Internet Engineering Task Force (IETF) A. Williams
Request for Comments: 7273 Audinate
Category: Standards Track K. Gross
ISSN: 2070-1721 AVA Networks
R. van Brandenburg
H. Stokking
TNO
June 2014
Internet Engineering Task Force (IETF) A. Williams
Request for Comments: 7273 Audinate
Category: Standards Track K. Gross
ISSN: 2070-1721 AVA Networks
R. van Brandenburg
H. Stokking
TNO
June 2014
RTP Clock Source Signalling
RTP时钟源信令
Abstract
摘要
NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.
NTP格式的时间戳被几个RTP协议用于同步和统计测量。此备忘录指定了用于标识时间戳参考时钟源的会话描述协议（SDP）信令和用于标识多媒体会话中媒体时钟源的SDP信令。
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/rfc7273.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7273.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5
4.1. Clock Synchronisation . . . . . . . . . . . . . . . . . . 5
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . 6
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . 6
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8
4.5. Private Reference Clocks . . . . . . . . . . . . . . . . 8
4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . 8
4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . 8
4.8. SDP Signalling of Timestamp Reference Clock Source . . . 9
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12
5.1. Asynchronously Generated Media Clock . . . . . . . . . . 12
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . 15
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19
6.1.1. Indicating Support for Clock Source Signalling . . . 20
6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20
6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22
8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 23
8.3. Timestamp Reference Clock Source Parameters Registry . . 23
8.4. Media Clock Source Parameters Registry . . . . . . . . . 24
8.5. Source-Level Attributes . . . . . . . . . . . . . . . . . 25
8.5.1. Source-Level Timestamp Reference Clock Attribute . . 25
8.5.2. Source-Level Media Clock Attribute . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5
4.1. Clock Synchronisation . . . . . . . . . . . . . . . . . . 5
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . 6
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . 6
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8
4.5. Private Reference Clocks . . . . . . . . . . . . . . . . 8
4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . 8
4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . 8
4.8. SDP Signalling of Timestamp Reference Clock Source . . . 9
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12
5.1. Asynchronously Generated Media Clock . . . . . . . . . . 12
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . 15
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19
6.1.1. Indicating Support for Clock Source Signalling . . . 20
6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20
6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22
8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 23
8.3. Timestamp Reference Clock Source Parameters Registry . . 23
8.4. Media Clock Source Parameters Registry . . . . . . . . . 24
8.5. Source-Level Attributes . . . . . . . . . . . . . . . . . 25
8.5.1. Source-Level Timestamp Reference Clock Attribute . . 25
8.5.2. Source-Level Media Clock Attribute . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 27
RTP protocols use NTP format timestamps to facilitate multimedia session synchronisation and to provide estimates of round-trip time (RTT) and other statistical parameters.
RTP协议使用NTP格式的时间戳来促进多媒体会话同步，并提供往返时间（RTT）和其他统计参数的估计。
Information about media clock timing exchanged in NTP format timestamps may come from a clock that is synchronised to a global time reference, but this cannot be assumed, nor is there a standardised mechanism available to indicate that timestamps are derived from a common reference clock. Therefore, RTP implementations typically assume that NTP timestamps are taken using unsynchronised clocks and must compensate for absolute time differences and rate differences. Without a shared reference clock, RTP can time align flows from the same source at a given receiver using relative timing; however, tight synchronisation between two or more different receivers (possibly with different network paths) or between two or more senders is not possible.
关于以NTP格式时间戳交换的媒体时钟定时的信息可能来自与全局时间基准同步的时钟，但不能假设这一点，也没有可用的标准化机制来指示时间戳源自公共基准时钟。因此，RTP实现通常假设NTP时间戳是使用非同步时钟获取的，并且必须补偿绝对时间差和速率差。在没有共享参考时钟的情况下，RTP可以使用相对定时在给定接收器处对来自同一源的流进行时间对齐；但是，两个或多个不同接收器（可能具有不同的网络路径）之间或两个或多个发送器之间不可能实现紧密同步。
High performance AV systems often use a reference media clock distributed to all devices in the system. The reference media clock may be distinct from the reference clock used to provide timestamps. A reference media clock may be provided along with an audio or video signal interface, or via a dedicated clock signal (e.g., genlock [SMPTE-318M-1999] or audio word clock [AES11-2009]). If sending and receiving media clocks are known to be synchronised to a common reference clock, performance can be improved by minimising buffering and avoiding rate conversion.
高性能AV系统通常使用分配给系统中所有设备的参考媒体时钟。参考媒体时钟可以不同于用于提供时间戳的参考时钟。参考媒体时钟可与音频或视频信号接口一起提供，或通过专用时钟信号提供（例如，genlock[SMPTE-318M-1999]或音频字时钟[AES11-2009]）。如果已知发送和接收媒体时钟与公共参考时钟同步，则可以通过最小化缓冲和避免速率转换来提高性能。
This specification defines SDP signalling of timestamp reference clock sources and media reference clock sources.
本规范定义了时间戳参考时钟源和媒体参考时钟源的SDP信令。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Timestamp reference clock source and media clock signalling benefit applications requiring synchronised media capture or playout and low latency operation.
时间戳参考时钟源和媒体时钟信号有利于需要同步媒体捕获或播放以及低延迟操作的应用。
Examples include, but are not limited to:
示例包括但不限于：
Social TV: "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)" [RFC7272] defines social TV as the combination of media content consumption by two or more users at different devices and locations and real-time communication between those users. An example of social TV is where two or more users are watching the same television broadcast at different devices and/or locations while communicating with each other using text, audio, and/or video. A skew in the media playout of the two or more users 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 other friends.
社交电视：“使用RTP控制协议（RTCP）的目的地间媒体同步（IDMS）”[RFC7272]将社交电视定义为两个或多个用户在不同设备和位置的媒体内容消费以及这些用户之间的实时通信的组合。社交电视的一个示例是，两个或多个用户在不同的设备和/或位置观看相同的电视广播，同时使用文本、音频和/或视频彼此通信。两个或两个以上的用户在媒体播放中的倾斜可能会对他们的体验产生不利影响。这里一个众所周知的用例是一个朋友在其他朋友之前或之后经历了一场足球比赛中的进球。
Video Walls: A video wall consists of multiple computer monitors, video projectors, or television sets tiled together contiguously or overlapped in order to form one large screen. Each of the screens reproduces a portion of the larger picture. In some implementations, each screen or projector 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 50 or 60 hertz or potentially faster. If the refresh is not synchronised, the effect of multiple screens acting as one is broken.
视频墙：视频墙由多台计算机显示器、视频投影仪或电视机组成，它们连续或重叠地拼接在一起，形成一个大屏幕。每一个屏幕都再现了大图的一部分。在一些实现中，每个屏幕或投影仪可以单独连接到网络，并从网络连接的视频服务器或视频定标器接收其整体图像的部分。屏幕刷新频率为50或60赫兹或可能更快。如果刷新不同步，则会破坏多个屏幕作为一个屏幕的效果。
Networked Audio: Networked loudspeakers, amplifiers, and analogue input/output (I/O) devices transmitting or receiving audio signals via RTP can be connected to various parts of a building or campus network. 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, 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 [Olsen].
网络音频：通过RTP传输或接收音频信号的网络扬声器、放大器和模拟输入/输出（I/O）设备可以连接到建筑物或校园网的各个部分。例如，在大型会议室、立法会议厅、教室（特别是支持远程学习的教室）和其他大型环境（如体育场）中可以发现这种情况。由于人类对音频延迟的差异更加敏感，因此该用例比视频墙用例需要更高的准确性。根据具体应用情况，对精度的要求可能在微秒[Olsen]范围内。
Sensor Arrays: Sensor arrays contain many synchronised measurement elements producing signals that are then combined to form an overall measurement. Accurate capture of the phase relationships between the various signals arriving at each element of the array is critically important for proper operation. Examples include towed or fixed sonar arrays, seismic arrays, and phased arrays used in radar applications, for instance.
传感器阵列：传感器阵列包含许多同步测量元件，这些元件产生信号，然后将这些信号组合起来形成整体测量。准确捕获到达阵列每个元素的各种信号之间的相位关系对于正确操作至关重要。例如，在雷达应用中使用的拖曳式或固定式声纳阵列、地震阵列和相控阵。
The following definitions are used in this document:
本文件中使用了以下定义：
media level: Media-level information applies to a single SDP media stream. In an SDP description, media-level information appears after each "m"-line.
媒体级别：媒体级别信息应用于单个SDP媒体流。在SDP描述中，媒体级别信息显示在每个“m”行之后。
multimedia session: A set of multimedia senders and receivers as well as the data streams flowing from senders to receivers. SDP [RFC4566] describes multimedia sessions.
多媒体会话：一组多媒体发送方和接收方，以及从发送方流向接收方的数据流。SDP[RFC4566]描述多媒体会话。
RTP media stream: A single stream of RTP packets identified by an RTP Synchronisation Source (SSRC).
RTP媒体流：由RTP同步源（SSRC）标识的单个RTP数据包流。
RTP sender: The device generating an associated RTP media stream.
RTP发送方：生成关联RTP媒体流的设备。
session level: Session-level information applies to an entire multimedia session. In an SDP description, session-level information appears before the first "m"-line.
会话级别：会话级别信息适用于整个多媒体会话。在SDP描述中，会话级别信息显示在第一个“m”行之前。
source level: Source-level information applies to a specific RTP media stream. "Source-Specific Media Attributes in the Session Description Protocol (SDP)" [RFC5576] defines how source-level information is included into an SDP session description.
源级别：源级别信息应用于特定RTP媒体流。“会话描述协议（SDP）中特定于源的媒体属性”[RFC5576]定义如何将源级别信息包括在SDP会话描述中。
traceable time: A clock is considered to provide traceable time if it can be proven to be synchronised to International Atomic Time (TAI). Coordinated Universal Time (UTC) is a time standard synchronised to TAI. UTC is, therefore, also considered traceable time once leap seconds have been taken into account. GPS [IS-GPS-200F] is commonly used to provide a TAI traceable time reference. Some network time synchronisation protocols (e.g., Precision Time Protocol (PTP) [IEEE1588-2008] and NTP) can explicitly indicate that the master clock is providing a traceable time reference over the network.
可追溯时间：如果可以证明时钟与国际原子时（TAI）同步，则认为时钟可提供可追溯时间。协调世界时（UTC）是与TAI同步的时间标准。因此，一旦考虑到闰秒，UTC也被视为可追踪时间。GPS[IS-GPS-200F]通常用于提供TAI可追踪时间参考。一些网络时间同步协议（例如，精确时间协议（PTP）[IEEE1588-2008]和NTP）可以明确指示主时钟通过网络提供可追踪的时间基准。
The NTP format timestamps used by RTP are taken by reading a local real-time clock at the sender or receiver. This local clock may be synchronised to another clock (time source) by some means, or it may be unsynchronised. A variety of methods are available to synchronise local clocks to a reference time source, including network time protocols (e.g., NTP [RFC5905] and PTP [IEEE1588-2008]) and radio clocks (e.g., GPS [IS-GPS-200F]).
RTP使用的NTP格式时间戳是通过读取发送方或接收方的本地实时时钟获取的。该本地时钟可以通过某种方式与另一个时钟（时间源）同步，也可以不同步。有多种方法可用于将本地时钟同步到参考时间源，包括网络时间协议（例如，NTP[RFC5905]和PTP[IEEE1588-2008]）和无线电时钟（例如，GPS[IS-GPS-200F]）。
The following sections describe and define SDP signalling, indicating whether and how the local timestamping clock in an RTP sender or receiver is synchronised to a reference clock.
以下各节描述和定义SDP信令，指示RTP发送器或接收器中的本地时间戳时钟是否以及如何与参考时钟同步。
Two or more local clocks that are sufficiently synchronised will produce timestamps for a given RTP event that can be used as if they came from the same clock. Timestamps produced in one RTP sender or receiver can be directly compared to a local clock in another RTP sender or receiver.
两个或多个充分同步的本地时钟将为给定RTP事件生成时间戳，该时间戳可以像来自同一时钟一样使用。一个RTP发送器或接收器中产生的时间戳可以直接与另一个RTP发送器或接收器中的本地时钟进行比较。
The accuracy of synchronisation required is application dependent. See "Applications" (Section 2) for a discussion of applications and their corresponding requirements. To serve as a reference clock, clocks must minimally be "syntonised" (exactly frequency matched) to one another.
所需的同步精度取决于应用。有关应用及其相应要求的讨论，请参见“应用”（第2节）。要用作参考时钟，时钟之间必须至少“同步”（精确频率匹配）。
Sufficient synchronisation can typically be achieved by using a network time protocol (e.g., NTP, 802.1AS, and IEEE 1588-2008) to synchronise all devices to a single master clock.
通常可以通过使用网络时间协议（例如NTP、802.1AS和IEEE 1588-2008）将所有设备同步到单个主时钟来实现充分的同步。
Another approach is to use clocks providing a global time reference (e.g., GPS, Galileo, and GLONASS). This concept may be used in conjunction with network time protocols as some protocols (e.g., PTP and NTP) allow master clocks to indicate explicitly that they are providing traceable time.
另一种方法是使用提供全球时间基准的时钟（例如GPS、伽利略和GLONASS）。此概念可与网络时间协议结合使用，因为某些协议（如PTP和NTP）允许主时钟明确指示它们提供可追踪时间。
A single NTP server is identified by a hostname (or IP address) and an optional port number. If the port number is not indicated, it is assumed to be the standard NTP port (123).
单个NTP服务器由主机名（或IP地址）和可选端口号标识。如果未显示端口号，则假定为标准NTP端口（123）。
Two or more NTP servers MAY be listed at the same level in the session description to indicate that all of the listed servers deliver the same reference time and may be used interchangeably. RTP senders and receivers are assured proper synchronisation regardless of which server they choose and, in support of fault tolerance, may switch servers while streaming.
两个或多个NTP服务器可以在会话描述中的同一级别列出，以指示所有列出的服务器提供相同的参考时间，并且可以互换使用。RTP发送方和接收方可以确保正确的同步，无论他们选择哪台服务器，并且为了支持容错，可以在流传输时切换服务器。
The Precision Time Protocol (PTP) as standardised in IEEE 1588 provides a shared reference clock in a network. IEEE 1588 provides sub-microsecond synchronisation between devices on a LAN and typically locks within seconds at startup. With support from Ethernet switches, IEEE 1588 protocols can achieve nanosecond timing
IEEE 1588标准化的精密时间协议（PTP）在网络中提供了一个共享参考时钟。IEEE 1588在局域网上的设备之间提供亚微秒级的同步，并且通常在启动时在几秒钟内锁定。在以太网交换机的支持下，IEEE 1588协议可以实现纳秒计时
accuracy in LANs. Network interface chips and cards supporting hardware timestamping of timing-critical protocol messages are also available.
局域网的准确性。还提供支持定时关键协议消息的硬件时间戳的网络接口芯片和卡。
Three flavours of IEEE 1588 are in use today:
目前，IEEE 1588有三种风格：
o IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". This is also known as IEEE1588v1 or PTPv1.
o IEEE 1588-2002[IEEE1588-2002]：最初的“网络化测量和控制系统精密时钟同步协议标准”。这也称为IEEE1588v1或PTPv1。
o IEEE 1588-2008 [IEEE1588-2008]: the second version of the "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". This is a revised version of the original IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002.
o IEEE 1588-2008[IEEE1588-2008]：第二版“网络化测量和控制系统精密时钟同步协议标准”。这是原始IEEE1588-2002标准的修订版，也称为IEEE1588v2或PTPv2。IEEE 1588-2008与IEEE 1588-2002的协议不兼容。
o IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for Time Sensitive Applications in Bridged Local Area Networks". This is a profile of IEEE 1588-2008 that is Layer 2 only and is for use in Audio/Video Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011].
o IEEE 802.1AS[IEEE802.1AS-2011]：“桥接局域网中时间敏感应用的定时和同步”。这是IEEE 1588-2008的配置文件，仅为第2层，用于IEEE 802.1BA-2011[IEEE802.1BA-2011]中所述的音频/视频桥接LAN。
Each IEEE 1588 clock is identified by a 64-bit Extended Unique Identifier (EUI-64) called a "ClockIdentity". A slave clock using one of the IEEE 1588 family of network time protocols acquires the ClockIdentity of the grandmaster clock that is the ultimate source of timing information for the network. A boundary clock, which is itself slaved to another boundary clock, or the grandmaster passes the grandmaster ClockIdentity through to its slaves.
每个IEEE 1588时钟由一个称为“时钟标识”的64位扩展唯一标识符（EUI-64）标识。使用IEEE 1588系列网络时间协议之一的从时钟获取作为网络时间信息最终来源的主时钟的时钟标识。边界时钟，它本身是另一个边界时钟的奴隶，或者大师将大师的时钟身份传递给它的奴隶。
Several instances of the IEEE 1588 protocol may operate independently on a single network, forming distinct PTP domains, each of which may have a different grandmaster clock. As the IEEE 1588 standards have evolved, the definition of PTP domains has changed. IEEE 1588-2002 identifies protocol subdomains by a textual name, but IEEE 1588-2008 identifies protocol domains using a numeric domain number. 802.1AS is a Layer 2 profile of IEEE 1588-2008 supporting a single numeric clock domain (0).
IEEE 1588协议的几个实例可在单个网络上独立运行，形成不同的PTP域，每个PTP域可具有不同的主时钟。随着IEEE 1588标准的发展，PTP域的定义发生了变化。IEEE 1588-2002通过文本名称标识协议子域，但IEEE 1588-2008使用数字域名标识协议域。802.1AS是IEEE 1588-2008的第2层配置文件，支持单个数字时钟域（0）。
When PTP domains are signalled via SDP, senders and receivers SHOULD check that both grandmaster ClockIdentity and the PTP domain match when determining clock equivalence.
当PTP域通过SDP发出信号时，发送方和接收方应在确定时钟等效性时检查grandmaster ClockIdentity和PTP域是否匹配。
Two or more IEEE 1588 clocks MAY be listed at the same level in the session description to indicate that all of the listed clocks are candidate grandmaster clocks for the domain or deliver the same reference time and may be used interchangeably. RTP senders and
两个或多个IEEE 1588时钟可以在会话描述中的相同级别上列出，以指示所有列出的时钟都是域的候选主时钟，或者提供相同的参考时间，并且可以互换使用。RTP发送器和
receivers are assured proper synchronisation regardless of which synchronisation source they choose and, in support of fault tolerance, may switch the reference clock source while streaming.
无论选择哪种同步源，接收器都能确保正确的同步，并且，为了支持容错，可以在流传输时切换参考时钟源。
The PTP protocols employ a distributed election protocol called the "Best Master Clock Algorithm" (BMCA) to determine the active clock master. The clock master choices available to BMCA can be restricted or biased by configuration parameters to influence the election process. In some systems, it may be desirable to limit the number of possible PTP clock masters to avoid the need to re-signal timestamp reference clock sources when the clock master changes.
PTP协议采用一种称为“最佳主时钟算法”（BMCA）的分布式选择协议来确定活动主时钟。BMCA可用的时钟主机选择可能受到配置参数的限制或偏差，从而影响选择过程。在一些系统中，可能希望限制可能的PTP时钟主控器的数量，以避免在时钟主控器改变时需要重新发送时间戳参考时钟源信号。
Global reference clocks provide a source of traceable time, typically via a hardware radio receiver interface. Examples include GPS, Galileo, and GLONASS. Apart from the name of the reference clock system, no further identification is required.
全局参考时钟通常通过硬件无线电接收器接口提供可追踪时间的来源。例如GPS、伽利略和GLONASS。除参考时钟系统的名称外，无需进一步识别。
In other systems, all RTP senders and receivers may use a timestamp reference clock that is not provided by one of the methods listed above. Examples may include the reference time information provided by digital television or cellular services. These sources are identified as "private" reference clocks. All RTP senders and receivers in a session using a private reference clock are assumed to have a mechanism outside this specification for determining whether their timestamp reference clocks are equivalent.
在其他系统中，所有RTP发送器和接收器可以使用时间戳参考时钟，该时钟不是由上面列出的方法之一提供的。示例可包括由数字电视或蜂窝服务提供的参考时间信息。这些源被标识为“专用”参考时钟。假定会话中使用专用参考时钟的所有RTP发送方和接收方具有本规范之外的机制，用于确定其时间戳参考时钟是否等效。
[RFC3550] allows senders and receivers to either use a local wallclock reference for their NTP timestamps or, by setting the timestamp field to 0, supply no timestamps at all. Both are common practice in embedded RTP implementations. These clocks are identified as "local" and can, at best, be assumed to be equivalent to clocks originating from the same device.
[RFC3550]允许发送方和接收方对其NTP时间戳使用本地wallclock参考，或者通过将时间戳字段设置为0，完全不提供时间戳。两者都是嵌入式RTP实现中的常见做法。这些时钟被标识为“本地”时钟，充其量可以假定为等同于源自同一设备的时钟。
A timestamp reference clock source may be labelled "traceable" if it is known to be delivering traceable time, provided adjustments are made for differing epochs, timezones, and leap seconds. Timestamps taken using clocks synchronised to a traceable time source can be directly compared even if the clocks are synchronised to different sources or via different mechanisms.
如果已知时间戳参考时钟源提供可跟踪时间，则可将其标记为“可跟踪”，前提是针对不同的纪元、时区和闰秒进行调整。使用与可追踪时间源同步的时钟获取的时间戳可以直接进行比较，即使时钟与不同的源或通过不同的机制同步。
Marking a clock as traceable allows additional information (e.g., IP addresses, PTP master identifiers, and the like) to be omitted from the SDP since any traceable clock available at the answerer is considered to be an appropriate timestamp reference clock. For example, an offerer could specify ts-refclk:ntp=/traceable/ and the answerer could use GPS as a reference clock since GPS is a source of traceable time.
将时钟标记为可追踪允许从SDP中省略附加信息（例如，IP地址、PTP主标识符等），因为应答器处可用的任何可追踪时钟被认为是适当的时间戳参考时钟。例如，报价人可以指定ts refclk:ntp=/traceable/，而应答人可以使用GPS作为参考时钟，因为GPS是可追踪时间的来源。
Specification of the timestamp reference clock source may be at any or all levels (session, media, or source) of an SDP description (see level definitions in Section 3 earlier in this document for more information).
时间戳参考时钟源的规范可以是SDP描述的任何或所有级别（会话、媒体或源）（有关更多信息，请参阅本文档前面第3节中的级别定义）。
Timestamp reference clock source signalling included at the session level provides default parameters for all RTP sessions and sources in the session description. More specific signalling included at the media level overrides session-level signalling. More specific signalling included at the source level overrides media-level signalling.
会话级别包含的时间戳参考时钟源信令为会话描述中的所有RTP会话和源提供默认参数。媒体级包含的更具体的信令覆盖会话级信令。源级别包含的更具体的信令覆盖媒体级别的信令。
If timestamp reference clock source signalling is included anywhere in an SDP description, it must be properly defined for all levels in the description. This may simply be achieved by providing default signalling at the session level.
如果时间戳参考时钟源信令包括在SDP描述中的任何位置，则必须为描述中的所有级别正确定义它。这可以简单地通过在会话级别提供默认信令来实现。
Timestamp reference clock parameters may be repeated at a given level (i.e., for a session or source) to provide information about additional servers or clock sources. If the attribute is repeated at a given level, all clocks described at that level are assumed to be equivalent. Traceable time sources MUST NOT be mixed with non-traceable time sources at any given level.
时间戳参考时钟参数可以在给定级别（即，对于会话或源）重复，以提供关于附加服务器或时钟源的信息。如果在给定级别重复该属性，则假定在该级别描述的所有时钟都是等效的。可追溯时间源不得与任何给定级别的不可追溯时间源混合使用。
Note that clock source parameters may change from time to time, for example, as a result of a PTP grandmaster election. SIP [RFC3261] supports the re-signalling of updated SDP information; however, other protocols may require additional notification mechanisms.
请注意，时钟源参数可能会不时更改，例如，PTP特级大师选举的结果。SIP[RFC3261]支持更新的SDP信息的重新信令；然而，其他协议可能需要额外的通知机制。
General forms of usage:
一般用法：
session level: a=ts-refclk:<clksrc>
session level: a=ts-refclk:<clksrc>
media level: a=ts-refclk:<clksrc>
media level: a=ts-refclk:<clksrc>
source level: a=ssrc:<ssrc-id> ts-refclk:<clksrc>
source level: a=ssrc:<ssrc-id> ts-refclk:<clksrc>
ABNF [RFC5234] grammar for the timestamp reference clock attribute:
时间戳参考时钟属性的ABNF[RFC5234]语法：
; external references:
POS-DIGIT = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
CRLF = <See RFC 5234>
hostport = <See RFC 3261, with revisions from RFC 5954>
; external references:
POS-DIGIT = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
CRLF = <See RFC 5234>
hostport = <See RFC 3261, with revisions from RFC 5954>
timestamp-refclk = "ts-refclk:" clksrc CRLF
时间戳refclk=“ts refclk:”clksrc CRLF
clksrc = ntp / ptp / gps / gal / glonass / local / private /
clksrc-ext
clksrc = ntp / ptp / gps / gal / glonass / local / private /
clksrc-ext
clksrc-ext = clksrc-param-name clksrc-param-value
clksrc-param-name = token
clksrc-param-value = ["=" byte-string ]
clksrc-ext = clksrc-param-name clksrc-param-value
clksrc-param-name = token
clksrc-param-value = ["=" byte-string ]
ntp = "ntp=" ntp-server-addr
ntp-server-addr = hostport / "/traceable/"
ntp = "ntp=" ntp-server-addr
ntp-server-addr = hostport / "/traceable/"
ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002"
/ "IEEE1588-2008"
/ "IEEE802.1AS-2011"
/ ptp-version-ext
ptp-version-ext = token
ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002"
/ "IEEE1588-2008"
/ "IEEE802.1AS-2011"
/ ptp-version-ext
ptp-version-ext = token
ptp-server = ptp-gmid [":" ptp-domain]
/ "traceable"
ptp-gmid = EUI64
ptp-domain = ptp-domain-name / ptp-domain-nmbr
ptp-server = ptp-gmid [":" ptp-domain]
/ "traceable"
ptp-gmid = EUI64
ptp-domain = ptp-domain-name / ptp-domain-nmbr
; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-name = "domain-name=" 1*16ptp-domain-char
ptp-domain-char = %x21-7E
; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-name = "domain-name=" 1*16ptp-domain-char
ptp-domain-char = %x21-7E
; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
ptp-domain-n1 = DIGIT ; 0-9
ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99
ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119
/ "12" %x30-37 ; 120-127
; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
ptp-domain-n1 = DIGIT ; 0-9
ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99
ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119
/ "12" %x30-37 ; 120-127
gps = "gps"
gps = "gps"
gal = "gal" glonass = "glonass" local = "local" private = "private" [ ":traceable" ]
gal=“gal”glonass=“glonass”local=“local”private=“private”[“：可追踪”]
EUI64 = 7(2HEXDIG "-") 2HEXDIG
EUI64=7（2HEXDIG“-”）2HEXDIG
Figure 1: Timestamp Reference Clock Source Signalling
图1：时间戳参考时钟源信令
Figure 2 shows an example SDP description with a timestamp reference clock source defined at the session level.
图2显示了一个示例SDP描述，其中在会话级别定义了一个时间戳参考时钟源。
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:ntp=/traceable/
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:ntp=/traceable/
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
Figure 2: Timestamp Reference Clock Definition at the Session Level
图2：会话级别的时间戳参考时钟定义
Figure 3 shows an example SDP description with timestamp reference clock definitions at the media level overriding the session-level defaults.
图3显示了一个示例SDP描述，其中媒体级别的时间戳参考时钟定义覆盖了会话级别的默认值。
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
a=ts-refclk:ntp=203.0.113.10
a=ts-refclk:ntp=198.51.100.22
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
a=ts-refclk:ntp=203.0.113.10
a=ts-refclk:ntp=198.51.100.22
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 3: Timestamp Reference Clock Definition at the Media Level
图3：媒体级别的时间戳参考时钟定义
Figure 4 shows an example SDP description with a timestamp reference clock definition at the source level overriding the session-level default.
图4显示了一个示例SDP描述，其中源级别的时间戳参考时钟定义覆盖了会话级别的默认值。
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 4: Timestamp Reference Clock Signalling at the Source Level
图4：源级的时间戳参考时钟信令
The media clock source for a stream determines the timebase used to advance the RTP timestamps included in RTP packets. The media clock may be asynchronously generated by the sender, it may be generated in fixed relationship to the reference clock, or it may be generated with respect to another stream on the network (which is presumably being received by the sender).
流的媒体时钟源确定用于提前RTP分组中包括的RTP时间戳的时基。媒体时钟可以由发送方异步生成，可以以与参考时钟的固定关系生成，或者可以相对于网络上的另一个流生成（该流可能由发送方接收）。
In the simplest sender implementation, the sender generates media by sampling audio or video according to a free-running local clock. The RTP timestamps in media packets are advanced according to this media clock, and packet transmission is typically timed to regular intervals on this timeline. The sender may or may not include an NTP timestamp in sender reports to allow mapping of this asynchronous media clock to a reference clock.
在最简单的发送器实现中，发送器通过根据自由运行的本地时钟对音频或视频进行采样来生成媒体。媒体分组中的RTP时间戳根据该媒体时钟提前，并且分组传输通常定时到该时间线上的规则间隔。发送方可以在发送方报告中包括或不包括NTP时间戳，以允许将该异步媒体时钟映射到参考时钟。
The asynchronously generated media clock is the assumed mode of operation when there is no signalling of the media clock source. Alternatively, an asynchronous media clock may be explicitly signalled.
当没有媒体时钟源的信号时，异步生成的媒体时钟是假定的操作模式。或者，可以显式地向异步媒体时钟发送信号。
a=mediaclk:sender
a=mediaclk:发送方
A media clock may be directly derived from a reference clock. For this case, it is required that a reference clock be specified with an a=ts-refclk attribute (Section 4.8).
媒体时钟可以直接从参考时钟导出。在这种情况下，要求使用a=ts refclk属性指定参考时钟（第4.8节）。
The signalling optionally indicates a media clock offset value. The offset indicates the RTP timestamp value at the epoch (time of origin) of the reference clock. To use the offset, implementations need to compute RTP timestamps from reference clocks. To simplify these calculations, streams utilizing offset signalling SHOULD use a TAI timestamp reference clock to avoid complications introduced by leap seconds. See [RFC7164] for further discussion of leap-second issues in timestamp reference clocks.
信令可选地指示媒体时钟偏移值。偏移量表示基准时钟的历元（起始时间）处的RTP时间戳值。要使用偏移量，实现需要从参考时钟计算RTP时间戳。为了简化这些计算，利用偏移信令的流应该使用TAI时间戳参考时钟，以避免闰秒带来的复杂性。有关时间戳参考时钟中闰秒问题的进一步讨论，请参见[RFC7164]。
To compute the RTP timestamp against an IEEE 1588 (TAI-based) reference, the time elapsed between the 00:00:00 1 January 1970 IEEE 1588 epoch and the current time must be computed. Between the epoch and 1 January 2013, there were 15,706 days (including extra days during leap years). Since there are no leap seconds in a TAI reference, there are exactly 86,400 seconds during each of these days or a total of 1,356,998,400 seconds from the epoch to 00:00:00 1
要根据IEEE 1588（基于TAI的）参考计算RTP时间戳，必须计算1970年1月1日00:00:00 IEEE 1588历元与当前时间之间经过的时间。从新纪元到2013年1月1日，共有15706天（包括闰年期间的额外天数）。由于TAI参考中没有闰秒，因此在这些天中的每一天中都有86400秒，或者从历元到00:00:00 1总共有1356998400秒
January 2013. A 90 kHz RTP clock for a video stream would have advanced 122,129,856,000,000 units over this period. With a signalled offset of 0, the RTP clock value modulo the 32-bit unsigned RTP timestamp representation in the RTP header would have been 2,460,938,240 at 00:00:00 1 January 2013. If an offset of 23,465 had been signalled, the clock value would have been 2,460,961,705.
2013年1月。在此期间，视频流的90 kHz RTP时钟将提高122129856000000个单位。如果信号偏移量为0，则RTP报头中32位无符号RTP时间戳表示的RTP时钟值在2013年1月1日00:00:00时为2460938240。如果发送了23465的偏移量信号，则时钟值应为2460961705。
In order to use an NTP reference, the actual time elapsed between the 00:00:00 1 January 1900 NTP epoch to the current time must be computed. 2,208,988,800 seconds elapsed between the NTP epoch and 00:00:00 1 January 1970 [RFC0868]. Between the beginning of 1970 and 2013, there were 15,706 days elapsed (including extra days during leap years) and 25 leap seconds inserted. There is, therefore, a total of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1 January 2013. A 90 kHz RTP clock for a video stream would have advanced 320,938,850,250,000 units over this period. With a signalled offset of 0, the RTP clock value modulo the 32-bit unsigned representation would have been 1,714,023,696 at 00:00:00 1 January 2013.
为了使用NTP参考，必须计算1900年1月1日00:00:00 NTP历元到当前时间之间经过的实际时间。NTP历元与1970年1月1日00:00:00之间经过2208988800秒[RFC0868]。从1970年初到2013年，共经过15706天（包括闰年期间的额外天数），并插入了25闰秒。因此，从NTP纪元到2013年1月1日00:00:00，总共有3565987225秒。在此期间，视频流的90 kHz RTP时钟将提高320938850250000个单位。如果信号偏移量为0，则以32位无符号表示为模的RTP时钟值在2013年1月1日00:00:00时为1714023696。
If no offset is signalled, the offset can be inferred at the receiver by examining RTCP sender reports that contain NTP and RTP timestamps, which combined define a mapping. The NTP/RTP timestamp mapping provided by RTCP sender reports (SRs) takes precedence over that signalled through SDP; however, the media clock rate implied by the SRs MUST be consistent with the rate signalled.
如果未发出任何偏移信号，则可通过检查包含NTP和RTP时间戳的RTCP发送方报告在接收方推断偏移量，这两个时间戳组合定义了映射。RTCP发送方报告（SRs）提供的NTP/RTP时间戳映射优先于通过SDP发出的信号；但是，SRs暗示的媒体时钟速率必须与信号速率一致。
A rate modifier may be specified. The modifier is expressed as the ratio of two integers and modifies the rate specified or implied by the media description by this ratio. If omitted, the rate is assumed to be the exact rate specified or implied by the media format. For example, without a rate specification, the RTP clock for an 8 kHz G.711 audio stream will advance exactly 8000 units for each second advance in the reference clock from which it is derived.
可以指定速率修饰符。修饰符表示为两个整数的比率，并通过该比率修改媒体描述中指定或暗示的速率。如果省略，则假定速率为媒体格式指定或暗示的准确速率。例如，在没有速率规范的情况下，8khz G.711音频流的RTP时钟将在从其导出的参考时钟中每秒钟精确前进8000个单位。
The rate modifier is primarily useful for accommodating certain "oddball" audio sample rates associated with NTSC video (see Figure 7). Modified rates are not advised for video streams that generally use a 90 kHz RTP clock regardless of frame rate or sample rate used for embedded audio.
rate修饰符主要用于调节与NTSC视频相关的某些“古怪”音频采样率（见图7）。对于通常使用90 kHz RTP时钟的视频流，无论用于嵌入式音频的帧速率或采样率如何，都不建议修改速率。
a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
denominator>]
a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
denominator>]
A common synchronisation architecture for audio/visual systems involves distributing a reference media clock from a master device to a number of slave devices, typically by means of a cable. Examples include audio word clock distribution and video black burst distribution. In this case, the media clock is locally generated, often by a crystal oscillator, and is not locked to a timestamp reference clock.
音频/视频系统的通用同步架构涉及通常通过电缆将参考媒体时钟从主设备分配到多个从设备。示例包括音频字时钟分布和视频黑突发分布。在这种情况下，媒体时钟通常由晶体振荡器本地生成，并且不锁定到时间戳参考时钟。
To support this architecture across a network, a master clock identifier is associated with an RTP media stream carrying media clock timing information from a master device. The master clock identifier represents a media clock source in the master device. Slave devices in turn associate the master media clock identifier with streams they transmit, signalling the synchronisation relationship between the master and the transmitter's media clock.
为了在网络上支持该架构，主时钟标识符与承载来自主设备的媒体时钟定时信息的RTP媒体流相关联。主时钟标识符表示主设备中的媒体时钟源。从属设备又将主媒体时钟标识符与它们传输的流相关联，以信号表示主媒体时钟和发射机媒体时钟之间的同步关系。
Slave devices recover media clock timing from the clock master stream, using it to synchronise the slave's media clock with the master. If a common reference clock is available, NTP timestamps in the master clock RTP media stream are taken using the shared reference clock. The NTP timestamps communicate information about media clock timing (rate and phase) from the master to the slave devices. NTP timestamps are communicated in the usual RTP fashion via RTCP SRs, or via the [RFC6051] header extension. If no shared reference clock is available or signalled, a slave can synchronise to the master's media clock using RTP timestamps alone as described in Section 5.1 of [RFC3550].
从设备从时钟主流恢复媒体时钟定时，使用它将从设备的媒体时钟与主设备同步。如果公共参考时钟可用，则使用共享参考时钟获取主时钟RTP媒体流中的NTP时间戳。NTP时间戳将有关媒体时钟定时（速率和相位）的信息从主设备传送到从设备。NTP时间戳通过RTCP SRs或[RFC6051]报头扩展以通常的RTP方式进行通信。如果没有共享参考时钟可用或发出信号，则从机可以按照[RFC3550]第5.1节中的说明，单独使用RTP时间戳与主机的媒体时钟同步。
Note that the slaving of a device media clock to a master device does not affect RTP inter-media synchronisation. Time-aligned playout of two or more RTP sources still relies upon NTP timestamps supplied via RTCP SRs or by the RFC 6051 timestamp header extension.
请注意，设备媒体时钟从属于主设备并不影响RTP媒体间同步。两个或多个RTP源的时间对齐播放仍然依赖于通过RTCP SRs或RFC 6051时间戳标头扩展提供的NTP时间戳。
In a given system, master clock identifiers must uniquely identify a single media clock source. Such identifiers MAY be manually configured; however, identifiers SHOULD be generated according to the "short-term persistent RTCP CNAME" algorithm as described in [RFC7022]. Master clock identifiers not already in base64 format MUST be encoded as base64 strings when used in SDP. Although the CNAME algorithm is used to generate the master clock identifier, it is used to tag RTP sources in SDP descriptions and does not appear in RTCP as a CNAME.
在给定系统中，主时钟标识符必须唯一标识单个媒体时钟源。这种标识符可以手动配置；但是，应根据[RFC7022]中所述的“短期持久RTCP CNAME”算法生成标识符。在SDP中使用时，尚未采用base64格式的主时钟标识符必须编码为base64字符串。尽管CNAME算法用于生成主时钟标识符，但它用于在SDP描述中标记RTP源，并且不会在RTCP中显示为CNAME。
A reference stream can be an RTP stream or an Audio Video Bridging (AVB) stream based on the [IEEE1722] standard.
参考流可以是基于[IEEE1722]标准的RTP流或音频视频桥接（AVB）流。
An RTP clock master stream SHOULD be identified at the source level by an SSRC [RFC5576] and master clock identifier. An RTP stream that provides media clock timing directly from a reference media clock (e.g., internal crystal, audio word clock, or video black burst signal) SHOULD tag the stream as a master clock source using the "src:" prefix. If master clock identifiers are declared at the media or session level, all RTP sources at or below the level of declaration MUST provide equivalent timing to a slave receiver.
RTP时钟主流应通过SSRC[RFC5576]和主时钟标识符在源级识别。直接从参考媒体时钟（例如，内部晶体、音频字时钟或视频黑突发信号）提供媒体时钟定时的RTP流应使用“src:”前缀将该流标记为主时钟源。如果在媒体或会话级别声明主时钟标识符，则声明级别或以下的所有RTP源必须向从属接收器提供等效的定时。
a=ssrc:<ssrc> mediaclk:id=src:<media-clktag> sender
a=ssrc:<ssrc> mediaclk:id=src:<media-clktag> sender
a=mediaclk:id=src:<media-clktag> sender
a=mediaclk:id=src:<media-clktag> sender
A transmitted RTP stream slaved to the media clock master is signalled by including a master clock identifier:
通过包括主时钟标识符，用信号通知从属于媒体时钟主机的传输RTP流：
a=mediaclk:id=<media-clktag> sender
a=mediaclk:id=<media-clktag> sender
An RTP media sender indicates that it is slaved to an IEEE 1722 clock master via a stream identifier (an EUI-64):
RTP媒体发送器表示它通过流标识符（EUI-64）从属于IEEE 1722时钟主机：
a=mediaclk:IEEE1722=<StreamID>
a=mediaclk:IEEE1722=<StreamID>
An RTP media sender may gateway IEEE 1722 media clock timing to RTP:
RTP媒体发送器可以网关IEEE 1722媒体时钟定时到RTP：
a=mediaclk:id=src:<media-clktag> IEEE1722=<StreamID>
a=mediaclk:id=src:<media-clktag> IEEE1722=<StreamID>
Specification of the media clock source may be at any or all levels (session, media, or source) of an SDP description (see level definitions (Section 3) earlier in this document for more information).
媒体时钟源的规格可以是SDP描述的任何或所有级别（会话、媒体或源）（有关更多信息，请参阅本文档前面的级别定义（第3节））。
Media clock source signalling included at session level provides default parameters for all RTP sessions and sources in the session description. More specific signalling included at the media level overrides session-level signalling. Further, source-level signalling overrides media clock source signalling at the enclosing media level and session level.
会话级别包含的媒体时钟源信令为会话描述中的所有RTP会话和源提供默认参数。媒体级包含的更具体的信令覆盖会话级信令。此外，源级别信令覆盖封闭媒体级别和会话级别的媒体时钟源信令。
Media clock source signalling may be present or absent on a per-stream basis. In the absence of media clock source signals, receivers assume an asynchronous media clock generated by the sender.
媒体时钟源信令可以在每个流的基础上存在或不存在。在没有媒体时钟源信号的情况下，接收机假定发送方生成异步媒体时钟。
Media clock source parameters may be repeated at a given level (i.e., for a session or source) to provide information about additional clock sources. If the attribute is repeated at a given level, all
媒体时钟源参数可以在给定级别（即，对于会话或源）重复，以提供关于附加时钟源的信息。如果在给定级别重复该属性，则所有
clocks described at that level are comparable clock sources and may be used interchangeably.
在该级别描述的时钟是可比较的时钟源，并且可以互换使用。
General forms of usage:
一般用法：
session level: a=mediaclk:<mediaclock>
session level: a=mediaclk:<mediaclock>
media level: a=mediaclk:<mediaclock>
media level: a=mediaclk:<mediaclock>
source level: a=ssrc:<ssrc-id> mediaclk:<mediaclock>
source level: a=ssrc:<ssrc-id> mediaclk:<mediaclock>
ABNF [RFC5234] grammar for the media clock reference attribute:
媒体时钟参考属性的ABNF[RFC5234]语法：
; external references:
integer = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
base64 = <See RFC 4566>
SP = <See RFC 5234>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
; external references:
integer = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
base64 = <See RFC 4566>
SP = <See RFC 5234>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
media-clksrc = "mediaclk:" [media-clkid SP] mediaclock
media clksrc=“mediaclk:[media clkid SP]mediaclock
media-clkid = "id=" [ "src:" ] media-clktag
media-clktag = base64
media-clkid = "id=" [ "src:" ] media-clktag
media-clktag = base64
mediaclock = sender / direct / ieee1722-streamid / mediaclock-ext
mediaclock = sender / direct / ieee1722-streamid / mediaclock-ext
mediaclock-ext = mediaclock-param-name mediaclock-param-value
mediaclock-param-name = token
mediaclock-param-value = [ "=" byte-string ]
mediaclock-ext = mediaclock-param-name mediaclock-param-value
mediaclock-param-name = token
mediaclock-param-value = [ "=" byte-string ]
sender = "sender"
direct = "direct" [ "=" 1*DIGIT ] [SP rate]
rate = "rate=" integer "/" integer
sender = "sender"
direct = "direct" [ "=" 1*DIGIT ] [SP rate]
rate = "rate=" integer "/" integer
ieee1722-streamid = "IEEE1722=" avb-stream-id
avb-stream-id = EUI64
EUI64 = 7(2HEXDIG "-") 2HEXDIG
ieee1722-streamid = "IEEE1722=" avb-stream-id
avb-stream-id = EUI64
EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 5: Media Clock Source Signalling
图5：媒体时钟源信令
Figure 6 shows an example SDP description -- 8 channels of 24-bit, 48 kHz audio transmitted as a multicast stream. Media clock is derived directly from an IEEE 1588-2008 reference.
图6显示了一个示例SDP描述——作为多播流传输的8个24位48 kHz音频通道。媒体时钟直接来自IEEE 1588-2008参考。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/8
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/8
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424
Figure 6: Media Clock Directly Referenced to IEEE 1588-2008
图6：直接参考IEEE 1588-2008的媒体时钟
Figure 7 shows an example SDP description -- 2 channels of 24-bit, 44056 kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-2008 reference clock.
图7显示了示例SDP描述——直接从IEEE 1588-2008参考时钟导出的2个24位44056 kHz NTSC“下拉”媒体时钟通道。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/44100/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 rate=1000/1001
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/44100/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 rate=1000/1001
Figure 7: "Oddball" Sample Rate Directly Referenced to IEEE 1588-2008
图7：直接参考IEEE 1588-2008的“古怪”样本率
Figure 8 shows the same 48 kHz audio transmission from Figure 6 with media clock derived from another RTP stream.
图8显示了与图6相同的48 kHz音频传输，媒体时钟来自另一个RTP流。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender
Figure 8: RTP Stream with Media Clock Slaved to a Master
图8：媒体时钟从属于主机的RTP流
Figure 9 shows the same 48 kHz audio transmission from Figure 6 with media clock derived from an IEEE 1722 AVB stream.
图9显示了与图6相同的48 kHz音频传输，媒体时钟来自IEEE 1722 AVB流。
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
Figure 9: RTP Stream with Media Clock Slaved to an IEEE 1722 Master Device
图9：媒体时钟从属于IEEE 1722主设备的RTP流
Signalling of timestamp reference clock source (Section 4.8) and media clock source (Section 5.4) is defined to be used either by applications that implement the SDP Offer/Answer model [RFC3264] or by applications that use SDP to describe media and transport configurations.
时间戳参考时钟源（第4.8节）和媒体时钟源（第5.4节）的信令定义为由实现SDP提供/应答模型[RFC3264]的应用程序或使用SDP描述媒体和传输配置的应用程序使用。
A description SHOULD include both reference clock signalling and media clock signalling. If no reference clock is available, this SHOULD be signalled as a local reference (Section 4.6).
描述应包括参考时钟信号和媒体时钟信号。如果没有可用的参考时钟，则应将其作为本地参考发出信号（第4.6节）。
When no media clock signalling is present, an asynchronous media clock (Section 5.1) MUST be assumed. When no reference clock signalling is present, a local reference clock (Section 4.6) MUST be assumed.
当不存在媒体时钟信号时，必须假定为异步媒体时钟（第5.1节）。当不存在参考时钟信号时，必须假设本地参考时钟（第4.6节）。
If a reference clock is not signalled or a local reference is specified, the corresponding media clock may be established as rate synchronised with no assurance of time synchronisation.
如果未用信号通知参考时钟或指定了本地参考，则相应的媒体时钟可建立为速率同步，而不保证时间同步。
When the description signals a direct-referenced media clock (Section 5.2), reference clock signalling is REQUIRED. Asynchronous and stream-referenced media clocks (Section 5.3) MAY be specified with or without a reference clock signalling.
当描述信号为直接参考媒体时钟（第5.2节）时，需要参考时钟信号。异步和流参考媒体时钟（第5.3节）可在有或无参考时钟信号的情况下指定。
During offer/answer, clock source signalling via SDP uses a declarative model. Supported media and/or reference clocks are specified in the offered SDP description. The answerer may accept or reject the offer in an application-specific way depending on the clocks that are available and the clocks that are offered. For example, an answerer may choose to accept an offer that lacks a common clock by falling back to a lower-performance mode of operation (e.g., by assuming reference or media clocks are local rather than shared). Conversely, the answerer may choose to reject the offer when the offered clock specifications indicate that the available reference and/or media clocks are incompatible.
在提供/应答期间，通过SDP的时钟源信令使用声明性模型。所提供的SDP说明中指定了支持的介质和/或参考时钟。应答者可根据可用时钟和提供的时钟，以特定于应用的方式接受或拒绝报价。例如，应答者可以通过退回到性能较低的操作模式（例如，通过假设参考或媒体时钟是本地的而不是共享的）来选择接受缺少公共时钟的报价。相反，当提供的时钟规格表明可用的参考时钟和/或媒体时钟不兼容时，应答者可以选择拒绝提供。
While negotiation of reference clock and media clock attributes is not defined in this document, negotiation MAY be accomplished using the capabilities negotiation procedures defined in [RFC5939].
虽然参考时钟和媒体时钟属性的协商未在本文件中定义，但可使用[RFC5939]中定义的能力协商程序完成协商。
An offerer or answerer indicates support for media clock signalling by including a reference or media clock specification in the SDP description. An offerer or answerer without specific reference or media clocks to signal SHOULD indicate support for clock source signalling by including a local reference clock (Section 4.6) specification in the SDP description.
报价人或应答人通过在SDP描述中包括参考或媒体时钟规范来表示对媒体时钟信令的支持。没有特定参考时钟或媒体时钟信号的报价人或应答人应通过在SDP描述中包括本地参考时钟（第4.6节）规范来表示对时钟源信号的支持。
If one or more of the reference clocks specified in the offer are usable by the answerer, the answerer SHOULD respond with an answer containing the subset of reference clock specifications in the offer that are usable by the answerer. If the answerer rejects the offer because the available reference clocks are incompatible, the
如果报价中规定的一个或多个参考时钟可供应答者使用，则应答者应回复包含报价中可供应答者使用的参考时钟规范子集的答案。如果应答器拒绝报价，因为可用的参考时钟不兼容，则
rejection MUST contain at least one timestamp reference clock specification usable by the answerer so that appropriate information is available for diagnostics. If no external reference clock is available to the answerer, a local reference clock (Section 4.6) specification SHOULD be included in the rejection.
拒绝必须包含至少一个应答者可用的时间戳参考时钟规范，以便为诊断提供适当的信息。如果应答人没有可用的外部参考时钟，则拒绝中应包括本地参考时钟（第4.6节）规范。
In both offers and answers, multiple reference clock specifications indicate equivalent clocks from different sources that may be used interchangeably. RTP senders and receivers are assured proper synchronisation regardless of which of the specified sources is chosen and, in support of fault tolerance, may switch clock sources while streaming.
在报价和应答中，多个参考时钟规格表示来自不同来源的可互换使用的等效时钟。RTP发送器和接收器确保正确同步，无论选择了哪种指定源，并且为了支持容错，可以在流传输时切换时钟源。
If the media clock mode specified in the offer is acceptable to the answerer, the answerer SHOULD respond with an answer containing the same media clock specification as the offer. If the answerer rejects the offer because the available reference clocks are incompatible, the rejection MUST contain a media clock specification supported by the answerer so that appropriate information is available for diagnostics. If no shared media clocks are available to the answerer, an asynchronous media clock (Section 5.1) specification SHOULD be included in the rejection.
如果报价中规定的媒体时钟模式为应答者所接受，则应答者应回复包含与报价相同的媒体时钟规格的答案。如果应答者因可用参考时钟不兼容而拒绝报价，则拒绝必须包含应答者支持的媒体时钟规范，以便提供适当的信息进行诊断。如果应答者没有可用的共享介质时钟，则应在拒绝中包括异步介质时钟（第5.1节）规范。
SDP can be employed outside of the offer/answer context, for instance, for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [RFC2974] or streamed through the Real Time Streaming Protocol (RTSP) [RFC2326].
SDP可在提供/应答上下文之外使用，例如，用于通过会话公告协议（SAP）[RFC2974]宣布或通过实时流协议（RTSP）[RFC2326]流传输的多媒体会话。
Devices using published descriptions to join sessions SHOULD assess their synchronisation compatibility with the described session based on the clock source signalling and SHOULD NOT attempt to join a session with incompatible reference or media clocks.
使用已发布描述加入会话的设备应基于时钟源信令评估其与所述会话的同步兼容性，并且不应尝试加入具有不兼容参考时钟或媒体时钟的会话。
Entities receiving and acting upon an SDP message should note that a session description cannot be trusted unless it has been obtained by an authenticated transport protocol from a known and trusted source. Many different transport protocols may be used to distribute a session description, and the nature of the authentication will differ from transport to transport. For some transports, security features are often not deployed. In case a session description has not been obtained in a trusted manner, the endpoint should exercise care because, among other attacks, the media sessions received may not be
接收SDP消息并对其采取行动的实体应注意，除非会话描述是通过经过身份验证的传输协议从已知和受信任的源获得的，否则会话描述是不可信的。可以使用许多不同的传输协议来分发会话描述，不同传输的身份验证的性质也不同。对于某些传输，通常不部署安全功能。如果没有以可信的方式获得会话描述，端点应该小心，因为在其他攻击中，接收到的媒体会话可能不可信
the intended ones, the destination where media is sent to may not be the expected one, and any of the parameters of the session may be incorrect.
对于预期的目标，媒体发送到的目标可能不是预期的目标，并且会话的任何参数都可能不正确。
Incorrect reference or media clock parameters may cause devices or streams to synchronise to unintended clock sources. Normally, this simply results in failure to establish a session or failure to synchronise once connected. Enough devices fraudulently assigned to a specific clock source (e.g., a particular IEEE 1588 grandmaster) may, however, constitute a successful denial-of-service attack on that source. Devices MAY wish to validate the integrity of the clock description through some means before connecting to unfamiliar clock sources.
不正确的参考或媒体时钟参数可能导致设备或流与意外时钟源同步。通常，这只会导致无法建立会话或连接后无法同步。然而，欺诈性地分配给特定时钟源（例如，特定IEEE 1588 grandmaster）的足够多的设备可能会对该源构成成功的拒绝服务攻击。在连接到不熟悉的时钟源之前，设备可能希望通过某种方式验证时钟描述的完整性。
The timestamp reference clocks negotiated by this protocol are used to provide media timing information to RTP. Negotiated timestamp reference clocks should not be relied upon to provide a secure time reference for security critical operations (e.g., the expiration of public key certificates).
该协议协商的时间戳参考时钟用于向RTP提供媒体定时信息。不应依赖协商时间戳参考时钟为安全关键操作（例如，公钥证书过期）提供安全时间参考。
This document defines two new SDP attributes: "ts-refclk" and "mediaclk", within the existing Internet Assigned Numbers Authority (IANA) registry of SDP Parameters.
本文档在SDP参数的现有Internet Assigned Numbers Authority（IANA）注册表中定义了两个新的SDP属性：“ts refclk”和“mediaclk”。
This document also defines a new IANA registry subordinate to the IANA SDP Parameters registry: the Media Clock Source Parameters registry. Within this new registry, this document defines an initial set of three media clock source parameters. Further, this document defines a second new IANA registry subordinate to the IANA SDP Parameters registry: the Timestamp Reference Clock Source Parameters registry. Within this new registry, this document defines an initial six parameters.
本文档还定义了一个新的IANA注册表，隶属于IANA SDP参数注册表：媒体时钟源参数注册表。在这个新的注册表中，本文档定义了一组初始的三个媒体时钟源参数。此外，本文档定义了IANA SDP参数注册表的第二个新IANA注册表：时间戳参考时钟源参数注册表。在这个新的注册表中，本文档定义了最初的六个参数。
The SDP attribute "ts-refclk" defined by this document is registered with the IANA registry of SDP Parameters as follows:
本文档定义的SDP属性“ts refclk”在IANA SDP参数注册表中注册，如下所示：
SDP Attributes ( "att-field (both session and media level)" & "att-field (source level)" ):
SDP属性（“att字段（会话和媒体级别）”和“att字段（源级别）”：
Attribute name: ts-refclk
属性名称：ts refclk
Long form: Timestamp reference clock source
长格式：时间戳参考时钟源
Type of name: att-field
名称类型：att字段
Type of attribute: Session, media, and source level
属性类型：会话、媒体和源级别
Subject to charset: No
以字符集为准：否
Purpose: See Section 4 of this document
目的：见本文件第4节
Reference: This document
参考：本文件
Values: See Section 8.3 of this document
数值：见本文件第8.3节
Figure 10: Reference Clock SDP Parameter IANA Registration
图10：参考时钟SDP参数IANA注册
The attribute has an extensible parameter field; therefore, a registry for these parameters is required. This new registry is defined in Section 8.3.
该属性具有可扩展的参数字段；因此，需要这些参数的注册表。第8.3节定义了此新注册表。
The SDP attribute "mediaclk" defined by this document is registered with the IANA registry of SDP Parameters as follows:
本文档定义的SDP属性“mediaclk”在IANA SDP参数注册表中注册，如下所示：
SDP Attributes ( "att-field (both session and media level)" & "att-field (source level)" ):
SDP属性（“att字段（会话和媒体级别）”和“att字段（源级别）”：
Attribute name: mediaclk
属性名称：mediaclk
Long form: Media clock source
长格式：媒体时钟源
Type of name: att-field
名称类型：att字段
Type of attribute: Session, media, and source level
属性类型：会话、媒体和源级别
Subject to charset: No
以字符集为准：否
Purpose: See Section 5 of this document
目的：见本文件第5节
Reference: This document
参考：本文件
Values: See Section 8.4 of this document
数值：见本文件第8.4节
Figure 11: Media Clock SDP Parameter IANA Registration
图11：媒体时钟SDP参数IANA注册
The attribute has an extensible parameter field; therefore, a registry for these parameters is required. The new registry is defined in Section 8.4.
该属性具有可扩展的参数字段；因此，需要这些参数的注册表。第8.4节定义了新注册表。
This document creates a new IANA subregistry called the Timestamp Reference Clock Source Parameters registry, subordinate to the IANA SDP Parameters registry. Each entry in the Timestamp Reference Clock Source Parameters registry contains:
本文档创建了一个新的IANA子区域，称为时间戳参考时钟源参数注册表，从属于IANA SDP参数注册表。时间戳参考时钟源参数注册表中的每个条目包含：
Name: Token used in the SDP description (clksrc-param-name)
名称：SDP描述中使用的令牌（clksrc参数名称）
Long name: Descriptive name for the timestamp reference clock source
长名称：时间戳参考时钟源的描述性名称
Reference: Reference to the document describing the SDP token (clksrc-param-name) and syntax for the optional value associated with the token (mediaclock-param-value)
参考：参考描述SDP令牌（clksrc参数名称）的文档，以及与该令牌关联的可选值（mediaclock参数值）的语法
Initial values for the Timestamp Reference Clock Source Parameters registry are given below.
时间戳参考时钟源参数注册表的初始值如下所示。
Future assignments are to be made through the Specification Required policy [RFC5226]. The Name field in the table corresponds to a new value corresponding to clksrc-param-name. The Reference must specify a syntax corresponding to clksrc-param-value.
未来的分配将通过规范要求的政策[RFC5226]进行。表中的名称字段对应于与clksrc param Name相对应的新值。引用必须指定与clksrc param值对应的语法。
+---------+------------------------------+--------------------------+
| Name | Long Name | Reference |
+---------+------------------------------+--------------------------+
| ntp | Network Time Protocol | This document, Section 4 |
| | | |
| ptp | Precision Time Protocol | This document, Section 4 |
| | | |
| gps | Global Positioning System | This document, Section 4 |
| | | |
| gal | Galileo | This document, Section 4 |
| | | |
| glonass | Global Navigation Satellite | This document, Section 4 |
| | System | |
| | | |
| local | Local Clock | This document, Section 4 |
| | | |
| private | Private Clock | This document, Section 4 |
+---------+------------------------------+--------------------------+
+---------+------------------------------+--------------------------+
| Name | Long Name | Reference |
+---------+------------------------------+--------------------------+
| ntp | Network Time Protocol | This document, Section 4 |
| | | |
| ptp | Precision Time Protocol | This document, Section 4 |
| | | |
| gps | Global Positioning System | This document, Section 4 |
| | | |
| gal | Galileo | This document, Section 4 |
| | | |
| glonass | Global Navigation Satellite | This document, Section 4 |
| | System | |
| | | |
| local | Local Clock | This document, Section 4 |
| | | |
| private | Private Clock | This document, Section 4 |
+---------+------------------------------+--------------------------+
This document creates a new IANA subregistry called the Media Clock Source Parameters registry, subordinate to the IANA SDP Parameters registry. Each entry in the Media Clock Source Parameters registry contains:
本文档创建了一个新的IANA子区域，称为媒体时钟源参数注册表，从属于IANA SDP参数注册表。媒体时钟源参数注册表中的每个条目都包含：
Name: Token used in the SDP description (mediaclock-param-name)
名称：SDP描述中使用的令牌（mediaclock参数名称）
Long name: Descriptive name for the media clock source type
长名称：媒体时钟源类型的描述性名称
Reference: Reference to the document describing the SDP token (mediaclock-param-name) and syntax for the optional value associated with the token (mediaclock-param-value)
参考：参考描述SDP令牌（mediaclock参数名称）和与令牌（mediaclock参数值）关联的可选值语法的文档
Initial values for the Media Clock Source Parameters registry are given below.
介质时钟源参数注册表的初始值如下所示。
Future assignments are to be made through the Specification Required policy [RFC5226]. The Name field in the table corresponds to a new value corresponding to mediaclock-param-name. The Reference must specify a syntax corresponding to mediaclock-param-value.
未来的分配将通过规范要求的政策[RFC5226]进行。表中的Name字段对应于mediaclock param Name对应的新值。引用必须指定与mediaclock参数值对应的语法。
+----------+-----------------------------+--------------------------+
| Name | Long Name | Reference |
+----------+-----------------------------+--------------------------+
| sender | Asynchronously Generated | This document, Section 5 |
| | Media Clock | |
| | | |
| direct | Direct-Referenced Media | This document, Section 5 |
| | Clock | |
| | | |
| IEEE1722 | IEEE1722 Media Stream | This document, Section 5 |
| | Identifier | |
+----------+-----------------------------+--------------------------+
+----------+-----------------------------+--------------------------+
| Name | Long Name | Reference |
+----------+-----------------------------+--------------------------+
| sender | Asynchronously Generated | This document, Section 5 |
| | Media Clock | |
| | | |
| direct | Direct-Referenced Media | This document, Section 5 |
| | Clock | |
| | | |
| IEEE1722 | IEEE1722 Media Stream | This document, Section 5 |
| | Identifier | |
+----------+-----------------------------+--------------------------+
[RFC5576] requires new source-level attributes to be registered with the IANA registry named "att-field (source level)".
[RFC5576]要求在名为“att字段（源级别）”的IANA注册表中注册新的源级别属性。
The source-level SDP attribute "ts-refclk" defined by this document is registered with the "att-field (source level)" IANA registry of SDP Parameters, according to Figure 10.
根据图10，本文档定义的源级SDP属性“ts refclk”在SDP参数的“att字段（源级）”IANA注册表中注册。
The source-level SDP attribute "mediaclk" defined by this document is registered with the "att-field (source level)" IANA registry of SDP Parameters, according to Figure 11.
根据图11，本文档定义的源级别SDP属性“mediaclk”在SDP参数的“att字段（源级别）”IANA注册表中注册。
The authors would like to thank Magnus Westerlund and Paul Kyzivat for valuable comments that resulted in important improvements to this document.
作者要感谢Magnus Westerlund和Paul Kyzivat的宝贵意见，这些意见导致了本文件的重要改进。
[IEEE1588-2002] IEEE, "1588-2002 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", October 2002, <http://standards.ieee.org/findstds/ standard/1588-2002.html>.
[IEEE1588-2002]IEEE，“1588-2002-网络测量和控制系统精密时钟同步协议的IEEE标准”，2002年10月<http://standards.ieee.org/findstds/ 标准/1588-2002.html>。
[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>。
[IEEE1722] IEEE, "1722-2001 - IEEE Standard for Layer 2 Transport Protocol for Time Sensitive Applications in a Bridged Local Area Network", May 2011, <http://standards.ieee.org/findstds/ standard/1722-2011.html>.
[IEEE1722]IEEE，“1722-2001-桥接局域网中时间敏感应用的第2层传输协议IEEE标准”，2011年5月<http://standards.ieee.org/findstds/ 标准/1722-2011.html>。
[IEEE802.1AS-2011] IEEE, "802.1AS-2011 - IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", February 2011, <http://standards.ieee.org/findstds/ standard/802.1AS-2011.html>.
[IEEE802.1AS-2011]IEEE，“802.1AS-2011-局域网和城域网IEEE标准-桥接局域网中时间敏感应用的定时和同步”，2011年2月<http://standards.ieee.org/findstds/ 标准/802.1AS-2011.html>。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[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月。
[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月。
[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月。
[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月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051]Perkins，C.和T.Schierl，“RTP流的快速同步”，RFC 60512010年11月。
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, September 2013.
[RFC7022]Begen，A.，Perkins，C.，Wing，D.，和E.Rescorla，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 7022，2013年9月。
[AES11-2009] Audio Engineering Society, "AES11-2009: AES recommended practice for digital audio engineering - Synchronization of digital audio equipment in studio operations", February 2010, <http://www.aes.org/standards/>.
[AES11-2009]音频工程学会，“AES11-2009:AES数字音频工程推荐规程-演播室操作中数字音频设备的同步”，2010年2月<http://www.aes.org/standards/>.
[IEEE802.1BA-2011] IEEE, "802.1BA-2011 - IEEE Standard for Local and metropolitan area networks -- Audio Video Bridging (AVB) Systems", September 2011, <http://standards.ieee.org/findstds/ standard/802.1BA-2011.html>.
[IEEE802.1BA-2011]IEEE，“802.1BA-2011-局域网和城域网IEEE标准——音频视频桥接（AVB）系统”，2011年9月<http://standards.ieee.org/findstds/ 标准/802.1BA-2011.html>。
[IS-GPS-200F] Global Positioning Systems Directorate, "Navstar GPS Space Segment/Navigation User Segment Interfaces", IS-GPS-200F , September 2011, <http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
[IS-GPS-200F]全球定位系统理事会，“导航星GPS空间段/导航用户段界面”，IS-GPS-200F，2011年9月<http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
[Olsen] Olsen, D., "Time Accuracy Requirements in Audio Networks", April 2007, <http://www.ieee802.org/1/files/public/docs2007/ as-dolsen-time-accuracy-0407.pdf>.
[Olsen]Olsen，D.“音频网络中的时间精度要求”，2007年4月<http://www.ieee802.org/1/files/public/docs2007/ as-dolsen-time-ACCESS-0407.pdf>。
[RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983.
[RFC0868]Postel，J.和K.Harrenstien，“时间协议”，STD 26，RFC 868，1983年5月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]Andreasen，F.，“会话描述协议（SDP）能力协商”，RFC 59392010年9月。
[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, March 2014.
[RFC7164]Gross，K.和R.Brandenburg，“RTP和闰秒”，RFC 7164，2014年3月。
[RFC7272] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, June 2014.
[RFC7272]勃兰登堡，R.，斯托金，H.，德文特，O.，博罗纳特，F.，蒙塔古德，M.，和K.格罗斯，“使用RTP控制协议（RTCP）的目的地间媒体同步（IDMS）”，RFC 7272，2014年6月。
[SMPTE-318M-1999] Society of Motion Picture & Television Engineers, "Television and Audio - Synchronization of 59.94- or 50-Hz Related Video and Audio Systems in Analog and Digital Areas - Reference Signals", ST 318:1999, <http://standards.smpte.org/>.
[SMPTE-318M-1999]电影和电视工程师学会，“电视和音频-模拟和数字领域59.94或50 Hz相关视频和音频系统的同步-参考信号”，ST 318:1999<http://standards.smpte.org/>.
Authors' Addresses
作者地址
Aidan Williams Audinate Level 1, 458 Wattle St Ultimo, NSW 2007 Australia
Aidan Williams Audinate 1级，2007年澳大利亚新南威尔士州沃特街458号
Phone: +61 2 8090 1000
Fax: +61 2 8090 1001
EMail: aidan.williams@audinate.com
URI: http://www.audinate.com/
Phone: +61 2 8090 1000
Fax: +61 2 8090 1001
EMail: aidan.williams@audinate.com
URI: http://www.audinate.com/
Kevin Gross AVA Networks Boulder, CO US
凯文·格罗斯美国博尔德艾娃网络公司
EMail: kevin.gross@avanw.com
URI: http://www.avanw.com/
EMail: kevin.gross@avanw.com
URI: http://www.avanw.com/
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT The Netherlands
雷范勃兰登堡TNO Brasserspein 2代尔夫特2612荷兰
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Hans Stokking TNO Brassersplein 2 Delft 2612CT The Netherlands
Hans Stokking TNO Brassersplein 2 Delft 2612 CT荷兰
EMail: hans.stokking@tno.nl
EMail: hans.stokking@tno.nl