Internet Engineering Task Force (IETF) R. van Brandenburg
Request for Comments: 7272 H. Stokking
Category: Standards Track O. van Deventer
ISSN: 2070-1721 TNO
F. Boronat
M. Montagud
UPV
K. Gross
AVA Networks
June 2014
Internet Engineering Task Force (IETF) R. van Brandenburg
Request for Comments: 7272 H. Stokking
Category: Standards Track O. van Deventer
ISSN: 2070-1721 TNO
F. Boronat
M. Montagud
UPV
K. Gross
AVA Networks
June 2014
Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)
使用RTP控制协议（RTCP）的目标间媒体同步（IDMS）
Abstract
摘要
This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.
本文档定义了新的RTP控制协议（RTCP）数据包类型和RTCP扩展报告（XR）块类型，用于实现目标间媒体同步（IDMS）。IDMS是跨多个媒体接收器同步播放的过程。使用本文档中定义的RTCP XR IDMS报告块，可以从同步组中的参与者收集媒体播放信息。根据收集到的信息，可以发送RTCP IDMS设置数据包以分发公共目标播放点，共享媒体体验的所有分布式接收器都可以同步到该点。
Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.
IDM有用的典型用例包括社交电视、共享服务控制（即两个或多个地理位置不同的用户一起观看媒体流的应用）、远程学习、网络视频墙、网络扬声器等。
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/rfc7272.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7272.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 3
2.2. IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . . 4
3. Inter-Destination Media Synchronization (IDMS) Use Cases . . 4
4. Overview of IDMS Operation . . . . . . . . . . . . . . . . . 5
5. Architecture for Inter-Destination Media Synchronization . . 7
5.1. Media Synchronization Application Server (MSAS) . . . . . 7
5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8
5.3. Communication between MSAS and SCs . . . . . . . . . . . 8
6. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . . . . 8
7. RTCP Packet Type for IDMS (IDMS Settings Packet) . . . . . . 11
8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13
9. On the Use of Presentation Timestamps . . . . . . . . . . . . 14
10. SDP Signaling for RTCP IDMS Settings Packet . . . . . . . . . 15
11. SDP Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Offer/Answer Rules . . . . . . . . . . . . . . . . . . . 16
11.2. Declarative Cases . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . 18
13.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . 19
13.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 19
13.4. IDMS XR Block SPST Registry . . . . . . . . . . . . . . 19
13.5. Contact Information for Registrations . . . . . . . . . 20
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 3
2.2. IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . . 4
3. Inter-Destination Media Synchronization (IDMS) Use Cases . . 4
4. Overview of IDMS Operation . . . . . . . . . . . . . . . . . 5
5. Architecture for Inter-Destination Media Synchronization . . 7
5.1. Media Synchronization Application Server (MSAS) . . . . . 7
5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8
5.3. Communication between MSAS and SCs . . . . . . . . . . . 8
6. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . . . . 8
7. RTCP Packet Type for IDMS (IDMS Settings Packet) . . . . . . 11
8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13
9. On the Use of Presentation Timestamps . . . . . . . . . . . . 14
10. SDP Signaling for RTCP IDMS Settings Packet . . . . . . . . . 15
11. SDP Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Offer/Answer Rules . . . . . . . . . . . . . . . . . . . 16
11.2. Declarative Cases . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . 18
13.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . 19
13.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 19
13.4. IDMS XR Block SPST Registry . . . . . . . . . . . . . . 19
13.5. Contact Information for Registrations . . . . . . . . . 20
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . 21
IDMS refers to the playout of media streams at two or more geographically distributed locations in a time-synchronized manner. It can be applied to both unicast and multicast media streams and can be applied to any type and/or combination of streaming media, such as audio, video, and text (subtitles). [Ishibashi2006] and [Boronat2009] provide an overview of technologies and algorithms for IDMS.
IDMS是指以时间同步的方式在两个或多个地理分布位置播放媒体流。它可以应用于单播和多播媒体流，并且可以应用于流媒体的任何类型和/或组合，例如音频、视频和文本（字幕）。[Ishibashi2006]和[Boronat2009]概述了IDMS的技术和算法。
Inter-Destination Media Synchronization (IDMS) requires the exchange of information on media arrival and presentation times among participants in an IDMS session. It may also require signaling for the initiation and maintenance of IDMS sessions and groups of receivers.
目的地间媒体同步（IDMS）需要在IDMS会话的参与者之间交换有关媒体到达和呈现时间的信息。它还可能需要信令来启动和维护IDMS会话和接收机组。
The presented RTCP specification for IDMS is independent of the synchronization algorithm employed, which is out of scope of this document.
所提出的IDMS RTCP规范独立于所采用的同步算法，不在本文档范围内。
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]中所述进行解释。
Currently, a large share of real-time applications make use of RTP and RTCP [RFC3550]. RTP provides end-to-end network transport functions suitable for applications requiring real-time data transport, such as audio, video, or data, over multicast or unicast network services. The timestamps, sequence numbers, and payload (content) type identification mechanisms provided by RTP packets are very useful for reconstructing the original media timing and the original order of packets and for detecting packet loss at the receiver.
目前，大部分实时应用程序使用RTP和RTCP[RFC3550]。RTP提供端到端网络传输功能，适用于需要通过多播或单播网络服务进行实时数据传输（如音频、视频或数据）的应用。RTP分组提供的时间戳、序列号和有效载荷（内容）类型识别机制对于重构原始媒体定时和分组的原始顺序以及用于在接收器处检测分组丢失非常有用。
The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner that is scalable to large groups and to provide minimal control and identification functionality. RTP receivers and senders provide reception quality feedback by sending out RTCP receiver report (RR) and sender report (SR) packets [RFC3550], respectively, which may be augmented by extended report (XR) blocks [RFC3611].
数据传输通过控制协议（RTCP）进行扩展，以允许以可扩展到大型组的方式监控数据传输，并提供最低限度的控制和识别功能。RTP接收方和发送方通过分别发送RTCP接收方报告（RR）和发送方报告（SR）数据包[RFC3550]来提供接收质量反馈，可通过扩展报告（XR）块[RFC3611]进行扩充。
IDMS involves the collection, summarization, and distribution of RTP packet arrival and presentation times. As information on RTP packet arrival times and presentation times can be considered reception quality feedback information, RTCP is well suited for carrying out IDMS.
IDMS涉及RTP数据包到达和呈现时间的收集、汇总和分发。由于有关RTP数据包到达时间和呈现时间的信息可被视为接收质量反馈信息，RTCP非常适合执行IDM。
A first version of IDMS for use with RTP/RTCP was standardized by ETSI Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) in [TS183063], resulting in an IANA registration for an RTCP XR Block Type. This work was then brought as input to the IETF AVTCORE WG for further standardization, leveraging the RTP/RTCP expertise present in the AVTCORE WG. This document is the result of that effort.
ETSI Telecommunications and Internet Converted Services and Protocols for Advanced Networking（TISPAN））在[TS183063]中对用于RTP/RTCP的IDMS的第一个版本进行了标准化，从而实现了RTCP XR块类型的IANA注册。这项工作随后作为输入提交给IETF AVTCORE工作组，以便进一步标准化，利用AVTCORE工作组中的RTP/RTCP专业知识。本文件就是这一努力的结果。
Although the IDMS protocol described in this document has evolved significantly from the version that was originally specified by ETSI TISPAN, it is still backwards compatible with the ETSI version. As such, it had been decided in ETSI to update the TS 183 063 document to reference this document as the normative specification of IDMS. This update can be found in newer versions of TS 183 063 (i.e., versions higher than 3.5.2). In accordance, this document proposes to update the IANA registration for the RTCP XR IDMS Report Block to point to this document. Finally, this document proposes an IANA registry for Synchronization Packet Sender Type (SPST) values, allowing the registration of extensions to this document.
尽管本文档中描述的IDMS协议与ETSI TISPAN最初指定的版本相比有了很大的改进，但它仍然向后兼容ETSI版本。因此，ETSI决定更新TS 183 063文件，以引用本文件作为IDMS的规范性规范。此更新可在TS 183 063的较新版本（即高于3.5.2的版本）中找到。根据本文件，本文件建议更新RTCP XR IDMS报告块的IANA注册，以指向本文件。最后，本文提出了一个用于同步数据包发送者类型（SPST）值的IANA注册表，允许注册此文档的扩展。
There is a large number of use cases in which IDMS might be useful. This section will highlight some of them. It should be noted that this section is in no way meant to be exhaustive.
在许多用例中，IDM可能是有用的。本节将重点介绍其中一些。应当指出，本节并非详尽无遗。
A first usage scenario for IDMS is social TV. Social TV is the combination of media content consumption by two or more users at different devices and locations combined with real-time communication between those users. An example of social TV is when two or more users are watching the same television broadcast at different devices and locations, while communicating with each other using text, audio, and/or video. A skew in their media playout processes can have adverse effects on their experience. A well-known use case here is one friend experiencing a goal in a football match well before or after another friend(s).
IDMS的第一个使用场景是社交电视。社交电视是两个或两个以上用户在不同设备和地点消费的媒体内容与这些用户之间的实时通信的结合。社交电视的一个例子是，两个或多个用户在不同的设备和位置观看相同的电视广播，同时使用文本、音频和/或视频彼此通信。媒体播放过程中的偏差可能会对他们的体验产生不利影响。这里一个众所周知的用例是一个朋友在另一个朋友之前或之后的足球比赛中进球。
Another potential use case for IDMS is a networked video wall. A video wall consists of multiple computer monitors, video projectors, or television sets tiled together contiguously or overlapped in order
IDMS的另一个潜在用例是网络视频墙。视频墙由多台计算机显示器、视频投影仪或电视机组成，它们以连续或重叠的顺序拼接在一起
to form one large screen. Each of the screens reproduces a portion of the larger picture. In some implementations, each screen may be individually connected to the network and receive its portion of the overall image from a network-connected video server or video scaler. Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh is not synchronized, the effect of multiple screens acting as one is broken, with users noticing tearing effects and no longer perceiving a single image.
形成一个大屏幕。每一个屏幕都再现了大图的一部分。在一些实现中，每个屏幕可以单独连接到网络，并从网络连接的视频服务器或视频定标器接收其整体图像的部分。屏幕刷新频率为60赫兹（每16-2/3毫秒一次）或可能更快。如果刷新不同步，多个屏幕作为一个屏幕的效果将被破坏，用户会注意到撕裂效果，不再感知单个图像。
A third usage scenario is that of networked loudspeakers in which two or more speakers are connected to the network individually. Such situations can, for example, be found in large conference rooms, legislative chambers, classrooms (especially those supporting distance learning), and other large-scale environments such as stadiums. Since humans are more sensitive to differences in audio delay compared to video delay, this use case needs even more accuracy than the video wall use case. Depending on the exact application, the need for accuracy can then be in the range of microseconds.
第三种使用场景是联网扬声器，其中两个或多个扬声器分别连接到网络。例如，在大型会议室、立法会议厅、教室（特别是支持远程学习的教室）和其他大型环境（如体育场）中可以发现这种情况。由于与视频延迟相比，人类对音频延迟的差异更为敏感，因此该用例比视频墙用例需要更高的准确性。根据具体应用，对精度的要求可能在微秒范围内。
This section provides a brief example of how the RTCP functionality is used for achieving IDMS. The section is tutorial in nature and does not contain any normative statements.
本节简要介绍了如何使用RTCP功能实现IDMS。本节为教程性质，不包含任何规范性声明。
Alice's . . . . . . .tv:abc.com . . . . . . . Bob's
TV (Sync Client) (Sync Server) Laptop (Sync Client)
| | |
| Media Session | |
|<=====================>| |
| Invite(URL, SyncGroupId) |
|------------------------------------------------->|
| | Media Session Setup |
| |<========================>|
| | |
| Call Setup |
|<================================================>|
| | |
| RTP Packets | RTP Packets |
|<----------------------|------------------------->|
| RR + XR IDMS Report | |
|---------------------->| RR + XR IDMS Report |
| |<-------------------------|
| RTCP IDMS Settings | RTCP IDMS Settings |
|<----------------------|------------------------->|
| | |
Alice's . . . . . . .tv:abc.com . . . . . . . Bob's
TV (Sync Client) (Sync Server) Laptop (Sync Client)
| | |
| Media Session | |
|<=====================>| |
| Invite(URL, SyncGroupId) |
|------------------------------------------------->|
| | Media Session Setup |
| |<========================>|
| | |
| Call Setup |
|<================================================>|
| | |
| RTP Packets | RTP Packets |
|<----------------------|------------------------->|
| RR + XR IDMS Report | |
|---------------------->| RR + XR IDMS Report |
| |<-------------------------|
| RTCP IDMS Settings | RTCP IDMS Settings |
|<----------------------|------------------------->|
| | |
Figure 1: Example of a Typical IDMS Session
图1：典型IDMS会话的示例
Alice is watching TV in her living room. At some point, she sees that Bob's favorite team is playing football. She sends him an invite to watch the program together. Embedded in the invitation is the link to the media server and a unique sync-group identifier.
爱丽丝正在客厅看电视。在某个时刻，她看到鲍勃最喜欢的球队在踢足球。她邀请他一起看节目。邀请中嵌入了指向媒体服务器的链接和唯一的同步组标识符。
Bob, who is also at home, receives the invite on his laptop. He accepts Alice's invitation, and the RTP client on his laptop sets up a session with the media server. A Voice over IP (VoIP) connection to Alice's TV is also set up, so that Alice and Bob can talk while watching the game together.
鲍勃也在家，他在笔记本电脑上收到了邀请。他接受了Alice的邀请，笔记本电脑上的RTP客户端与媒体服务器建立了会话。IP语音（VoIP）连接到Alice的电视，这样Alice和Bob可以在一起观看比赛时聊天。
As is common with RTP, both the RTP client in Alice's TV as well as the one in Bob's laptop send periodic RTCP RRs to the media server. However, in order to make sure Alice and Bob see the events in the football game at the same time, their clients also periodically send an RTCP XR IDMS Report Block to the Sync Server function of the media server. Included in the RTCP XR IDMS Report Blocks are timestamps on when both Alice and Bob received (and, optionally, when they played out) a particular RTP packet.
与RTP一样，Alice电视中的RTP客户端和Bob笔记本电脑中的RTP客户端定期向媒体服务器发送RTCP RRs。但是，为了确保Alice和Bob同时看到足球比赛中的事件，他们的客户端还定期向媒体服务器的同步服务器功能发送RTCP XR IDMS报告块。RTCP XR IDMS报告块中包括Alice和Bob接收（以及可选播放）特定RTP数据包时的时间戳。
The Sync Server function in the media server calculates a reference client from the received RTCP XR IDMS Report Blocks (e.g., by selecting the most lagged client as the reference for IDMS). It then sends an RTCP IDMS Settings Packet containing the playout information of this reference client to the sync clients of both Alice and Bob.
媒体服务器中的同步服务器功能根据接收到的RTCP XR IDMS报告块计算参考客户端（例如，通过选择最滞后的客户端作为IDMS的参考）。然后，它向Alice和Bob的同步客户端发送一个RTCP IDMS设置数据包，其中包含该参考客户端的播放信息。
In this case, Bob's connection has the longest delay and the reference client, therefore, includes a delay similar to the one experienced by Bob. Upon reception of this information, Alice's RTP client can choose what to do with this information. In this case, it decreases its playout rate temporarily until the playout time matches with the reference client playout (and, thus, matches Bob's playout). Another option for Alice's TV would be to simply pause playback until it catches up. The exact implementation of the synchronization algorithm is up to the client.
在这种情况下，Bob的连接具有最长的延迟，因此，参考客户机包括与Bob经历的延迟类似的延迟。收到此信息后，Alice的RTP客户端可以选择如何处理此信息。在这种情况下，它会暂时降低其播放速率，直到播放时间与参考客户端播放时间匹配（因此，与Bob的播放时间匹配）。爱丽丝的电视的另一个选择是暂停播放，直到它赶上。同步算法的具体实现取决于客户端。
Upon reception of the RTCP IDMS Settings Packet, Bob's client does not have to do anything since it is already synchronized to the reference client (since it is based on Bob's delay). Note that other synchronization algorithms may introduce even more delay than the one experienced by the most delayed client, e.g., to account for delay variations, for new clients joining an existing synchronization group, etc.
在接收到RTCP IDMS设置数据包后，Bob的客户端无需执行任何操作，因为它已与参考客户端同步（因为它基于Bob的延迟）。请注意，其他同步算法可能会引入比最延迟的客户端所经历的延迟更多的延迟，例如，为了考虑延迟变化，为了新客户端加入现有同步组，等等。
For this functionality to work correctly, it is necessary that the wallclocks of the receivers are synchronized with each other. While Alice and Bob both report when they receive, and optionally when they
为了使该功能正常工作，接收机的挂钟必须相互同步。而Alice和Bob都会在收到时报告，也可以在收到时报告
playout, certain RTP packets, in order to correlate their reports to each other, it is necessary that their wallclocks are synchronized.
播放，某些RTP数据包，为了使它们的报告相互关联，必须同步它们的挂钟。
The architecture for IDMS, which is based on a sync-maestro architecture [Boronat2009], is diagrammed below. In this particular case, the Synchronization Client (SC) and Media Synchronization Application Server (MSAS) entities are shown as additional functionality for the RTP receiver and sender, respectively.
IDMS的架构基于sync maestro架构[Boronat2009]，如下图所示。在此特定情况下，同步客户端（SC）和媒体同步应用服务器（MSAS）实体分别显示为RTP接收器和发送器的附加功能。
+-----------------------+ +-----------------------+
| | SR + | |
| RTP Receiver | RTCP | RTP Sender |
| | IDMS | |
| +-----------------+ | <----- | +-----------------+ |
| | | | | | | |
| | Synchronization | | | | Media | |
| | Client | | | | Synchronization | |
| | (SC) | | | | Application | |
| | | | | | Server | |
| | | | RR+XR | | (MSAS) | |
| | | | -----> | | | |
| +-----------------+ | | +-----------------+ |
| | | |
+-----------------------+ +-----------------------+
+-----------------------+ +-----------------------+
| | SR + | |
| RTP Receiver | RTCP | RTP Sender |
| | IDMS | |
| +-----------------+ | <----- | +-----------------+ |
| | | | | | | |
| | Synchronization | | | | Media | |
| | Client | | | | Synchronization | |
| | (SC) | | | | Application | |
| | | | | | Server | |
| | | | RR+XR | | (MSAS) | |
| | | | -----> | | | |
| +-----------------+ | | +-----------------+ |
| | | |
+-----------------------+ +-----------------------+
Figure 2: IDMS Architecture Diagram
图2:IDMS体系结构图
An MSAS collects RTP packet arrival times and presentation times from one or more SCs in a synchronization group by receiving RTCP XR IDMS reports. The MSAS summarizes and distributes this information to the SCs in the synchronization group as synchronization settings via the RTCP IDMS Settings Packet messages, e.g., by determining the SC with the most lagged playout and using its reported RTP packet arrival time and presentation time as a summary.
MSAS通过接收RTCP XR IDMS报告，从同步组中的一个或多个SCs收集RTP数据包到达时间和显示时间。MSA通过RTCP IDMS设置数据包消息将该信息汇总并作为同步设置分发给同步组中的SCs，例如，通过确定播放时间最晚的SC，并使用其报告的RTP数据包到达时间和呈现时间作为汇总。
It should be noted that while the diagram above shows the MSAS as part of the RTP sender, this is not necessary. For example, an MSAS might also be implemented as an independent function in the network or in a master/slave type of architecture where one of the SC devices also acts as an MSAS. Wherever the MSAS is implemented, it is important that the MSAS has access to the RTP stream to which the XR reports apply, so that it is able to correlate the RTCP XR IDMS reports coming from different SCs.
应该注意的是，尽管上图显示MSA是RTP发送器的一部分，但这并不是必需的。例如，msa还可以作为网络中的独立功能或在主/从类型的体系结构中实现，其中一个SC设备还充当msa。无论在何处实施MSA，MSA都必须能够访问XR报告应用的RTP流，以便能够关联来自不同SCs的RTCP XR IDMS报告。
An SC reports on RTP packet arrival times and presentation times of a media stream. It can receive IDMS Settings Packets containing summaries of such information and use that to adjust its playout buffer. The SC sends RTCP XR IDMS reports to the MSAS.
SC报告媒体流的RTP包到达时间和呈现时间。它可以接收包含此类信息摘要的IDMS设置数据包，并使用这些数据包调整其播放缓冲区。SC向MSA发送RTCP XR IDMS报告。
Two different message types are used for the communication between MSAS and SCs. For the SC->MSAS message containing the arrival and playout information of a particular client, an RTCP XR IDMS Report Block is used (see Section 6). For the MSAS->SC message containing the synchronization settings instructions, a new RTCP IDMS Settings Packet is defined (see Section 7).
MSA和SCs之间的通信使用两种不同的消息类型。对于包含特定客户端到达和播放信息的SC->MSAS消息，使用RTCP XR IDMS报告块（参见第6节）。对于包含同步设置指令的MSAS->SC消息，定义了一个新的RTCP IDMS设置数据包（参见第7节）。
This section specifies a new RTCP XR Block Type, the RTCP XR IDMS Report Block, for reporting IDMS information to an MSAS. In particular, it is used to provide feedback information on arrival times and presentation times of RTP packets. Its definition is based on [RFC3550] and [RFC3611].
本节指定一种新的RTCP XR块类型，即RTCP XR IDMS报告块，用于向MSAS报告IDMS信息。特别地，它用于提供关于RTP数据包的到达时间和呈现时间的反馈信息。其定义基于[RFC3550]和[RFC3611]。
In most cases, a single RTP receiver will only be part of a single IDMS session, i.e., it will report on arrival and presentation times of RTP packets from a single RTP stream in a certain synchronization group. In some cases, however, an RTP receiver may be a member of multiple synchronization groups for the same RTP stream, e.g., watching a single television program simultaneously with different groups. In even further cases, a receiver may wish to synchronize different RTP streams at the same time, either as part of the same synchronization group or as part of multiple synchronization groups. These are all valid scenarios for IDMS and will require multiple reports by an SC.
在大多数情况下，单个RTP接收器将仅是单个IDMS会话的一部分，即，它将报告来自某个同步组中单个RTP流的RTP数据包的到达和呈现时间。然而，在一些情况下，RTP接收机可以是相同RTP流的多个同步组的成员，例如，与不同组同时观看单个电视节目。在更进一步的情况下，接收机可能希望同时同步不同的RTP流，或者作为同一同步组的一部分，或者作为多个同步组的一部分。这些都是IDMS的有效方案，需要SC提交多份报告。
This document does not define new rules for when to send RTCP reports, but uses the existing rules specified in [RFC3550] for sending RTCP reports. When the RTCP reporting timer allows an SC to send an IDMS report, the SC SHOULD report on an RTP packet received during the period since the last RTCP XR IDMS Report Block was sent. Because of RTP timestamp rollover, there is ambiguity in mapping RTP timestamps to NTP timestamps. The recommendation to report on recent RTP packets serves to manage this ambiguity. For more details on which packet to report on, see below under "Packet Received RTP timestamp".
本文档未定义发送RTCP报告的新规则，但使用[RFC3550]中指定的发送RTCP报告的现有规则。当RTCP报告计时器允许SC发送IDMS报告时，SC应报告自上次发送RTCP XR IDMS报告块以来收到的RTP数据包。由于RTP时间戳的滚动，在将RTP时间戳映射到NTP时间戳时存在歧义。报告最近的RTP数据包的建议用于管理这种模糊性。有关报告哪个数据包的更多详细信息，请参阅下面的“数据包接收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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=12 | SPST |Resrv|P| block length=7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Resrv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=12 | SPST |Resrv|P| block length=7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Resrv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTCP XR IDMS Report Block consists of 8 32-bit words, with the following fields:
RTCP XR IDMS报告块由8个32位字组成，包含以下字段：
Block Type (BT): 8 bits. It identifies the block format. Its value is set to 12.
块类型（BT）：8位。它标识块格式。其值设置为12。
Synchronization Packet Sender Type (SPST): 4 bits. This field identifies the role of the packet sender for this specific Extended Report. It can have the following values, as enumerated in a registry maintained by IANA (see Section 13.4):
同步数据包发送方类型（SPST）：4位。此字段标识此特定扩展报告的数据包发送者的角色。它可以具有以下值，如IANA维护的注册表中所列举的（见第13.4节）：
SPST=0 Reserved for future use.
SPST=0保留供将来使用。
SPST=1 The packet sender is an SC. It uses this XR to report synchronization status information. Timestamps relate to the SC input.
SPST=1数据包发送方是SC。它使用此XR报告同步状态信息。时间戳与SC输入相关。
SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]).
SPST=ETSI TISPAN定义的2-4个值（见[TS183063]）。
SPST=5-15 Unassigned.
SPST=5-15未分配。
Reserved bits (Resrv): 3 bits. These bits are reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero at transmission and MUST be ignored by the receiver.
保留位（Resrv）：3位。这些位保留用于将来的定义。在没有此类定义的情况下，此字段中的位必须在传输时设置为零，并且必须被接收器忽略。
Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the Packet Presented NTP timestamp field contains a value, 0 if it is empty. If this flag is set to 0, then the Packet Presented NTP timestamp SHALL be ignored by the receiver.
数据包呈现NTP时间戳标志（P）：1位。如果数据包显示的NTP时间戳字段包含值，则位设置为1，如果为空，则位设置为0。如果该标志设置为0，则接收方应忽略呈现NTP时间戳的数据包。
Block Length: 16 bits. This field indicates the length of the block in 32-bit words minus one and is set to 7, as this RTCP XR IDMS Block Report has a fixed length.
块长度：16位。此字段以32位字减去1表示块的长度，并设置为7，因为此RTCP XR IDMS块报告具有固定长度。
Payload Type (PT): 7 bits. This field identifies the format of the media payload, according to [RFC3551]. This is the payload type of the RTP packet reported upon. The PT field is needed in the case where the MSAS is neither the media server nor a receiver of the media stream, i.e., it is implemented as a third-party entity. In such cases, the MSAS needs the PT to determine the rate of advancement of the timestamps of the RTP media stream to be able to relate reports from different SCs on different RTP timestamp values.
有效负载类型（PT）：7位。该字段根据[RFC3551]标识媒体有效负载的格式。这是报告的RTP数据包的有效负载类型。在MSAS既不是媒体服务器也不是媒体流的接收器的情况下（即，它被实现为第三方实体），需要PT字段。在这种情况下，msa需要PT确定RTP媒体流的时间戳的前进速率，以便能够将来自不同SCs的报告与不同RTP时间戳值相关联。
Reserved bits (Resrv): 25 bits. These bits are reserved for future use and SHALL be set to 0 at transmission and MUST be ignored by the receiver.
保留位（Resrv）：25位。这些位保留供将来使用，在传输时应设置为0，且接收器必须忽略。
Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media streams. The value 0 (all bits are set "0") indicates that this field is empty. The value 2^32-1 (all bits are set "1") is reserved for future use. If the RTCP Packet Sender is an SC (SPST=1), then the Media Stream Correlation Identifier field contains the Synchronization Group Identifier (SyncGroupId) to which the report applies.
媒体流相关标识符：32位。此标识符用于关联同步媒体流。值0（所有位均设置为“0”）表示该字段为空。值2^32-1（所有位均设置为“1”）保留供将来使用。如果RTCP数据包发送方是SC（SPST=1），则媒体流相关标识符字段包含报告适用的同步组标识符（SyncGroupId）。
Synchronization Source (SSRC): 32 bits. The SSRC of the media source is set to the value of the SSRC identifier carried in the RTP header [RFC3550] of the RTP packet to which the XR IDMS relates.
同步源（SSRC）：32位。媒体源的SSRC设置为XR IDMS相关RTP数据包的RTP报头[RFC3550]中携带的SSRC标识符的值。
Packet Received NTP timestamp: 64 bits. This timestamp reflects the wallclock time at the moment of arrival of the first octet of the RTP packet to which the XR IDMS relates. It is formatted based on the NTP timestamp format as specified in [RFC5905]. See Section 8 for more information on how this field is used.
收到的数据包NTP时间戳：64位。该时间戳反映XR IDMS所涉及的RTP数据包的第一个八位组到达时的挂钟时间。根据[RFC5905]中规定的NTP时间戳格式对其进行格式化。有关如何使用此字段的更多信息，请参见第8节。
Packet Received RTP timestamp: 32 bits. This timestamp has the value of the RTP timestamp carried in the RTP header [RFC3550] of the RTP packet to which the XR IDMS relates. Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. It may well be the case that one receiver reports on the first RTP packet that has a certain RTP timestamp, and a second receiver reports on the last RTP packet that has that same RTP timestamp. This would lead to an error in the
数据包接收RTP时间戳：32位。此时间戳具有XR IDMS相关RTP数据包的RTP报头[RFC3550]中携带的RTP时间戳的值。如果几个连续的RTP数据包（逻辑上）同时生成，例如，属于同一视频帧，则它们将具有相等的时间戳。很可能是这样的情况，一个接收机报告具有特定RTP时间戳的第一个RTP分组，而第二个接收机报告具有相同RTP时间戳的最后一个RTP分组。这将导致错误
synchronization algorithm due to the faulty interpretation of considering both reports to be on the same RTP packet. When reporting on an RTP packet, which is one of several consecutive RTP packets having equal timestamps, an SC SHOULD report on the RTP packet it received with the lowest sequence number. Note that 'lowest sequence number' here is meant to be the first in the sequence of RTP packets just received, not from an earlier time before the last wrap around of RTP timestamps (unless this wrap around occurs during the sequence with equal RTP timestamps).
由于错误地解释了将两个报告视为在同一个RTP数据包上，因此采用了同步算法。当报告RTP数据包（具有相同时间戳的多个连续RTP数据包之一）时，SC应报告其接收的具有最低序列号的RTP数据包。请注意，此处的“最低序列号”是指刚接收到的RTP数据包序列中的第一个，而不是来自RTP时间戳最后一次环绕之前的较早时间（除非此环绕在具有相同RTP时间戳的序列期间发生）。
Packet Presented NTP timestamp: 32 bits. This timestamp reflects the wallclock time at the moment the rendered media unit (e.g., video frame or audio sample) contained in the first byte of the associated RTP packet is presented to the user. It is based on the time format used by NTP and consists of the least significant 16 bits of the NTP seconds part and the most significant 16 bits of the NTP fractional second part. If no Packet Presented NTP timestamp is available, this field SHALL be set to 0 and be considered empty, and the Packet Presented NTP timestamp flag (P) SHALL be set to 0. With regards to NTP epoch and rollover, the value of the Packet Presented NTP timestamp is considered to always be greater than the Packet Received NTP timestamp and to be within 2^16 seconds of it. Presented in this context means the moment the data is played out to the user of the system, i.e., sound played out through speakers, video images being displayed on some display, etc. The accuracy resulting from the synchronization algorithm will only be as good as the accuracy with which the SCs can determine the delay between receiving packets and presenting them to the end user. If no presentation timestamps are reported by SCs, the ability to accurately synchronize playout may be limited.
数据包呈现NTP时间戳：32位。该时间戳反映了相关RTP分组的第一字节中包含的渲染媒体单元（例如，视频帧或音频样本）呈现给用户时的墙时钟时间。它基于NTP使用的时间格式，由NTP秒部分的最低有效16位和NTP分数秒部分的最高有效16位组成。如果没有数据包呈现的NTP时间戳可用，则该字段应设置为0并视为空，数据包呈现的NTP时间戳标志（P）应设置为0。关于NTP epoch和rollover，认为呈现NTP时间戳的数据包的值始终大于接收到的数据包NTP时间戳，并且在其2^16秒内。在本上下文中，表示向系统用户播放数据的时刻，即通过扬声器播放声音，在某些显示器上显示视频图像，等等。同步算法产生的精度仅与SCs确定接收数据包和向最终用户呈现数据包之间的延迟的精度相同。如果SCs未报告演示时间戳，则准确同步播放的能力可能会受到限制。
This section specifies the RTCP packet type for indicating synchronization settings instructions to the receivers of the RTP media stream. Its definition is based on [RFC3550]. Synchronization settings take the form of a report referencing a real or hypothetical RTP packet selected or contrived by the MSAS.
本节指定RTCP数据包类型，用于向RTP媒体流的接收器指示同步设置指令。其定义基于[RFC3550]。同步设置采用报告的形式，引用MSA选择或设计的真实或假设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| Resrv | PT=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Resrv | PT=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 64 bits form the header of the RTCP packet type, as defined in [RFC3550]. The SSRC of the packet sender identifies the sender of the specific RTCP packet.
前64位构成RTCP数据包类型的报头，如[RFC3550]中所定义。数据包发送方的SSRC标识特定RTCP数据包的发送方。
The RTCP IDMS Settings Packet consists of 7 32-bit words, with the following fields:
RTCP IDMS设置数据包由7个32位字组成，包含以下字段：
PT: 211, as registered by IANA.
PT:211，由IANA注册。
SSRC: 32 bits. The SSRC of the media source is set to the value of the SSRC identifier of the media source carried in the RTP header [RFC3550] of the RTP packet to which the RTCP IDMS Settings Packet relates.
SSRC:32位。媒体源的SSRC设置为与RTCP IDMS设置数据包相关的RTP数据包的RTP报头[RFC3550]中携带的媒体源的SSRC标识符的值。
Media Stream Correlation Identifier: 32 bits. This identifier is used to correlate synchronized media streams. The value 0 (all bits are set "0") indicates that this field is empty. The value 2^32-1 (all bits are set "1") is reserved for future use. The Media Stream Correlation Identifier contains the SyncGroupId of the group to which this packet is sent.
媒体流相关标识符：32位。此标识符用于关联同步媒体流。值0（所有位均设置为“0”）表示该字段为空。值2^32-1（所有位均设置为“1”）保留供将来使用。媒体流相关标识符包含将此数据包发送到的组的SyncGroupId。
Packet Received NTP timestamp: 64 bits. This timestamp reflects the wallclock time at the reference client at the moment it received the first octet of the RTP packet to which this packet relates. It can be used by the synchronization algorithm on the receiving SC to adjust its playout timing in order to achieve synchronization, e.g.,
收到的数据包NTP时间戳：64位。该时间戳反映了参考客户机在接收到与该数据包相关的RTP数据包的第一个八位组时的挂钟时间。它可由接收SC上的同步算法用于调整其播放定时，以实现同步，例如。，
to set the required playout delay. The timestamp is formatted based on the NTP timestamp format as specified in [RFC5905]. See Section 8 for more information on how this field is used. Because RTP timestamps do wrap around, the sender of this packet MUST use recent values, i.e., choose NTP timestamps that reflect current time and not too far in the future or in the past so as to create ambiguity with regards to RTP timestamp wrap around.
设置所需的播放延迟。时间戳的格式基于[RFC5905]中规定的NTP时间戳格式。有关如何使用此字段的更多信息，请参见第8节。由于RTP时间戳确实是环绕的，因此该数据包的发送方必须使用最近的值，即，选择反映当前时间且在未来或过去不太远的NTP时间戳，以便在RTP时间戳环绕方面产生歧义。
Packet Received RTP timestamp: 32 bits. This timestamp has the value of the RTP timestamp carried in the RTP header [RFC3550] of the RTP packet to which the XR IDMS relates. This SHOULD relate to the first arriving RTP packet containing this particular RTP timestamp, in case multiple consecutive RTP packets contain the same RTP timestamp.
数据包接收RTP时间戳：32位。此时间戳具有XR IDMS相关RTP数据包的RTP报头[RFC3550]中携带的RTP时间戳的值。如果多个连续RTP数据包包含相同的RTP时间戳，则这应与包含该特定RTP时间戳的第一个到达RTP数据包相关。
Packet Presented NTP timestamp: 64 bits. This timestamp reflects the wallclock time at the reference client at the moment it presented the rendered media unit (e.g., video frame or audio sample) contained in the first octet of the associated RTP packet to the user. The timestamp is formatted based on the NTP timestamp format as specified in [RFC5905]. If no Packet Presented NTP timestamp is available, this field SHALL be set to 0 and be considered empty. This field MAY be left empty if none or only one of the receivers reported on presentation timestamps. Presented here means the moment the data is played out to the user of the system.
数据包呈现NTP时间戳：64位。该时间戳反映了参考客户端向用户呈现包含在相关RTP分组的第一个八位组中的渲染媒体单元（例如，视频帧或音频样本）时的参考客户端的墙时钟时间。时间戳的格式基于[RFC5905]中规定的NTP时间戳格式。如果没有提供NTP时间戳的数据包，该字段应设置为0，并视为空。如果没有或只有一个接收者报告了演示时间戳，则此字段可能为空。此处显示的是指向系统用户播放数据的时刻。
In some use cases (e.g., phased array transducers), the level of control an MSAS might need to have over the exact moment of playout is so precise that a 32-bit Presented timestamp will not suffice. For this reason, this RTCP packet type for IDMS includes a 64-bit Presented Timestamp field. Since an MSAS will in practice always add some extra delay to the delay reported by the most lagged receiver (to account for packet jitter), it suffices for the RTCP XR IDMS Report Block with which the SCs report on their playout to have a 32-bit Presented Timestamp field.
在某些使用情况下（例如，相控阵传感器），MSA可能需要对播放的准确时刻进行精确控制，因此32位时间戳是不够的。因此，IDMS的RTCP数据包类型包括一个64位的时间戳字段。由于MSA在实践中总是会在最滞后的接收器报告的延迟上增加一些额外的延迟（以考虑数据包抖动），因此SCs在播放时报告的RTCP XR IDMS报告块具有32位呈现的时间戳字段就足够了。
To achieve IDMS, the different receivers involved need synchronized wallclocks as a common timeline for synchronization. This synchronized clock is used for reporting the Packet Received NTP timestamp and the Packet Presented NTP timestamp, and for interpretation of these fields in received IDMS Settings Packets. Depending on the synchronization accuracy required, different clock synchronization methods can be used. For social TV, synchronization accuracy should be achieved on the order of hundreds of milliseconds. In that case, correct use of NTP on receivers will in most situations achieve the required accuracy. As a guideline, to deal with clock drift of receivers, receivers should synchronize their clocks at the
为了实现IDM，所涉及的不同接收机需要同步的挂钟作为同步的公共时间线。该同步时钟用于报告数据包接收到的NTP时间戳和数据包呈现的NTP时间戳，并用于解释接收到的IDMS设置数据包中的这些字段。根据所需的同步精度，可以使用不同的时钟同步方法。对于社交电视，同步精度应该达到数百毫秒左右。在这种情况下，在大多数情况下，在接收机上正确使用NTP将达到所需的精度。作为指南，为了处理接收机的时钟漂移，接收机应在同一时间同步其时钟
beginning of a synchronized session. In case of high required accuracy, the synchronized clocks of different receivers should not drift beyond the accuracy required for the synchronization mechanism. In practice, this can mean that receivers need to synchronize their clocks repeatedly during a synchronization session.
同步会话的开始。在要求精度较高的情况下，不同接收机的同步时钟不应漂移超过同步机构要求的精度。实际上，这可能意味着接收机需要在同步会话期间重复同步其时钟。
Because of the stringent synchronization requirements for achieving good audio quality in some use cases, a high accuracy will be needed. In this case, use of the global NTP system may not be sufficient. For improved accuracy, a local NTP server could be set up, or some other more accurate clock synchronization mechanism can be used, such as GPS time or the Precision Time Protocol [IEEE1588-2008].
由于在某些使用情况下，为了获得良好的音频质量，需要严格的同步要求，因此需要高精度。在这种情况下，使用全球NTP系统可能不够。为了提高精度，可以设置本地NTP服务器，或使用其他更精确的时钟同步机制，如GPS时间或精密时间协议[IEEE1588-2008]。
[RFC7273] defines a set of Session Description Protocol (SDP) parameters for signaling the clock synchronization source or sources available to and used by the individual receivers. SCs MAY use [RFC7273] to indicate their clock synchronization source or sources in use and available. Using these parameters, an SC can indicate which synchronization source is being used at the moment. An SC can also indicate any other synchronization sources available to it. This allows multiple SCs in an IDMS session to use the same or a similar clock source for their session.
[RFC7273]定义了一组会话描述协议（SDP）参数，用于向单个接收机可用并由其使用的时钟同步源发送信号。SCs可使用[RFC7273]指示其时钟同步源或正在使用且可用的源。使用这些参数，SC可以指示当前正在使用哪个同步源。SC还可以指示其可用的任何其他同步源。这允许IDMS会话中的多个SC为其会话使用相同或类似的时钟源。
Applications performing IDMS may or may not be able to choose a synchronization method for the system clock because this may be a system-wide setting that the application cannot change. How applications deal with this is up to the implementation. The application might control the system clock, or it might use a separate application clock or even a separate IDMS session clock. It might also report on the system clock and the synchronization method used, without being able to change it.
执行IDM的应用程序可能无法为系统时钟选择同步方法，因为这可能是应用程序无法更改的系统范围设置。应用程序如何处理这一问题取决于实现。应用程序可以控制系统时钟，也可以使用单独的应用程序时钟，甚至是单独的IDMS会话时钟。它还可能报告系统时钟和使用的同步方法，而无法更改它。
[RFC7164] presents some guidelines on how RTP senders and receivers should deal with leap seconds. When relying on NTP for clock synchronization, IDMS is particularly sensitive to leap-second-induced timing discrepancies. It is RECOMMENDED to take the guidelines specified in [RFC7164] into account when implementing IDMS.
[RFC7164]介绍了RTP发送方和接收方应如何处理闰秒的一些指导原则。当依靠NTP进行时钟同步时，IDMS对闰秒引起的定时差异特别敏感。建议在实施IDMS时考虑[RFC7164]中规定的指南。
A receiver can report on different timing events, i.e., on packet arrival times and on playout or presentation times. A receiver SHALL report on arrival times and a receiver MAY report on playout times. RTP packet arrival times are relatively easy to report on. Normally, the processing and playout of the same media stream by different receivers will take roughly the same amount of time. Synchronizing
接收机可以报告不同的定时事件，即分组到达时间和播放或呈现时间。接收者应报告到达时间，接收者可报告播放时间。RTP数据包到达时间相对容易报告。通常，不同接收器对相同媒体流的处理和播放将花费大致相同的时间。同步
on packet arrival times may lead to some accuracy loss, but it will be adequate for many applications, such as social TV.
数据包到达时间可能会导致一些准确性损失，但对于许多应用程序（如社交电视）来说，这已经足够了。
Also, if the receivers are in some way controlled, e.g., having the same buffer settings and decoding and rendering times, high accuracy can be achieved. However, if all receivers in a synchronization session have the ability to report on and, thus, synchronize on actual presentation times, this will be more accurate. It is up to the applications and implementations of this RTCP extension whether to implement and use presentation timestamps.
此外，如果接收机以某种方式被控制，例如，具有相同的缓冲器设置以及解码和渲染时间，则可以实现高精度。但是，如果同步会话中的所有接收器都能够报告并因此能够同步实际的演示时间，那么这将更加准确。是否实现和使用表示时间戳取决于此RTCP扩展的应用程序和实现。
The SDP attribute rtcp-idms is used to signal the use of the RTCP IDMS Settings Packet and the associated RTCP XR IDMS Report Block. It is also used to carry an identifier of the synchronization group to which clients belong or will belong. The SDP attribute is used as a media-level attribute during session setup. This means that in case of multiple related streams, IDMS is performed on one of them. The other streams will be synchronized to this reference or master stream using existing inter-stream synchronization (such as lip-sync) solutions, i.e., using sender reports based on a common clock source. Basic guidelines for choosing the media stream for IDMS is to choose audio above video, as humans are most sensitive to degradation in audio synchronization. When using multi-description or multi-view codecs, the IDMS control should be performed on the base layer.
SDP属性rtcp idms用于发出使用rtcp idms设置数据包和相关rtcp XR idms报告块的信号。它还用于携带客户端所属或将要属的同步组的标识符。SDP属性在会话设置期间用作媒体级属性。这意味着在多个相关流的情况下，对其中一个流执行idm。其他流将使用现有的流间同步（例如lip sync）解决方案（即，使用基于公共时钟源的发送方报告）与该参考流或主流同步。为IDM选择媒体流的基本准则是选择音频而不是视频，因为人类对音频同步的退化最敏感。当使用多描述或多视图编解码器时，IDMS控制应在基本层上执行。
This SDP attribute is defined as follows, using Augmented Backus-Naur Form [RFC5234].
此SDP属性的定义如下所示，使用扩展的Backus Naur表单[RFC5234]。
rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF
rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF
sync-grp = "sync-group=" SyncGroupId
sync grp=“sync group=”SyncGroupId
SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294
SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294
DIGIT = %x30-39
DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer and represented in decimal. SyncGroupId identifies a group of SCs for IDMS. The value SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 (2^32-1) is reserved for future use. For a description on the value of SyncGroupId to include, see Section 11.
SyncGroupId是一个32位无符号整数，以十进制表示。SyncGroupId为IDM标识一组SCs。值SyncGroupId=0表示空的SyncGroupId。值4294967295（2^32-1）保留供将来使用。有关要包括的SyncGroupId值的说明，请参见第11节。
The following is an example of the SDP attribute for IDMS.
以下是IDMS的SDP属性示例。
a=rtcp-idms:sync-group=42
a=rtcp-idms:sync-group=42
The SDP usage for IDMS follows the rules defined in [RFC4566] and Section 5 of [RFC3611] on SDP signaling with the exception of what is stated here. The IDMS usage of RTCP is a loosely coupled collaborative attribute, in the sense that receivers send their status information and, in response, the MSAS asynchronously sends synchronization setting instructions. The rtcp-idms attribute, thus, indicates the ability to send and receive indicated RTCP messages. This section defines how this SDP attribute should be used with regard to an offer/answer context.
IDM的SDP使用遵循[RFC4566]和[RFC3611]第5节中关于SDP信令的规定，但此处所述的情况除外。RTCP的IDMS使用是一种松散耦合的协作属性，即接收方发送其状态信息，作为响应，MSA异步发送同步设置指令。因此，rtcp idms属性表示发送和接收指定rtcp消息的能力。本节定义了此SDP属性在提供/应答上下文中的使用方式。
It is expected that, in most cases, the rtcp-idms attribute will be used in an offer/answer context where receivers will have predetermined, through some means outside the scope of this document, a SyncGroupId before the media session is set up. However, A sender that assigns a SyncGroupId is also supported for cases, for example, where the MSAS contains group management functionality and is co-located with or otherwise communicates with the sender. Thus, both senders and receivers can insert the attribute and the SyncGroupId. Furthermore, the attribute is allowed to be inserted for more than one media stream, allowing an SC to become part of multiple synchronization groups simultaneously. This effectively couples two (or more) synchronization groups to each other. If the rtcp-idms attribute is inserted more than once for a particular media session, each SyncGroupId SHALL only be inserted once.
预计在大多数情况下，rtcp idms属性将在提供/应答上下文中使用，在该上下文中，接收者将在设置媒体会话之前通过本文档范围之外的某种方式预先确定SyncGroupId。但是，在某些情况下，也支持分配SyncGroupId的发送方，例如，MSA包含组管理功能，并且与发送方位于同一位置或以其他方式进行通信。因此，发送方和接收方都可以插入属性和SyncGroupId。此外，允许为多个媒体流插入该属性，从而允许SC同时成为多个同步组的一部分。这将有效地将两个（或更多）同步组相互耦合。如果为特定媒体会话多次插入rtcp idms属性，则每个SyncGroupId只能插入一次。
In order to join an IDMS session, the receiver (the SC) inserts the rtcp-idms attribute as a media-level attribute in the SDP offer. This SDP offer can be an initial offer if the media session is starting as a synchronized session. The SDP offer can also be an update to an existing media session, converting the session to an IDMS session. If the receiver has a predetermined SyncGroupId value, it SHOULD use this value for setting the SyncGroupId parameter in the rtcp-idms attribute. If the receiver does not know the SyncGroupId to be used, it MAY leave the SyncGroupId parameter empty by setting its value to 0.
为了加入IDMS会话，接收方（SC）将rtcp IDMS属性作为媒体级属性插入SDP报价中。如果媒体会话以同步会话启动，则此SDP优惠可以是初始优惠。SDP服务还可以是对现有媒体会话的更新，将会话转换为IDMS会话。如果接收器具有预定的SyncGroupId值，则应使用该值在rtcp idms属性中设置SyncGroupId参数。如果接收方不知道要使用的SyncGroupId，则可以将SyncGroupId参数的值设置为0，从而将其保留为空。
The sender SHALL include the rtcp-idms attribute in its answer. If the value of the SyncGroupId parameter in the offer is not empty (not equal to 0), the sender SHOULD NOT change the SyncGroupId in its answer. If the SyncGroupId is empty, the sender SHALL include the proper SyncGroupId in its answer. If the sender receives an offer with the value of the SyncGroupId parameter set to 0, and cannot determine the proper SyncGroupId, it SHALL remove the attribute from its answer.
发送方应在其回答中包含rtcp idms属性。如果报价中SyncGroupId参数的值不为空（不等于0），则发件人不应更改其答案中的SyncGroupId。如果SyncGroupId为空，发送方应在其答案中包含正确的SyncGroupId。如果发件人收到SyncGroupId参数值设置为0的要约，并且无法确定正确的SyncGroupId，则应将该属性从其答案中删除。
A sender receiving an SDP offer without the rtcp-idms attribute can also decide that IDMS is applicable to that media session. In such a case, the sender MAY insert the rtcp-idms attribute, including a non-empty SyncGroupId, as part of its answer.
接收不带rtcp idms属性的SDP要约的发送方也可以确定idms适用于该媒体会话。在这种情况下，发送方可以插入rtcp idms属性，包括非空SyncGroupId，作为其答案的一部分。
A receiver receiving an rtcp-idms attribute as part of the SDP answer from a sender SHALL start sending RTCP XR IDMS reports (following all the normal RTCP rules for sending RTCP XR IDMS Report Blocks) and SHALL be ready to start receiving IDMS Settings. As usual, if a receiver does not support the attribute (e.g., in case of an MSAS-inserted IDMS attribute), it SHALL ignore the attribute.
作为发送方SDP应答的一部分，接收rtcp idms属性的接收方应开始发送rtcp XR idms报告（遵循发送rtcp XR idms报告块的所有正常rtcp规则），并应准备好开始接收idms设置。通常，如果接收器不支持该属性（例如，在MSAS插入IDMS属性的情况下），则应忽略该属性。
Different updates are applicable to such an IDMS session. Updates can be sent omitting the rtcp-idms attribute, thereby ending involvement in the synchronization session. Updates can also be sent including the rtcp-idms attribute, but with a different SyncGroupId. This indicates a switch in the synchronization group.
不同的更新适用于此类IDMS会话。发送更新时可以忽略rtcp idms属性，从而结束同步会话。也可以发送更新，包括rtcp idms属性，但使用不同的SyncGroupId。这表示同步组中有一个开关。
In certain situations, there is no offer/answer context, but only a declarative modus. In this case, the MSAS just inserts the rtcp-idms attribute and a valid SyncGroupId. Any receiver receiving the rtcp-idms attribute in such a declarative case SHALL start sending RTCP XR IDMS Report Blocks and SHALL be ready to start receiving RTCP IDMS Settings Packets.
在某些情况下，没有提供/回答上下文，只有声明性方式。在这种情况下，MSA只插入rtcp idms属性和有效的SyncGroupId。在这种声明性情况下，接收rtcp idms属性的任何接收器应开始发送rtcp XR idms报告块，并应准备好开始接收rtcp idms设置数据包。
The security considerations described in [RFC3611] apply to this document as well.
[RFC3611]中描述的安全注意事项也适用于本文档。
The RTCP XR IDMS Report Block defined in this document is used to collect, summarize, and distribute information on packet reception and playout times of streaming media. The information may be used to orchestrate the media playout at multiple devices.
本文档中定义的RTCP XR IDMS报告块用于收集、汇总和分发有关流媒体数据包接收和播放时间的信息。该信息可用于在多个设备上编排媒体播放。
Errors in the information, either accidental or malicious, may lead to undesired behavior. For example, if one device erroneously or maliciously reports a two-hour delayed playout, then another device in the same synchronization group could decide to delay its playout by two hours as well, in order to keep its playout synchronized. A user would likely interpret this two-hour delay as a malfunctioning service.
信息中的错误，无论是偶然的还是恶意的，都可能导致不期望的行为。例如，如果一个设备错误地或恶意地报告了两个小时的延迟播放，那么同一同步组中的另一个设备也可以决定将其播放延迟两个小时，以保持其播放同步。用户可能会将这两个小时的延迟解释为服务出现故障。
Therefore, the application logic of both SCs and MSASs should check for out-of-bound information. Differences in playout time exceeding configured limits (e.g., more than ten seconds) could be an indication of such out-of-bound information.
因此，SCs和MSSS的应用逻辑都应检查越界信息。播放时间的差异超过配置的限制（例如，超过10秒）可能表示此类越界信息。
Apart from checking for out-of-bound information in the endpoints, an IDMS implementation can reduce its vulnerability to attacks by including source authentication and message integrity measures, reducing the potential for man-in-the-middle attacks. [RFC7201] provides an overview of the security options in RTP environments and includes a set of recommendations for message integrity and source authentication that are applicable to IDMS. In addition to preventing man-in-the-middle attacks from inserting erroneous IDMS reports, the message confidentiality mechanisms outlined in [RFC7201] also prevent third parties from determining that two or more end hosts are receiving the same stream by looking at the Media Stream Correlation Identifier.
除了检查端点中的越界信息外，IDMS实现还可以通过包括源身份验证和消息完整性措施来降低其易受攻击的漏洞，从而降低中间人攻击的可能性。[RFC7201]概述了RTP环境中的安全选项，并包括一组适用于IDM的消息完整性和源身份验证建议。除了防止中间人攻击插入错误的IDMS报告外，[RFC7201]中概述的消息保密机制还防止第三方通过查看媒体流相关标识符来确定两个或多个终端主机正在接收相同的流。
Apart from attacking an IDMS session directly by sending incorrect IDMS reports, and with it introducing delays for all devices in a synchronization group, another potential vulnerability comes from the clock synchronization method used. Should an attacker succeed in adjusting an SC's wallclock, that SC will report incorrect IDMS reports. In order to prevent such clock synchronization attacks, it is recommended to use a secure time synchronization service.
除了通过发送不正确的IDMS报告直接攻击IDMS会话，并为同步组中的所有设备引入延迟之外，另一个潜在漏洞来自所使用的时钟同步方法。如果攻击者成功调整SC的挂钟，该SC将报告不正确的IDMS报告。为了防止此类时钟同步攻击，建议使用安全的时间同步服务。
This document defines a new RTCP packet type, the RTCP IDMS Packet (IDMS Settings), within the existing Internet Assigned Numbers Authority (IANA) registry of RTCP Control Packet Types. This document also defines a new RTCP XR Block Type, the RTCP XR IDMS Report Block, within the existing IANA registry of RTCP Extended Reports (RTCP XR) Block Types.
本文档在现有的RTCP控制数据包类型的Internet Assigned Numbers Authority（IANA）注册表中定义了一种新的RTCP数据包类型，即RTCP IDMS数据包（IDMS设置）。本文档还定义了RTCP扩展报告（RTCP XR）块类型的现有IANA注册表中的新RTCP XR块类型RTCP XR IDMS报告块。
Further, this document defines a new SDP attribute "rtcp-idms" within the existing IANA registry of SDP Parameters, which is part of the "att-field (media level only)". Finally, this document defines a new IANA registry subordinate to the IANA RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR Block SPST Registry.
此外，本文档在SDP参数的现有IANA注册表中定义了一个新的SDP属性“rtcp idms”，它是“att字段（仅媒体级别）”的一部分。最后，本文档定义了从属于IANA RTCP扩展报告（RTCP XR）块类型注册表的新IANA注册表：IDMS XR块SPST注册表。
This document assigns the packet type value 211 in the IANA 'RTCP Control Packet types (PT)' registry to the RTCP IDMS Packet (IDMS Settings).
本文件将IANA“RTCP控制数据包类型（PT）”注册表中的数据包类型值211分配给RTCP IDMS数据包（IDMS设置）。
This document updates the assignment of value 12 from the RTCP XR Block Type for reporting IDMS information as per [TS183063] to the RTCP XR IDMS Report Block defined in this document.
本文档根据[TS183063]将RTCP XR IDMS报告块类型中的值12的赋值更新为本文档中定义的RTCP XR IDMS报告块。
The RTCP XR IDMS Report Block contains an extensible SPST value field; therefore, a new registry for this field is required. This new registry is defined in Section 13.4.
RTCP XR IDMS报告块包含可扩展的SPST值字段；因此，此字段需要一个新的注册表。该新注册在第13.4节中定义。
The SDP attribute "rtcp-idms" defined by this document is registered with the IANA registry of SDP Parameters as follows:
本文档定义的SDP属性“rtcp idms”在IANA SDP参数注册表中注册，如下所示：
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
Attribute name: rtcp-idms
属性名称：rtcp idms
Long form: RTCP IDMS Parameters
长格式：RTCP IDMS参数
Type of name: att-field
名称类型：att字段
Type of attribute: media level
属性类型：媒体级别
Subject to charset: no
以字符集为准：否
Purpose: see Section 10 of this document
目的：见本文件第10节
Reference: this document
参考：本文件
Values: see this document
值：请参阅此文档
This document defines a new IANA registry subordinate to the IANA RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR Block SPST Registry.
本文档定义了从属于IANA RTCP扩展报告（RTCP XR）块类型注册表的新IANA注册表：IDMS XR块SPST注册表。
Initial values for the IDMS XR Block SPST Registry are given below; future assignments are to be made through the Specification Required policy [RFC5226]. The registry is limited to 16 entries (numbered 0-15), with 0 being Reserved. Values 5-15 are available for assignment.
IDMS XR Block SPST注册表的初始值如下所示；未来的分配将通过规范要求的政策[RFC5226]进行。注册表限制为16个条目（编号为0-15），保留0个条目。值5-15可用于赋值。
In accordance with [RFC5226], a Designated Expert will review any applications made to IANA for the registry. Primary criteria for the Designated Expert to use when reviewing new applications are clarity
根据[RFC5226]，指定专家将审查向IANA提出的注册申请。指定专家在审查新申请时使用的主要标准是清晰性
of the specification and, due to the relatively small value range of SPST values available, potential overlap in functionality with existing SPST registrations.
由于可用SPST值的相对较小的值范围，可能与现有SPST注册的功能重叠。
Value Name Reference
----- ---- ---------
1 Synchronization Client This document, Section 7
2 MSAS [TS183063]
3 SC Prime Input [TS183063]
4 SC Prime Output [TS183063]
Value Name Reference
----- ---- ---------
1 Synchronization Client This document, Section 7
2 MSAS [TS183063]
3 SC Prime Input [TS183063]
4 SC Prime Output [TS183063]
The contact information for the registrations is:
注册的联系信息为：
Ray van Brandenburg (ray.vanbrandenburg@tno.nl) Brassersplein 2 2612CT, Delft, The Netherlands
雷·范·勃兰登堡（雷。vanbrandenburg@tno.nl)Brasserspein 2 2612克拉，代尔夫特，荷兰
The following people have provided substantial contributions to this document: Omar Niamut, Fabian Walraven, Ishan Vaishnavi, and Rufael Mekuria. In addition, the authors would like to thank Aidan Williams, Colin Perkins, Magnus Westerlund, Roni Even, Peter Musgrave, Ali Begen, Qin Wu, and Rob Koenen for their review comments and contributions to the text.
以下人士对本文件做出了重大贡献：Omar Niamut、Fabian Walraven、Ishan Vaishnavi和Rufael Mekuria。此外，作者还要感谢艾丹·威廉姆斯、科林·帕金斯、马格努斯·韦斯特隆德、甚至罗尼、彼得·马斯格雷夫、阿里·贝根、秦武和罗布·科恩对本文的评论和贡献。
[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月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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月。
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, June 2014.
[RFC7273]Williams，A.，Gross，K.，van Brandenburg，R.，和H.Stokking，“RTP时钟源信令”，RFC 72732014年6月。
[Boronat2009] Boronat, F., Lloret, J., and M. Garcia, "Multimedia group and inter-stream synchronization techniques: a comparative study", Elsevier Information Systems 34, Pages 108-131, March 2009, <http://www.sciencedirect.com/science/article/pii/ S0306437908000525>.
[Boronat 2009]Boronat，F.，Lloret，J.，和M.Garcia，“多媒体组和流间同步技术：比较研究”，爱思唯尔信息系统34，第108-131页，2009年3月<http://www.sciencedirect.com/science/article/pii/ S030643908000525>。
[IEEE1588-2008] IEEE, "1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", July 2008, <http://standards.ieee.org/findstds/ standard/1588-2008.html>.
[IEEE1588-2008]IEEE，“1588-2008-网络测量和控制系统精密时钟同步协议的IEEE标准”，2008年7月<http://standards.ieee.org/findstds/ 标准/1588-2008.html>。
[Ishibashi2006] Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective assessment of fairness among users in multipoint communications", Proceedings of the 2006 ACM SIGCHI international conference on Advances in computer entertainment technology, Article No. 69, June 2006, <http://dl.acm.org/citation.cfm?id=1178905>.
[Ishibashi 2006]Ishibashi，Y.，Nagasaka，M.，和N.Fujiyoshi，“多点通信中用户公平性的主观评估”，2006年ACM SIGCHI国际计算机娱乐技术进步会议论文集，第69条，2006年6月<http://dl.acm.org/citation.cfm?id=1178905>.
[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, March 2014.
[RFC7164]Gross，K.和R.Brandenburg，“RTP和闰秒”，RFC 7164，2014年3月。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, April 2014.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，2014年4月。
[TS183063] ETSI, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification", TS 183 063 v3.5.2, March 2011.
[TS183063]ETSI，“用于高级网络的电信和互联网融合服务和协议（TISPAN）；基于IMS的IPTV第3阶段规范”，TS 183063 v3.5.22011年3月。
Authors' Addresses
作者地址
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 EMail: ray.vanbrandenburg@tno.nl
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT荷兰电话：+31-88-866-7000电子邮件：Ray。vanbrandenburg@tno.nl
Hans Stokking TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 EMail: hans.stokking@tno.nl
Hans Stokking TNO Brassersplein 2 Delft 2612CT荷兰电话：+31-88-866-7000电子邮件：Hans。stokking@tno.nl
M. Oskar van Deventer TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 EMail: oskar.vandeventer@tno.nl
M.Oskar van Deventer TNO Brassersplein 2 Delft 2612CT荷兰电话：+31-88-866-7000电子邮件：Oskar。vandeventer@tno.nl
Fernando Boronat Universitat Politecnica de Valencia (UPV) Valencia 46730 Spain Phone: +34 962 849 341 EMail: fboronat@dcom.upv.es
费尔南多·博罗纳特大学巴伦西亚理工学院（UPV）巴伦西亚46730西班牙电话：+34962849341电子邮件：fboronat@dcom.upv.es
Mario Montagud Universitat Politecnica de Valencia (UPV) Valencia 46730 Spain Phone: +34 962 849 341 EMail: mamontor@posgrado.upv.es
马里奥·蒙塔古大学巴伦西亚理工学院（UPV）巴伦西亚46730西班牙电话：+34962849341电子邮件：mamontor@posgrado.upv.es
Kevin Gross AVA Networks Phone: +1-303-447-0517 EMail: Kevin.Gross@AVAnw.com
凯文·格罗斯·艾娃网络电话：+1-303-447-0517电子邮件：凯文。Gross@AVAnw.com