draft-ietf-avtcore-clksrc-11.txt   rfc7273.txt 
Audio/Video Transport Core A. Williams Internet Engineering Task Force (IETF) A. Williams
Maintenance Audinate Request for Comments: 7273 Audinate
Internet-Draft K. Gross Category: Standards Track K. Gross
Intended status: Standards Track AVA Networks ISSN: 2070-1721 AVA Networks
Expires: September 26, 2014 R. van Brandenburg R. van Brandenburg
H. Stokking H. Stokking
TNO TNO
March 25, 2014 June 2014
RTP Clock Source Signalling RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-11
Abstract Abstract
NTP format timestamps are used by several RTP protocols for NTP format timestamps are used by several RTP protocols for
synchronisation and statistical measurements. This memo specifies synchronisation and statistical measurements. This memo specifies
SDP signalling identifying timestamp reference clock sources and SDP Session Description Protocol (SDP) signalling that identifies
signalling identifying the media clock sources in a multimedia timestamp reference clock sources and SDP signalling that identifies
session. the media clock sources in a multimedia session.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 26, 2014. 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.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 6 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 7 4.1. Clock Synchronisation . . . . . . . . . . . . . . . . . . 5
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 7 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . 6
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 9 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . 6
4.5. Private Reference Clocks . . . . . . . . . . . . . . . . . 9 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8
4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . . 9 4.5. Private Reference Clocks . . . . . . . . . . . . . . . . 8
4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . . 9 4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . 8
4.8. SDP Signalling of Timestamp Reference Clock Source . . . . 10 4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . 8
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 4.8. SDP Signalling of Timestamp Reference Clock Source . . . 9
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 13 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 13 5.1. Asynchronously Generated Media Clock . . . . . . . . . . 12
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 15 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 16 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. SDP Signalling of Media Clock Source . . . . . . . . . . 15
6. Signalling Considerations . . . . . . . . . . . . . . . . . . 20 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 20 6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19
6.1.1. Indicating Support for Clock Source Signalling . . . . 21 6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19
6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 21 6.1.1. Indicating Support for Clock Source Signalling . . . 20
6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 21 6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 22 6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 24 8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22
8.3. Timestamp Reference Clock Source Parameters Registry . . . 24 8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 23
8.4. Media Clock Source Parameters Registry . . . . . . . . . . 25 8.3. Timestamp Reference Clock Source Parameters Registry . . 23
8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 26 8.4. Media Clock Source Parameters Registry . . . . . . . . . 24
8.5.1. Source-level Timestamp Reference Clock Attribute . . . 26 8.5. Source-Level Attributes . . . . . . . . . . . . . . . . . 25
8.5.2. Source-level Media Clock Attribute . . . . . . . . . . 26 8.5.1. Source-Level Timestamp Reference Clock Attribute . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 8.5.2. Source-Level Media Clock Attribute . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
RTP protocols use NTP format timestamps to facilitate multimedia RTP protocols use NTP format timestamps to facilitate multimedia
session synchronisation and for providing estimates of round trip session synchronisation and to provide estimates of round-trip time
time (RTT) and other statistical parameters. (RTT) and other statistical parameters.
Information about media clock timing exchanged in NTP format Information about media clock timing exchanged in NTP format
timestamps may come from a clock which is synchronised to a global timestamps may come from a clock that is synchronised to a global
time reference, but this cannot be assumed nor is there a time reference, but this cannot be assumed, nor is there a
standardised mechanism available to indicate that timestamps are standardised mechanism available to indicate that timestamps are
derived from a common reference clock. Therefore, RTP derived from a common reference clock. Therefore, RTP
implementations typically assume that NTP timestamps are taken using implementations typically assume that NTP timestamps are taken using
unsynchronised clocks and must compensate for absolute time unsynchronised clocks and must compensate for absolute time
differences and rate differences. Without a shared reference clock, differences and rate differences. Without a shared reference clock,
RTP can time align flows from the same source at a given receiver RTP can time align flows from the same source at a given receiver
using relative timing, however tight synchronisation between two or using relative timing; however, tight synchronisation between two or
more different receivers (possibly with different network paths) or more different receivers (possibly with different network paths) or
between two or more senders is not possible. between two or more senders is not possible.
High performance AV systems often use a reference media clock High performance AV systems often use a reference media clock
distributed to all devices in the system. The reference media clock distributed to all devices in the system. The reference media clock
is often distinct from the reference clock used to provide may be distinct from the reference clock used to provide timestamps.
timestamps. A reference media clock may be provided along with an A reference media clock may be provided along with an audio or video
audio or video signal interface, or via a dedicated clock signal signal interface, or via a dedicated clock signal (e.g., genlock
(e.g. genlock [SMPTE-318-1999] or audio word clock [AES11-2009]). If [SMPTE-318M-1999] or audio word clock [AES11-2009]). If sending and
sending and receiving media clocks are known to be synchronised to a receiving media clocks are known to be synchronised to a common
common reference clock, performance can improved by minimising reference clock, performance can be improved by minimising buffering
buffering and avoiding rate conversion. and avoiding rate conversion.
This specification defines SDP signalling of timestamp reference This specification defines SDP signalling of timestamp reference
clock sources and media reference clock sources. clock sources and media reference clock sources.
1.1. Requirements Language
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].
2. Applications 2. Applications
Timestamp reference clock source and media clock signalling benefit Timestamp reference clock source and media clock signalling benefit
applications requiring synchronised media capture or playout and low applications requiring synchronised media capture or playout and low
latency operation. latency operation.
Examples include, but are not limited to: Examples include, but are not limited to:
Social TV : RTCP for inter-destination media synchronization Social TV: "Inter-Destination Media Synchronization (IDMS) Using the
[I-D.ietf-avtcore-idms] defines social TV as the combination of RTP Control Protocol (RTCP)" [RFC7272] defines social TV as the
media content consumption by two or more users at different combination of media content consumption by two or more users at
devices and locations and real-time communication between those different devices and locations and real-time communication
users. An example of Social TV, is where two or more users are between those users. An example of social TV is where two or more
watching the same television broadcast at different devices and/or users are watching the same television broadcast at different
locations, while communicating with each other using text, audio devices and/or locations while communicating with each other using
and/or video. A skew in the media playout of the two or more text, audio, and/or video. A skew in the media playout of the two
users can have adverse effects on their experience. A well-known or more users can have adverse effects on their experience. A
use case here is one friend experiencing a goal in a football well-known use case here is one friend experiencing a goal in a
match well before or after other friends. football match well before or after other friends.
Video Walls : A video wall consists of multiple computer monitors, Video Walls: A video wall consists of multiple computer monitors,
video projectors, or television sets tiled together contiguously video projectors, or television sets tiled together contiguously
or overlapped in order to form one large screen. Each of the or overlapped in order to form one large screen. Each of the
screens reproduces a portion of the larger picture. In some screens reproduces a portion of the larger picture. In some
implementations, each screen or projector may be individually implementations, each screen or projector may be individually
connected to the network and receive its portion of the overall connected to the network and receive its portion of the overall
image from a network-connected video server or video scaler. image from a network-connected video server or video scaler.
Screens are refreshed at 50 or 60 hertz or potentially faster. If Screens are refreshed at 50 or 60 hertz or potentially faster. If
the refresh is not synchronized, the effect of multiple screens the refresh is not synchronised, the effect of multiple screens
acting as one is broken. acting as one is broken.
Networked Audio : Networked loudspeakers, amplifiers and analogue Networked Audio: Networked loudspeakers, amplifiers, and analogue
I/O devices transmitting or receiving audio signals via RTP can be input/output (I/O) devices transmitting or receiving audio signals
connected to various parts of a building or campus network. Such via RTP can be connected to various parts of a building or campus
situations can for example be found in large conference rooms, network. Such situations can, for example, be found in large
legislative chambers, classrooms (especially those supporting conference rooms, legislative chambers, classrooms (especially
distance learning) and other large-scale environments such as those supporting distance learning), and other large-scale
stadiums. Since humans are more susceptible to differences in environments such as stadiums. Since humans are more sensitive to
audio delay, this use case needs even more accuracy than the video differences in audio delay, this use case needs even more accuracy
wall use case. Depending on the exact application, the need for than the video wall use case. Depending on the exact application,
accuracy can then be in the range of microseconds [Olsen]. the need for accuracy can then be in the range of microseconds
[Olsen].
Sensor Arrays : Sensor arrays contain many synchronised measurement Sensor Arrays: Sensor arrays contain many synchronised measurement
elements producing signals which are then combined to form an elements producing signals that are then combined to form an
overall measurement. Accurate capture of the phase relationships overall measurement. Accurate capture of the phase relationships
between the various signals arriving at each element of the array between the various signals arriving at each element of the array
is critically important for proper operation. Examples include is critically important for proper operation. Examples include
towed or fixed sonar arrays, seismic arrays and phased arrays used towed or fixed sonar arrays, seismic arrays, and phased arrays
in radar applications, for instance. used in radar applications, for instance.
3. Definitions 3. Definitions
The following definitions are used in this draft: The following definitions are used in this document:
media level : Media level information applies to a single SDP media media level: Media-level information applies to a single SDP media
stream. In an SDP description, media-level information appears stream. In an SDP description, media-level information appears
after each "m"-line. after each "m"-line.
multimedia session : A set of multimedia senders and receivers as multimedia session: A set of multimedia senders and receivers as
well as the data streams flowing from senders to receivers. The well as the data streams flowing from senders to receivers. SDP
Session Description Protocol (SDP) [RFC4566] describes multimedia [RFC4566] describes multimedia sessions.
sessions.
RTP media stream : A single stream of RTP packets identified by an
RTP SSRC.
RTP media sender : The device generating an associated RTP media RTP media stream: A single stream of RTP packets identified by an
stream RTP Synchronisation Source (SSRC).
SDP media stream : An RTP session potentially containing more than RTP sender: The device generating an associated RTP media stream.
one RTP source. SDP media descriptions beginning with an "m"-line
define the parameters of an SDP media stream.
session level : Session level information applies to an entire session level: Session-level information applies to an entire
multimedia session. In an SDP description, session-level multimedia session. In an SDP description, session-level
information appears before the first "m"-line. information appears before the first "m"-line.
source level : Source level information applies to a specific RTP source level: Source-level information applies to a specific RTP
media stream. Source-Specific Media Attributes in the Session media stream. "Source-Specific Media Attributes in the Session
Description Protocol (SDP) [RFC5576] defines how source-level Description Protocol (SDP)" [RFC5576] defines how source-level
information is included into an SDP session description. information is included into an SDP session description.
traceable time : A clock is considered to provide traceable time if traceable time: A clock is considered to provide traceable time if
it can be proven to be synchronised to International Atomic Time it can be proven to be synchronised to International Atomic Time
(TAI). Coordinated Universal Time (UTC) is a time standard (TAI). Coordinated Universal Time (UTC) is a time standard
synchronized to TAI. UTC is therefore also considered traceable synchronised to TAI. UTC is, therefore, also considered traceable
time once leap seconds have been taken unto account. GPS time once leap seconds have been taken into account. GPS
[IS-GPS-200F] is commonly used to provide a TAI traceable time [IS-GPS-200F] is commonly used to provide a TAI traceable time
reference. Some network time synchronisation protocols (e.g. PTP reference. Some network time synchronisation protocols (e.g.,
[IEEE1588-2008], NTP) can explicitly indicate that the master Precision Time Protocol (PTP) [IEEE1588-2008] and NTP) can
clock is providing a traceable time reference over the network. explicitly indicate that the master clock is providing a traceable
time reference over the network.
4. Timestamp Reference Clock Source Signalling 4. Timestamp Reference Clock Source Signalling
The NTP format timestamps used by RTP are taken by reading a local 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 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 synchronised to another clock (time source) by some means, or it may
be unsynchronised. A variety of methods are available to synchronise be unsynchronised. A variety of methods are available to synchronise
local clocks to a reference time source, including network time local clocks to a reference time source, including network time
protocols (e.g. NTP [RFC5905], PTP [IEEE1588-2008]) and radio clocks protocols (e.g., NTP [RFC5905] and PTP [IEEE1588-2008]) and radio
(e.g. GPS [IS-GPS-200F]). clocks (e.g., GPS [IS-GPS-200F]).
The following sections describe and define SDP signalling, indicating The following sections describe and define SDP signalling, indicating
whether and how the local timestamping clock in an RTP sender/ whether and how the local timestamping clock in an RTP sender or
receiver is synchronised to a reference clock. receiver is synchronised to a reference clock.
4.1. Clock synchronization 4.1. Clock Synchronisation
Two or more local clocks that are sufficiently synchronised will Two or more local clocks that are sufficiently synchronised will
produce timestamps for a given RTP event can be used as if they came produce timestamps for a given RTP event that can be used as if they
from the same clock. Providing they are sufficiently synchronised, came from the same clock. Timestamps produced in one RTP sender or
timestamps produced in one RTP sender or receiver can be directly receiver can be directly compared to a local clock in another RTP
compared to a local clock in another RTP sender or receiver. sender or receiver.
The accuracy of synchronisation required is application dependent. The accuracy of synchronisation required is application dependent.
See Applications (Section 2) section for a discussion of applications See "Applications" (Section 2) for a discussion of applications and
and their corresponding requirements. To serve as a reference clock, their corresponding requirements. To serve as a reference clock,
clocks must minimally be syntonized (exactly frequency matched) to clocks must minimally be "syntonised" (exactly frequency matched) to
one another. one another.
Sufficient synchronisation can typically be achieving by using a Sufficient synchronisation can typically be achieved by using a
network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to network time protocol (e.g., NTP, 802.1AS, and IEEE 1588-2008) to
synchronize all devices to a single master clock. synchronise all devices to a single master clock.
Another approach is to use clocks providing a global time reference Another approach is to use clocks providing a global time reference
(e.g. GPS, Galileo, GLONASS). This concept may be used in (e.g., GPS, Galileo, and GLONASS). This concept may be used in
conjunction with network time protocols as some protocols (e.g. PTP, conjunction with network time protocols as some protocols (e.g., PTP
NTP) allow master clocks to indicate explicitly that they are and NTP) allow master clocks to indicate explicitly that they are
providing traceable time. providing traceable time.
4.2. Identifying NTP Reference Clocks 4.2. Identifying NTP Reference Clocks
A single NTP server is identified by hostname (or IP address) and an A single NTP server is identified by a hostname (or IP address) and
optional port number. If the port number is not indicated, it is an optional port number. If the port number is not indicated, it is
assumed to be the standard NTP port (123). assumed to be the standard NTP port (123).
Two or more NTP servers MAY be listed at the same level in the Two or more NTP servers MAY be listed at the same level in the
session description to indicate that all of the listed servers session description to indicate that all of the listed servers
deliver the same reference time and may be used interchangeably. RTP deliver the same reference time and may be used interchangeably. RTP
senders and receivers are assured proper synchronization regardless senders and receivers are assured proper synchronisation regardless
of which server they choose and, in support of fault tolerance, may of which server they choose and, in support of fault tolerance, may
switch servers while streaming. switch servers while streaming.
4.3. Identifying PTP Reference Clocks 4.3. Identifying PTP Reference Clocks
The IEEE 1588 Precision Time Protocol (PTP) family of clock The Precision Time Protocol (PTP) as standardised in IEEE 1588
synchronisation protocols provides a shared reference clock in an provides a shared reference clock in a network. IEEE 1588 provides
network - typically a LAN. IEEE 1588 provides sub-microsecond sub-microsecond synchronisation between devices on a LAN and
synchronisation between devices on a LAN and typically locks within typically locks within seconds at startup. With support from
seconds at startup. With support from Ethernet switches, IEEE 1588 Ethernet switches, IEEE 1588 protocols can achieve nanosecond timing
protocols can achieve nanosecond timing accuracy in LANs. Network accuracy in LANs. Network interface chips and cards supporting
interface chips and cards supporting hardware time-stamping of timing hardware timestamping of timing-critical protocol messages are also
critical protocol messages are also available. available.
Three flavours of IEEE 1588 are in use today: Three flavours of IEEE 1588 are in use today:
o IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a o IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a
Precision Clock Synchronization Protocol for Networked Measurement Precision Clock Synchronization Protocol for Networked Measurement
and Control Systems". This is also known as IEEE1588v1 or PTPv1. and Control Systems". This is also known as IEEE1588v1 or PTPv1.
o IEEE 1588-2008 [IEEE1588-2008]: the second version of the o IEEE 1588-2008 [IEEE1588-2008]: the second version of the
"Standard for a Precision Clock Synchronization Protocol for "Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems". This is a revised Networked Measurement and Control Systems". This is a revised
version of the original IEEE1588-2002 standard and is also known version of the original IEEE1588-2002 standard and is also known
as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible
with IEEE 1588-2002. with IEEE 1588-2002.
o IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for o IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for
Time Sensitive Applications in Bridged Local Area Networks". This Time Sensitive Applications in Bridged Local Area Networks". This
is a Layer-2 only profile of IEEE 1588-2008 for use in Audio/Video is a profile of IEEE 1588-2008 that is Layer 2 only and is for use
Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011]. in Audio/Video Bridged LANs as described in IEEE 802.1BA-2011
[IEEE802.1BA-2011].
Each IEEE 1588 clock is identified by an EUI-64 called a Each IEEE 1588 clock is identified by a 64-bit Extended Unique
"ClockIdentity". A slave clock using one of the IEEE 1588 family of Identifier (EUI-64) called a "ClockIdentity". A slave clock using
network time protocols acquires the ClockIdentity/EUI-64 of the one of the IEEE 1588 family of network time protocols acquires the
grandmaster clock that is the ultimate source of timing information ClockIdentity of the grandmaster clock that is the ultimate source of
for the network. A boundary clock which is itself slaved to another timing information for the network. A boundary clock, which is
boundary clock or the grandmaster passes the grandmaster itself slaved to another boundary clock, or the grandmaster passes
ClockIdentity through to its slaves. the grandmaster ClockIdentity through to its slaves.
Several instances of the IEEE 1588 protocol may operate independently Several instances of the IEEE 1588 protocol may operate independently
on a single network, forming distinct PTP domains, each of which may on a single network, forming distinct PTP domains, each of which may
have a different grandmaster clock. As the IEEE 1588 standards have have a different grandmaster clock. As the IEEE 1588 standards have
developed, the definition of PTP domains has changed. IEEE 1588-2002 evolved, the definition of PTP domains has changed. IEEE 1588-2002
identifies protocol subdomains by a textual name, but IEEE 1588-2008 identifies protocol subdomains by a textual name, but IEEE 1588-2008
identifies protocol domains using a numeric domain number. 802.1AS is identifies protocol domains using a numeric domain number. 802.1AS is
a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock a Layer 2 profile of IEEE 1588-2008 supporting a single numeric clock
domain (0). domain (0).
When PTP domains are signalled via SDP, senders and receivers SHOULD When PTP domains are signalled via SDP, senders and receivers SHOULD
check that both grandmaster ClockIdentity and PTP domain match when check that both grandmaster ClockIdentity and the PTP domain match
determining clock equivalence. when determining clock equivalence.
Two or more IEEE 1588 clocks MAY be listed at the same level in the 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 session description to indicate that all of the listed clocks are
candidate grandmaster clocks for the domain or deliver the same candidate grandmaster clocks for the domain or deliver the same
reference time and may be used interchangeably. RTP senders and reference time and may be used interchangeably. RTP senders and
receivers are assured proper synchronization regardless of which receivers are assured proper synchronisation regardless of which
synchronization source they choose and, in support of fault synchronisation source they choose and, in support of fault
tolerance, may switch reference clock source while streaming. tolerance, may switch the reference clock source while streaming.
The PTP protocols employ a distributed election protocol called the The PTP protocols employ a distributed election protocol called the
"Best Master Clock Algorithm" (BMCA) to determine the active clock "Best Master Clock Algorithm" (BMCA) to determine the active clock
master. The clock master choices available to BMCA can be restricted master. The clock master choices available to BMCA can be restricted
or biased by configuration parameters to influence the election or biased by configuration parameters to influence the election
process. In some systems it may be desirable to limit the number of 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 possible PTP clock masters to avoid the need to re-signal timestamp
reference clock sources when the clock master changes. reference clock sources when the clock master changes.
4.4. Identifying Global Reference Clocks 4.4. Identifying Global Reference Clocks
Global reference clocks provide a source of traceable time, typically Global reference clocks provide a source of traceable time, typically
via a hardware radio receiver interface. Examples include GPS, via a hardware radio receiver interface. Examples include GPS,
Galileo and GLONASS. Apart from the name of the reference clock Galileo, and GLONASS. Apart from the name of the reference clock
system, no further identification is required. system, no further identification is required.
4.5. Private Reference Clocks 4.5. Private Reference Clocks
In other systems, all RTP senders and receivers may use a timestamp In other systems, all RTP senders and receivers may use a timestamp
reference clock that is not provided by one of the methods listed reference clock that is not provided by one of the methods listed
above. Examples may include the reference time information provided above. Examples may include the reference time information provided
by digital television or cellular services. These sources are by digital television or cellular services. These sources are
identified as "private" reference clocks. All RTP senders and identified as "private" reference clocks. All RTP senders and
receivers in a session using a private reference clock are assumed to receivers in a session using a private reference clock are assumed to
have a mechanism outside this specification for determining whether have a mechanism outside this specification for determining whether
their timestamp reference clocks are equivalent. their timestamp reference clocks are equivalent.
4.6. Local Reference Clocks 4.6. Local Reference Clocks
RFC 3550 allows senders and receivers to either use a local wall [RFC3550] allows senders and receivers to either use a local
clock reference for their NTP timestamps or, by setting the timestamp wallclock reference for their NTP timestamps or, by setting the
field to 0, to supply no timestamps at all. Both are common practice timestamp field to 0, supply no timestamps at all. Both are common
in embedded RTP implementations. These clocks are identified as practice in embedded RTP implementations. These clocks are
"local" and can only be assumed to be equivalent to clocks identified as "local" and can, at best, be assumed to be equivalent
originating from the same device. to clocks originating from the same device.
4.7. Traceable Reference Clocks 4.7. Traceable Reference Clocks
A timestamp reference clock source may be labelled "traceable" if it A timestamp reference clock source may be labelled "traceable" if it
is known to be to delivering traceable time. Providing adjustments is known to be delivering traceable time, provided adjustments are
are made for differing epochs, timezones and leap seconds, timestamps made for differing epochs, timezones, and leap seconds. Timestamps
taken using clocks synchronised to a traceable time source can be taken using clocks synchronised to a traceable time source can be
directly compared even if the clocks are synchronised to different directly compared even if the clocks are synchronised to different
sources or via different mechanisms. sources or via different mechanisms.
Marking a clock as traceable allows additional information (e.g. IP Marking a clock as traceable allows additional information (e.g., IP
addresses, PTP master identifiers and the like) to be omitted from addresses, PTP master identifiers, and the like) to be omitted from
the SDP since any traceable clock available at the answerer is the SDP since any traceable clock available at the answerer is
considered to be an appropriate timestamp reference clock. For considered to be an appropriate timestamp reference clock. For
example, an offerer could could specify ts-refclk:ntp=/traceable/ and example, an offerer could specify ts-refclk:ntp=/traceable/ and the
the answerer could use GPS as a reference clock since GPS is a source answerer could use GPS as a reference clock since GPS is a source of
of traceable time. traceable time.
4.8. SDP Signalling of Timestamp Reference Clock Source 4.8. SDP Signalling of Timestamp Reference Clock Source
Specification of the timestamp reference clock source may be at any Specification of the timestamp reference clock source may be at any
or all levels (session, media or source) of an SDP description (see or all levels (session, media, or source) of an SDP description (see
level definitions (Section 3) earlier in this document for more level definitions in Section 3 earlier in this document for more
information). information).
Timestamp reference clock source signalling included at session-level Timestamp reference clock source signalling included at the session
provides default parameters for all RTP sessions and sources in the level provides default parameters for all RTP sessions and sources in
session description. More specific signalling included at the media the session description. More specific signalling included at the
level overrides default session level signalling. More specific media level overrides session-level signalling. More specific
signalling included at the source level overrides default media level signalling included at the source level overrides media-level
signalling. signalling.
If timestamp reference clock source signalling is included anywhere If timestamp reference clock source signalling is included anywhere
in an SDP description, it must be properly defined for all levels in in an SDP description, it must be properly defined for all levels in
the description. This may simply be achieved by providing default the description. This may simply be achieved by providing default
signalling at the session level. signalling at the session level.
Timestamp reference clock parameters may be repeated at a given level Timestamp reference clock parameters may be repeated at a given level
(i.e. for a session or source) to provide information about (i.e., for a session or source) to provide information about
additional servers or clock sources. If the attribute is repeated at additional servers or clock sources. If the attribute is repeated at
a given level, all clocks described at that level are assumed to be a given level, all clocks described at that level are assumed to be
equivalent. Traceable time sources MUST NOT be mixed with non- equivalent. Traceable time sources MUST NOT be mixed with non-
traceable time sources at any given level. traceable time sources at any given level.
Note that clock source parameters may change from time to time, for Note that clock source parameters may change from time to time, for
example, as a result of a PTP clock master election. The SIP example, as a result of a PTP grandmaster election. SIP [RFC3261]
[RFC3261] protocol supports re-signalling of updated SDP information, supports the re-signalling of updated SDP information; however, other
however other protocols may require additional notification protocols may require additional notification mechanisms.
mechanisms.
General forms of usage: 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] grammar for the timestamp reference clock attribute:
; external references: ; external references:
POS-DIGIT = <See RFC 4566> POS-DIGIT = <See RFC 4566>
token = <See RFC 4566> token = <See RFC 4566>
byte-string = <See RFC 4566> byte-string = <See RFC 4566>
DIGIT = <See RFC 5324> DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5324> HEXDIG = <See RFC 5234>
CRLF = <See RFC 5324> CRLF = <See RFC 5234>
hostport = <See RFC 3261, with revisions from RFC 5954> hostport = <See RFC 3261, with revisions from RFC 5954>
timestamp-refclk = "ts-refclk:" clksrc CRLF timestamp-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-ext = clksrc-param-name clksrc-param-value
clksrc-param-name = token clksrc-param-name = token
clksrc-param-value = ["=" byte-string ] clksrc-param-value = ["=" byte-string ]
ntp = "ntp=" ntp-server-addr ntp = "ntp=" ntp-server-addr
ntp-server-addr = hostport / "/traceable/" ntp-server-addr = hostport / "/traceable/"
ptp = "ptp=" ptp-version ":" ptp-server ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002" ptp-version = "IEEE1588-2002"
skipping to change at page 12, line 10 skipping to change at page 11, line 18
EUI64 = 7(2HEXDIG "-") 2HEXDIG EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 1: Timestamp Reference Clock Source Signalling Figure 1: Timestamp Reference Clock Source Signalling
4.8.1. Examples 4.8.1. Examples
Figure 2 shows an example SDP description with a timestamp reference Figure 2 shows an example SDP description with a timestamp reference
clock source defined at the session level. clock source defined at the session level.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
a=ts-refclk:ntp=/traceable/ a=ts-refclk:ntp=/traceable/
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
Figure 2: Timestamp reference clock definition at the session level Figure 2: Timestamp Reference Clock Definition at the Session Level
Figure 3 shows an example SDP description with timestamp reference Figure 3 shows an example SDP description with timestamp reference
clock definitions at the media level overriding the session level clock definitions at the media level overriding the session-level
defaults. defaults.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
a=ts-refclk:local a=ts-refclk:local
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=ts-refclk:ntp=203.0.113.10 a=ts-refclk:ntp=203.0.113.10
a=ts-refclk:ntp=198.51.100.22 a=ts-refclk:ntp=198.51.100.22
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 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 Figure 3: Timestamp Reference Clock Definition at the Media Level
Figure 4 shows an example SDP description with a timestamp reference Figure 4 shows an example SDP description with a timestamp reference
clock definition at the source level overriding the session level clock definition at the source level overriding the session-level
default. default.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
a=ts-refclk:local a=ts-refclk:local
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 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 Figure 4: Timestamp Reference Clock Signalling at the Source Level
5. Media Clock Source Signalling 5. Media Clock Source Signalling
The media clock source for a stream determines the timebase used to The media clock source for a stream determines the timebase used to
advance the RTP timestamps included in RTP packets. The media clock advance the RTP timestamps included in RTP packets. The media clock
may be asynchronously generated by the sender, it may be generated in may be asynchronously generated by the sender, it may be generated in
fixed relationship to the reference clock or it may be generated with fixed relationship to the reference clock, or it may be generated
respect to another stream on the network (which is presumably being with respect to another stream on the network (which is presumably
received by the sender). being received by the sender).
5.1. Asynchronously Generated Media Clock 5.1. Asynchronously Generated Media Clock
In the simplest sender implementation, the sender generates media by In the simplest sender implementation, the sender generates media by
sampling audio or video according to a free-running local clock. The sampling audio or video according to a free-running local clock. The
RTP timestamps in media packets are advanced according to this media RTP timestamps in media packets are advanced according to this media
clock and packet transmission is typically timed to regular intervals clock, and packet transmission is typically timed to regular
on this timeline. The sender may or may not include an NTP timestamp intervals on this timeline. The sender may or may not include an NTP
in sender reports to allow mapping of this asynchronous media clock timestamp in sender reports to allow mapping of this asynchronous
to a reference clock. media clock to a reference clock.
The asynchronously generated media clock is the assumed mode of The asynchronously generated media clock is the assumed mode of
operation when there is no signalling of media clock source. operation when there is no signalling of the media clock source.
Alternatively, asynchronous media clock may be explicitly signalled. Alternatively, an asynchronous media clock may be explicitly
signalled.
a=mediaclk:sender a=mediaclk:sender
5.2. Direct-Referenced Media Clock 5.2. Direct-Referenced Media Clock
A media clock may be directly derived from a reference clock. For 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 this case, it is required that a reference clock be specified with an
a=ts-refclk attribute (Section 4.8). a=ts-refclk attribute (Section 4.8).
The signalling optionally indicates a media clock offset value. The The signalling optionally indicates a media clock offset value. The
offset indicates the RTP timestamp value at the epoch (time of offset indicates the RTP timestamp value at the epoch (time of
origin) of the reference clock. To use the offset, implementations origin) of the reference clock. To use the offset, implementations
need to compute RTP timestamps from reference clocks. To simplify need to compute RTP timestamps from reference clocks. To simplify
these calculations, streams utilizing offset signalling SHOULD use a these calculations, streams utilizing offset signalling SHOULD use a
TAI timestamp reference clock to avoid complications introduced by TAI timestamp reference clock to avoid complications introduced by
leap seconds. See [I-D.ietf-avtcore-leap-second] for further leap seconds. See [RFC7164] for further discussion of leap-second
discussion of leap-second issues in timestamp reference clocks. issues in timestamp reference clocks.
To compute the RTP timestamp against an IEEE 1588 (TAI-based) To compute the RTP timestamp against an IEEE 1588 (TAI-based)
reference, the time elapsed between the 00:00:00 1 January 1970 IEEE 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 1588 epoch and the current time must be computed. Between the epoch
and 1 January 2013, there were 15,706 days (including extra days and 1 January 2013, there were 15,706 days (including extra days
during leap years). Since there are no leap seconds in a TAI during leap years). Since there are no leap seconds in a TAI
reference, there are exactly 86,400 seconds during each of these days 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 or a total of 1,356,998,400 seconds from the epoch to 00:00:00 1
January 2013. A 90 kHz RTP clock for a video stream would have 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 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 signalled offset of 0, the RTP clock value modulo the 32-bit unsigned
representation in the RTP header would have been 2,460,938,240 at 00: RTP timestamp representation in the RTP header would have been
00:00 1 January 2013. If an offset of 23,465 had been signalled, the 2,460,938,240 at 00:00:00 1 January 2013. If an offset of 23,465 had
clock value would have been 2,460,961,705. been signalled, the clock value would have been 2,460,961,705.
In order to use an NTP reference, the actual time elapsed between the 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 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: computed. 2,208,988,800 seconds elapsed between the NTP epoch and
00:00 1 January 1970 [RFC0868]. Between the beginning of 1970 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 2013, there were 15,706 days elapsed (including extra days during
leap years) and 25 leap seconds inserted. There is therefore a total leap years) and 25 leap seconds inserted. There is, therefore, a
of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1 January total of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1
2013. A 90 kHz RTP clock for a video stream would have advanced January 2013. A 90 kHz RTP clock for a video stream would have
320,938,850,250,000 units over this period. With a signalled offset advanced 320,938,850,250,000 units over this period. With a
of 0, the RTP clock value modulo the 32-bit unsigned representation signalled offset of 0, the RTP clock value modulo the 32-bit unsigned
would have been 1,714,023,696 at 00:00:00 1 January 2013. representation would have been 1,714,023,696 at 00:00:00 1 January
2013.
If no offset is signalled, the offset can be inferred at the receiver If no offset is signalled, the offset can be inferred at the receiver
by examining RTCP sender reports which contain NTP and RTP timestamps by examining RTCP sender reports that contain NTP and RTP timestamps,
which combined define a mapping. The NTP/RTP timestamp mapping which combined define a mapping. The NTP/RTP timestamp mapping
provided by RTCP SRs takes precedence over that singaled through SDP, provided by RTCP sender reports (SRs) takes precedence over that
however the media clock rate implied by the SRs MUST be consistent signalled through SDP; however, the media clock rate implied by the
with the rate signalled. SRs MUST be consistent with the rate signalled.
A rate modifier may be specified. The modifier is expressed as the A rate modifier may be specified. The modifier is expressed as the
ratio of two integers and modifies the rate specified or implied by ratio of two integers and modifies the rate specified or implied by
the media description by this ratio. If omitted, the rate is assumed 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 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 example, without a rate specification, the RTP clock for an 8 kHz
G.711 audio stream will advance exactly 8000 units for each second G.711 audio stream will advance exactly 8000 units for each second
advance in the reference clock from which it is derived. advance in the reference clock from which it is derived.
The rate modifier is primarily useful for accommodating certain The rate modifier is primarily useful for accommodating certain
"oddball" audio sample rates associated with NTSC video (see "oddball" audio sample rates associated with NTSC video (see
Figure 7). Modified rates are not advised for video streams which Figure 7). Modified rates are not advised for video streams that
generally use a 90 kHz RTP clock regardless of frame rate or sample generally use a 90 kHz RTP clock regardless of frame rate or sample
rate used for embedded audio. rate used for embedded audio.
a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
denominator>] denominator>]
5.3. Stream-Referenced Media Clock 5.3. Stream-Referenced Media Clock
A common synchronisation architecture for audio/visual systems A common synchronisation architecture for audio/visual systems
involves distributing a reference media clock from a master device to involves distributing a reference media clock from a master device to
a number of slave devices, typically by means of a cable. Examples a number of slave devices, typically by means of a cable. Examples
include audio word clock distribution and video black burst include audio word clock distribution and video black burst
distribution. In this case, the media clock is locally generated, distribution. In this case, the media clock is locally generated,
often by a crystal oscillator and is not locked to a timestamp often by a crystal oscillator, and is not locked to a timestamp
reference clock. reference clock.
To support this architecture across a network, a master clock To support this architecture across a network, a master clock
identifier is associated with an RTP media stream carrying media identifier is associated with an RTP media stream carrying media
clock timing information from a master device. The master clock clock timing information from a master device. The master clock
identifier represents a media clock source in the master device. identifier represents a media clock source in the master device.
Slave devices in turn associate the master media clock identifier Slave devices in turn associate the master media clock identifier
with streams they transmit, signalling the synchronisation with streams they transmit, signalling the synchronisation
relationship between the master and the transmitter's media clock. relationship between the master and the transmitter's media clock.
Slave devices recover media clock timing from the clock master Slave devices recover media clock timing from the clock master
stream, using it to synchronise the slave media clock with the stream, using it to synchronise the slave's media clock with the
master. Timestamps in the master clock RTP media stream are taken master. If a common reference clock is available, NTP timestamps in
using the timestamp reference clock shared by the master and slave the master clock RTP media stream are taken using the shared
devices. The timestamps communicate information about media clock reference clock. The NTP timestamps communicate information about
timing (rate, phase) from the master to the slave devices. media clock timing (rate and phase) from the master to the slave
Timestamps are communicated in the usual RTP fashion via RTCP SRs, or devices. NTP timestamps are communicated in the usual RTP fashion
via the RFC6051 [RFC6051] header extension. The stream media format via RTCP SRs, or via the [RFC6051] header extension. If no shared
may indicate other clock information, such as the nominal rate. 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].
Note that slaving of a device media clock to a master device does not Note that the slaving of a device media clock to a master device does
affect the usual RTP lip sync / time alignment algorithms. Time not affect RTP inter-media synchronisation. Time-aligned playout of
aligned playout of two or more RTP sources still relies upon NTP two or more RTP sources still relies upon NTP timestamps supplied via
timestamps supplied via RTCP SRs or by the RFC6051 timestamp header RTCP SRs or by the RFC 6051 timestamp header extension.
extension.
In a given system, master clock identifiers must uniquely identify a In a given system, master clock identifiers must uniquely identify a
single media clock source. Such identifiers MAY be manually single media clock source. Such identifiers MAY be manually
configured, however identifiers SHOULD be generated according to the configured; however, identifiers SHOULD be generated according to the
"short-term persistent RTCP CNAME" algorithm as described in RFC7022 "short-term persistent RTCP CNAME" algorithm as described in
[RFC7022]. Master clock identifiers not already in base64 format [RFC7022]. Master clock identifiers not already in base64 format
MUST be encoded as a base64 strings when used in SDP. Although the MUST be encoded as base64 strings when used in SDP. Although the
RTCP CNAME algorithm is used to generate the master clock identifier, CNAME algorithm is used to generate the master clock identifier, it
it is used to tag RTP sources in SDP descriptions and does not appear is used to tag RTP sources in SDP descriptions and does not appear in
in RTCP as a CNAME. RTCP as a CNAME.
A reference stream can be an RTP stream or AVB stream based on the A reference stream can be an RTP stream or an Audio Video Bridging
IEEE 1722 [IEEE1722] standard. (AVB) stream based on the [IEEE1722] standard.
An RTP clock master stream SHOULD be identified at the source level An RTP clock master stream SHOULD be identified at the source level
by an SSRC [RFC5576] and master clock identifier. An RTP stream that by an SSRC [RFC5576] and master clock identifier. An RTP stream that
provides media clock timing directly from a reference media clock provides media clock timing directly from a reference media clock
(e.g. internal crystal, audio word clock or video blackburst signal) (e.g., internal crystal, audio word clock, or video black burst
SHOULD tag the stream as a master clock source using the "src:" signal) SHOULD tag the stream as a master clock source using the
prefix. If master clock identifiers are declared at the media or "src:" prefix. If master clock identifiers are declared at the media
session level, all RTP sources at or below the level of declaration or session level, all RTP sources at or below the level of
MUST provide equivalent timing to a slave receiver. declaration MUST provide equivalent timing to a slave receiver.
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 media clock master is signalled by A transmitted RTP stream slaved to the media clock master is
including master clock identifier: signalled by including a master clock identifier:
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 An RTP media sender indicates that it is slaved to an IEEE 1722 clock
master via a stream identifier (an EUI-64): master via a stream identifier (an EUI-64):
a=mediaclk:IEEE1722=<StreamID> a=mediaclk:IEEE1722=<StreamID>
An RTP media sender may gateway IEEE 1722 media clock timing to RTP: An RTP media sender may gateway IEEE 1722 media clock timing to RTP:
a=mediaclk:id=src:<media-clktag> IEEE1722=<StreamID> a=mediaclk:id=src:<media-clktag> IEEE1722=<StreamID>
5.4. SDP Signalling of Media Clock Source 5.4. SDP Signalling of Media Clock Source
Specification of the media clock source may be at any or all levels Specification of the media clock source may be at any or all levels
(session, media or source) of an SDP description (see level (session, media, or source) of an SDP description (see level
definitions (Section 3) earlier in this document for more definitions (Section 3) earlier in this document for more
information). information).
Media clock source signalling included at session level provides Media clock source signalling included at session level provides
default parameters for all RTP sessions and sources in the session default parameters for all RTP sessions and sources in the session
description. More specific signalling included at the media level description. More specific signalling included at the media level
overrides default session level signalling. Further, source-level overrides session-level signalling. Further, source-level signalling
signalling overrides media clock source signalling at the enclosing overrides media clock source signalling at the enclosing media level
media level and session level. and session level.
Media clock source signalling may be present or absent on a per- Media clock source signalling may be present or absent on a per-
stream basis. In the absence of media clock source signals, stream basis. In the absence of media clock source signals,
receivers assume an asynchronous media clock generated by the sender. receivers assume an asynchronous media clock generated by the sender.
Media clock source parameters may be repeated at a given level (i.e. Media clock source parameters may be repeated at a given level (i.e.,
for a session or source) to provide information about additional for a session or source) to provide information about additional
clock sources. If the attribute is repeated at a given level, all clock sources. If the attribute is repeated at a given level, all
clocks described at that level are comparable clock sources and may clocks described at that level are comparable clock sources and may
be used interchangeably. be used interchangeably.
General forms of usage: General forms of usage:
session level: a=mediaclk:<mediaclock> session level: a=mediaclk:<mediaclock>
media level: a=mediaclk:<mediaclock> media level: a=mediaclk:<mediaclock>
skipping to change at page 18, line 37 skipping to change at page 18, line 7
rate = "rate=" integer "/" integer rate = "rate=" integer "/" integer
ieee1722-streamid = "IEEE1722=" avb-stream-id ieee1722-streamid = "IEEE1722=" avb-stream-id
avb-stream-id = EUI64 avb-stream-id = EUI64
EUI64 = 7(2HEXDIG "-") 2HEXDIG EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 5: Media Clock Source Signalling Figure 5: Media Clock Source Signalling
5.5. Examples 5.5. Examples
Figure 6 shows an example SDP description 8 channels of 24-bit, 48 Figure 6 shows an example SDP description -- 8 channels of 24-bit, 48
kHz audio transmitted as a multicast stream. Media clock is derived kHz audio transmitted as a multicast stream. Media clock is derived
directly from an IEEE 1588-2008 reference. directly from an IEEE 1588-2008 reference.
v=0 v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1 o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
s= s=
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/8 a=rtpmap:96 L24/48000/8
a=sendonly a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 a=mediaclk:direct=963214424
Figure 6: Media clock directly referenced to IEEE 1588-2008
Figure 7 shows an example SDP description 2 channels of 24-bit, 44056 Figure 6: Media Clock Directly Referenced to IEEE 1588-2008
kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-
2008 reference clock
v=0 Figure 7 shows an example SDP description -- 2 channels of 24-bit,
o=- 1311738121 1311738121 IN IP4 192.0.2.1 44056 kHz NTSC "pull-down" media clock derived directly from an IEEE
c=IN IP4 233.252.0.1/64 1588-2008 reference clock.
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 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
Figure 8 shows the same 48 kHz audio transmission from Figure 6 with Figure 8 shows the same 48 kHz audio transmission from Figure 6 with
media clock derived from another RTP stream. media clock derived from another RTP stream.
v=0 v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1 o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
s= s=
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2 a=rtpmap:96 L24/48000/2
a=sendonly a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender
Figure 8: RTP stream with media clock slaved to a master Figure 8: RTP Stream with Media Clock Slaved to a Master
Figure 9 shows the same 48 kHz audio transmission from Figure 6 with Figure 9 shows the same 48 kHz audio transmission from Figure 6 with
media clock derived from an IEEE 1722 AVB stream. media clock derived from an IEEE 1722 AVB stream.
v=0 v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1 o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
s= s=
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2 a=rtpmap:96 L24/48000/2
a=sendonly a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 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 a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
Figure 9: RTP stream with media clock slaved to an IEEE1722 master Figure 9: RTP Stream with Media Clock Slaved to an
device IEEE 1722 Master Device
6. Signalling Considerations 6. Signalling Considerations
Signalling of timestamp reference clock source (Section 4.8) and Signalling of timestamp reference clock source (Section 4.8) and
media clock source (Section 5.4) is defined to be used either by media clock source (Section 5.4) is defined to be used either by
applications that implement the SDP Offer/Answer model [RFC3264] or applications that implement the SDP Offer/Answer model [RFC3264] or
by applications that use SDP to describe media and transport by applications that use SDP to describe media and transport
configurations. configurations.
A description SHOULD include both reference clock signalling and A description SHOULD include both reference clock signalling and
skipping to change at page 21, line 5 skipping to change at page 20, line 27
with or without a reference clock signalling. with or without a reference clock signalling.
6.1. Usage in Offer/Answer 6.1. Usage in Offer/Answer
During offer/answer, clock source signalling via SDP uses a During offer/answer, clock source signalling via SDP uses a
declarative model. Supported media and/or reference clocks are declarative model. Supported media and/or reference clocks are
specified in the offered SDP description. The answerer may accept or specified in the offered SDP description. The answerer may accept or
reject the offer in an application-specific way depending on the reject the offer in an application-specific way depending on the
clocks that are available and the clocks that are offered. For clocks that are available and the clocks that are offered. For
example, an answerer may choose to accept an offer that lacks a example, an answerer may choose to accept an offer that lacks a
common clock by falling back to a lower performance mode of operation common clock by falling back to a lower-performance mode of operation
(e.g. by assuming reference or media clocks are local rather than (e.g., by assuming reference or media clocks are local rather than
shared). Conversely, the answerer may choose to reject the offer shared). Conversely, the answerer may choose to reject the offer
when the offered clock specifications indicate that the available when the offered clock specifications indicate that the available
reference and/or media clocks are incompatible. reference and/or media clocks are incompatible.
While negotiation of reference clock and media clock attributes is While negotiation of reference clock and media clock attributes is
not defined in this document, negotiation MAY be accomplished using not defined in this document, negotiation MAY be accomplished using
the capabilities negotiation procedures defined in [RFC5939]. the capabilities negotiation procedures defined in [RFC5939].
6.1.1. Indicating Support for Clock Source Signalling 6.1.1. Indicating Support for Clock Source Signalling
skipping to change at page 21, line 33 skipping to change at page 21, line 6
6.1.2. Timestamp Reference Clock 6.1.2. Timestamp Reference Clock
If one or more of the reference clocks specified in the offer are If one or more of the reference clocks specified in the offer are
usable by the answerer, the answerer SHOULD respond with an answer usable by the answerer, the answerer SHOULD respond with an answer
containing the subset of reference clock specifications in the offer containing the subset of reference clock specifications in the offer
that are usable by the answerer. If the answerer rejects the offer that are usable by the answerer. If the answerer rejects the offer
because the available reference clocks are incompatible, the because the available reference clocks are incompatible, the
rejection MUST contain at least one timestamp reference clock rejection MUST contain at least one timestamp reference clock
specification usable by the answerer so that appropriate information specification usable by the answerer so that appropriate information
is available for debugging. If no external reference clock is is available for diagnostics. If no external reference clock is
available to the answerer a local reference clock (Section 4.6) available to the answerer, a local reference clock (Section 4.6)
specification SHOULD be included in the rejection. specification SHOULD be included in the rejection.
In both offers and answers, multiple reference clock specifications In both offers and answers, multiple reference clock specifications
indicate equivalent clocks from different sources which may be used indicate equivalent clocks from different sources that may be used
interchangeably. RTP senders and receivers are assured proper interchangeably. RTP senders and receivers are assured proper
synchronization regardless of which of the specified sources is synchronisation regardless of which of the specified sources is
chosen and, in support of fault tolerance, may switch clock sources chosen and, in support of fault tolerance, may switch clock sources
while streaming. while streaming.
6.1.3. Media Clock 6.1.3. Media Clock
If the media clock mode specified in the offer is acceptable to the If the media clock mode specified in the offer is acceptable to the
answerer, the answerer SHOULD respond with an answer containing the answerer, the answerer SHOULD respond with an answer containing the
same media clock specification as the offer. If the answerer rejects same media clock specification as the offer. If the answerer rejects
the offer because the available reference clocks are incompatible, the offer because the available reference clocks are incompatible,
the rejection MUST contain a media clock specification supported by the rejection MUST contain a media clock specification supported by
the answerer so that appropriate information is available for the answerer so that appropriate information is available for
debugging. If no shared media clocks are available to the answerer diagnostics. If no shared media clocks are available to the
an asynchronous media clock (Section 5.1) specification SHOULD be answerer, an asynchronous media clock (Section 5.1) specification
included in the rejection. SHOULD be included in the rejection.
6.2. Usage Outside of Offer/Answer 6.2. Usage Outside of Offer/Answer
SDP can be employed outside of the Offer/Answer context, for instance SDP can be employed outside of the offer/answer context, for
for multimedia sessions that are announced through the Session instance, for multimedia sessions that are announced through the
Announcement Protocol (SAP) [RFC2974], or streamed through the Real Session Announcement Protocol (SAP) [RFC2974] or streamed through the
Time Streaming Protocol (RTSP) [RFC2326]. Real Time Streaming Protocol (RTSP) [RFC2326].
Devices using published descriptions to join sessions SHOULD assess Devices using published descriptions to join sessions SHOULD assess
their synchronization compatibility with the described session based their synchronisation compatibility with the described session based
on the clock source signalling and SHOULD NOT attempt to join a on the clock source signalling and SHOULD NOT attempt to join a
session with incompatible reference or media clocks. session with incompatible reference or media clocks.
7. Security Considerations 7. Security Considerations
Entities receiving and acting upon an SDP message should note that a Entities receiving and acting upon an SDP message should note that a
session description cannot be trusted unless it has been obtained by session description cannot be trusted unless it has been obtained by
an authenticated transport protocol from a known and trusted source. an authenticated transport protocol from a known and trusted source.
Many different transport protocols may be used to distribute session Many different transport protocols may be used to distribute a
description, and the nature of the authentication will differ from session description, and the nature of the authentication will differ
transport to transport. For some transports, security features are from transport to transport. For some transports, security features
often not deployed. In case a session description has not been are often not deployed. In case a session description has not been
obtained in a trusted manner, the endpoint should exercise care obtained in a trusted manner, the endpoint should exercise care
because, among other attacks, the media sessions received may not be because, among other attacks, the media sessions received may not be
the intended ones, the destination where media is sent to may not be the intended ones, the destination where media is sent to may not be
the expected one, any of the parameters of the session may be the expected one, and any of the parameters of the session may be
incorrect. incorrect.
Incorrect reference or media clock parameters may cause devices or Incorrect reference or media clock parameters may cause devices or
streams to synchronize to unintended clock sources. Normally this streams to synchronise to unintended clock sources. Normally, this
simply results in failure to establish a session or failure to simply results in failure to establish a session or failure to
synchronize once connected. Enough devices fraudulently assigned to synchronise once connected. Enough devices fraudulently assigned to
a specific clock source (e.g. a particular IEEE 1588 grandmaster) a specific clock source (e.g., a particular IEEE 1588 grandmaster)
may, however, constitute a successful denial of service attack on may, however, constitute a successful denial-of-service attack on
that source. Devices MAY wish to validate the integrity of the clock that source. Devices MAY wish to validate the integrity of the clock
description through some means before connecting to unfamiliar clock description through some means before connecting to unfamiliar clock
sources. sources.
The timestamp reference clocks negotiated by this protocol are used The timestamp reference clocks negotiated by this protocol are used
to provide media timing information to RTP. Negotiated timestamp to provide media timing information to RTP. Negotiated timestamp
reference clocks should not be relied upon to provide a secure time reference clocks should not be relied upon to provide a secure time
reference for security critical operations (e.g. the expiration of reference for security critical operations (e.g., the expiration of
public key certificates). public key certificates).
8. IANA Considerations 8. IANA Considerations
This document defines two new SDP attributes: 'ts-refclk' and This document defines two new SDP attributes: "ts-refclk" and
'mediaclk', within the existing Internet Assigned Numbers Authority "mediaclk", within the existing Internet Assigned Numbers Authority
(IANA) registry of SDP Parameters. (IANA) registry of SDP Parameters.
This document also defines a new IANA registry subordinate to the This document also defines a new IANA registry subordinate to the
IANA SDP Parameters registry: the Media Clock Source Parameters IANA SDP Parameters registry: the Media Clock Source Parameters
Registry. Within this new registry, this document defines an initial registry. Within this new registry, this document defines an initial
set of three media clock source parameters. Further, this document set of three media clock source parameters. Further, this document
defines a second new IANA registry subordinate to the IANA SDP defines a second new IANA registry subordinate to the IANA SDP
Parameters registry: the Timestamp Reference Clock Source Parameters Parameters registry: the Timestamp Reference Clock Source Parameters
Registry. Within this new registry, this document defines an initial registry. Within this new registry, this document defines an initial
six parameters. six parameters.
8.1. Reference Clock SDP Parameter 8.1. Reference Clock SDP Parameter
The SDP attribute "ts-refclk" defined by this document is registered The SDP attribute "ts-refclk" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attributes ( "att-field (both session and media level)" & SDP Attributes ( "att-field (both session and media level)" &
"att-field (source level)" ): "att-field (source level)" ):
Attribute name: ts-refclk Attribute name: ts-refclk
Long form: Timestamp reference clock source Long form: Timestamp reference clock source
Type of name: att-field Type of name: att-field
Type of attribute: Session, media and source level Type of attribute: Session, media, and source level
Subject to charset: No Subject to charset: No
Purpose: See section 4 of this document Purpose: See Section 4 of this document
Reference: This document Reference: This document
Values: See section 8.3 of this document Values: See Section 8.3 of this document
Figure 10 Figure 10: Reference Clock SDP Parameter IANA Registration
The attribute has an extensible parameter field and therefore a The attribute has an extensible parameter field; therefore, a
registry for these parameters is required. This new registry is registry for these parameters is required. This new registry is
defined in Section 8.3. defined in Section 8.3.
8.2. Media Clock SDP Parameter 8.2. Media Clock SDP Parameter
The SDP attribute "mediaclk" defined by this document is registered The SDP attribute "mediaclk" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attributes ( "att-field (both session and media level)" & SDP Attributes ( "att-field (both session and media level)" &
"att-field (source level)" ): "att-field (source level)" ):
Attribute name: mediaclk Attribute name: mediaclk
Long form: Media clock source Long form: Media clock source
Type of name: att-field Type of name: att-field
Type of attribute: Session, media and source level Type of attribute: Session, media, and source level
Subject to charset: No Subject to charset: No
Purpose: See section 5 of this document Purpose: See Section 5 of this document
Reference: This document Reference: This document
Values: See section 8.4 of this document Values: See Section 8.4 of this document
Figure 11 Figure 11: Media Clock SDP Parameter IANA Registration
The attribute has an extensible parameter field and therefore a The attribute has an extensible parameter field; therefore, a
registry for these parameters is required. The new registry is registry for these parameters is required. The new registry is
defined in Section 8.4. defined in Section 8.4.
8.3. Timestamp Reference Clock Source Parameters Registry 8.3. Timestamp Reference Clock Source Parameters Registry
This document creates a new IANA sub-registry called the Timestamp This document creates a new IANA subregistry called the Timestamp
Reference Clock Source Parameters Registry, subordinate to the IANA Reference Clock Source Parameters registry, subordinate to the IANA
SDP Parameters registry. Each entry in the Timestamp Reference Clock SDP Parameters registry. Each entry in the Timestamp Reference Clock
Source Parameters Registry contains: Source Parameters registry contains:
Name: Token used in the SDP description (clksrc-param-name) Name: Token used in the SDP description (clksrc-param-name)
Long name: Descriptive name for the timestamp reference clock source Long name: Descriptive name for the timestamp reference clock source
Reference: Reference to the document describing the SDP token Reference: Reference to the document describing the
(clksrc-param-name) and syntax for the optional value associated SDP token (clksrc-param-name) and syntax for the optional
with the token (mediaclock-param-value) value associated with the token (mediaclock-param-value)
Initial values for the Timestamp Reference Clock Source Parameters Initial values for the Timestamp Reference Clock Source Parameters
registry are given below. registry are given below.
Future assignments are to be made through the Specification Required Future assignments are to be made through the Specification Required
policy [RFC5226]. The Name field in the table corresponds to a new policy [RFC5226]. The Name field in the table corresponds to a new
value corresponding to clksrc-param-name. The Reference must specify value corresponding to clksrc-param-name. The Reference must specify
a syntax corresponding to clksrc-param-value. a syntax corresponding to clksrc-param-value.
+---------+--------------------------------+------------------------+ +---------+------------------------------+--------------------------+
| Name | Long Name | Reference | | Name | Long Name | Reference |
+---------+--------------------------------+------------------------+ +---------+------------------------------+--------------------------+
| ntp | Network Time Protocol | This document, section | | ntp | Network Time Protocol | This document, Section 4 |
| | | 4 | | | | |
| ptp | Precision Time Protocol | This document, section | | ptp | Precision Time Protocol | This document, Section 4 |
| | | 4 | | | | |
| gps | Global Position System | This document, section | | gps | Global Positioning System | This document, Section 4 |
| | | 4 | | | | |
| gal | Galileo | This document, section | | gal | Galileo | This document, Section 4 |
| | | 4 | | | | |
| glonass | Global Navigation Satellite | This document, section | | glonass | Global Navigation Satellite | This document, Section 4 |
| | System | 4 | | | System | |
| local | Local Clock | This document, section | | | | |
| | | 4 | | local | Local Clock | This document, Section 4 |
| private | Private Clock | This document, section | | | | |
| | | 4 | | private | Private Clock | This document, Section 4 |
+---------+--------------------------------+------------------------+ +---------+------------------------------+--------------------------+
8.4. Media Clock Source Parameters Registry 8.4. Media Clock Source Parameters Registry
This document creates a new IANA sub-registry called the Media Clock This document creates a new IANA subregistry called the Media Clock
Source Parameters registry, subordinate to the IANA SDP Parameters Source Parameters registry, subordinate to the IANA SDP Parameters
registry. Each entry in the Media Clock Source Parameters Registry registry. Each entry in the Media Clock Source Parameters registry
contains: contains:
Name: Token used in the SDP description (mediaclock-param-name) Name: Token used in the SDP description (mediaclock-param-name)
Long name: Descriptive name for the media clock source type Long name: Descriptive name for the media clock source type
Reference: Reference to the document describing the SDP token Reference: Reference to the document describing the SDP token
(mediaclock-param-name) and syntax for the optional value (mediaclock-param-name) and syntax for the optional
associated with the token (mediaclock-param-value) value associated with the token (mediaclock-param-value)
Initial values for the Media Clock Source Parameters registry are Initial values for the Media Clock Source Parameters registry are
given below. given below.
Future assignments are to be made through the Specification Required Future assignments are to be made through the Specification Required
policy [RFC5226]. The Name field in the table corresponds to a new policy [RFC5226]. The Name field in the table corresponds to a new
value corresponding to mediaclock-param-name. The Reference must value corresponding to mediaclock-param-name. The Reference must
specify a syntax corresponding to mediaclock-param-value. specify a syntax corresponding to mediaclock-param-value.
+----------+--------------------------------+-----------------------+ +----------+-----------------------------+--------------------------+
| Name | Long Name | Reference | | Name | Long Name | Reference |
+----------+--------------------------------+-----------------------+ +----------+-----------------------------+--------------------------+
| sender | Asynchronously Generated Media | This document, | | sender | Asynchronously Generated | This document, Section 5 |
| | Clock | section 5 | | | Media Clock | |
| direct | Direct-Referenced Media Clock | This document, | | | | |
| | | section 5 | | direct | Direct-Referenced Media | This document, Section 5 |
| IEEE1722 | IEEE1722 Media Stream | This document, | | | Clock | |
| | Identifier | section 5 | | | | |
+----------+--------------------------------+-----------------------+ | IEEE1722 | IEEE1722 Media Stream | This document, Section 5 |
| | Identifier | |
+----------+-----------------------------+--------------------------+
8.5. Source-level Attributes 8.5. Source-Level Attributes
[RFC5576] requires new source-level attributes to be registered with [RFC5576] requires new source-level attributes to be registered with
the IANA registry named "att-field (source level)". the IANA registry named "att-field (source level)".
8.5.1. Source-level Timestamp Reference Clock Attribute 8.5.1. Source-Level Timestamp Reference Clock Attribute
The source-level SDP attribute "ts-refclk" defined by this document The source-level SDP attribute "ts-refclk" defined by this document
is registered with the "att-field (source level)" IANA registry of is registered with the "att-field (source level)" IANA registry of
SDP Parameters according to Figure 10. SDP Parameters, according to Figure 10.
8.5.2. Source-level Media Clock Attribute 8.5.2. Source-Level Media Clock Attribute
The source-level SDP attribute "mediaclk" defined by this document is The source-level SDP attribute "mediaclk" defined by this document is
registered with the "att-field (source level)" IANA registry of SDP registered with the "att-field (source level)" IANA registry of SDP
Parameters according to Figure 11. Parameters, according to Figure 11.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Magnus Westerlund and Paul Kyzivat The authors would like to thank Magnus Westerlund and Paul Kyzivat
for valuable comments which resulted in important improvements to for valuable comments that resulted in important improvements to this
this document. document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IEEE1588-2002] [IEEE1588-2002]
Institute of Electrical and Electronics Engineers, "1588- IEEE, "1588-2002 - IEEE Standard for a Precision Clock
2002 - IEEE Standard for a Precision Clock Synchronization Synchronization Protocol for Networked Measurement and
Protocol for Networked Measurement and Control Systems", Control Systems", October 2002,
IEEE Std 1588-2002, 2002, <http://standards.ieee.org/ <http://standards.ieee.org/findstds/
findstds/standard/1588-2002.html>. standard/1588-2002.html>.
[IEEE1588-2008] [IEEE1588-2008]
Institute of Electrical and Electronics Engineers, "1588- IEEE, "1588-2008 - IEEE Standard for a Precision Clock
2008 - IEEE Standard for a Precision Clock Synchronization Synchronization Protocol for Networked Measurement and
Protocol for Networked Measurement and Control Systems", Control Systems", July 2008,
IEEE Std 1588-2008, 2008, <http://standards.ieee.org/ <http://standards.ieee.org/findstds/
findstds/standard/1588-2008.html>. standard/1588-2008.html>.
[IEEE1722] [IEEE1722] IEEE, "1722-2001 - IEEE Standard for Layer 2 Transport
Institute of Electrical and Electronics Engineers, "IEEE Protocol for Time Sensitive Applications in a Bridged
Standard for Layer 2 Transport Protocol for Time Sensitive Local Area Network", May 2011,
Applications in a Bridged Local Area Network", <http:// <http://standards.ieee.org/findstds/
standards.ieee.org/findstds/standard/1722-2011.html>. standard/1722-2011.html>.
[IEEE802.1AS-2011] [IEEE802.1AS-2011]
Institute of Electrical and Electronics Engineers, "Timing IEEE, "802.1AS-2011 - IEEE Standard for Local and
and Synchronization for Time-Sensitive Applications in Metropolitan Area Networks - Timing and Synchronization
Bridged Local Area Networks", <http://standards.ieee.org/ for Time-Sensitive Applications in Bridged Local Area
findstds/standard/802.1AS-2011.html>. Networks", February 2011,
<http://standards.ieee.org/findstds/
standard/802.1AS-2011.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 28, line 11 skipping to change at page 28, line 32
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
10.2. Informative References 10.2. Informative References
[AES11-2009] [AES11-2009]
Audio Engineering Society, "AES11-2009: AES recommended Audio Engineering Society, "AES11-2009: AES recommended
practice for digital audio engineering - Synchronization practice for digital audio engineering - Synchronization
of digital audio equipment in studio operations", of digital audio equipment in studio operations", February
<http://www.aes.org/standards/>. 2010, <http://www.aes.org/standards/>.
[I-D.ietf-avtcore-idms]
Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
Montagud, M., and K. Gross, "Inter-destination Media
Synchronization using the RTP Control Protocol (RTCP)",
draft-ietf-avtcore-idms-13 (work in progress),
August 2013.
[I-D.ietf-avtcore-leap-second]
Gross, K. and R. Brandenburg, "RTP and Leap Seconds",
draft-ietf-avtcore-leap-second-07 (work in progress),
December 2013.
[IEEE802.1BA-2011] [IEEE802.1BA-2011]
Institute of Electrical and Electronics Engineers, "Audio IEEE, "802.1BA-2011 - IEEE Standard for Local and
Video Bridging (AVB) Systems", <http://standards.ieee.org/ metropolitan area networks -- Audio Video Bridging (AVB)
findstds/standard/802.1BA-2011.html>. Systems", September 2011,
<http://standards.ieee.org/findstds/
standard/802.1BA-2011.html>.
[IS-GPS-200F] [IS-GPS-200F]
Global Positioning Systems Directorate, "Navstar GPS Space Global Positioning Systems Directorate, "Navstar GPS Space
Segment/Navigation User Segment Interfaces", Segment/Navigation User Segment Interfaces", IS-GPS-200F ,
September 2011. September 2011,
<http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
[Olsen] Olsen, D., "Time Accuracy Requirements in Audio Networks", [Olsen] Olsen, D., "Time Accuracy Requirements in Audio Networks",
April 2007, <http://www.ieee802.org/1/files/public/ April 2007,
docs2007/as-dolsen-time-accuracy-0407.pdf>. <http://www.ieee802.org/1/files/public/docs2007/
as-dolsen-time-accuracy-0407.pdf>.
[RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, [RFC0868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
RFC 868, May 1983. RFC 868, May 1983.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010. Capability Negotiation", RFC 5939, September 2010.
[SMPTE-318-1999] [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC
7164, March 2014.
[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.
[SMPTE-318M-1999]
Society of Motion Picture & Television Engineers, Society of Motion Picture & Television Engineers,
"Television and Audio - Synchronization of 59.94- or 50-Hz "Television and Audio - Synchronization of 59.94- or 50-Hz
Related Video and Audio Systems in Analog and Digital Related Video and Audio Systems in Analog and Digital
Areas - Reference Signals", <http://standards.smpte.org/>. Areas - Reference Signals", ST 318:1999,
<http://standards.smpte.org/>.
Authors' Addresses Authors' Addresses
Aidan Williams Aidan Williams
Audinate Audinate
Level 1, 458 Wattle St Level 1, 458 Wattle St
Ultimo, NSW 2007 Ultimo, NSW 2007
Australia Australia
Phone: +61 2 8090 1000 Phone: +61 2 8090 1000
Fax: +61 2 8090 1001 Fax: +61 2 8090 1001
Email: aidan.williams@audinate.com EMail: aidan.williams@audinate.com
URI: http://www.audinate.com/ URI: http://www.audinate.com/
Kevin Gross Kevin Gross
AVA Networks AVA Networks
Boulder, CO Boulder, CO
US US
Email: kevin.gross@avanw.com EMail: kevin.gross@avanw.com
URI: http://www.avanw.com/ URI: http://www.avanw.com/
Ray van Brandenburg Ray van Brandenburg
TNO TNO
Brassersplein 2 Brassersplein 2
Delft 2612CT Delft 2612CT
the Netherlands The Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl EMail: ray.vanbrandenburg@tno.nl
Hans Stokking Hans Stokking
TNO TNO
Brassersplein 2 Brassersplein 2
Delft 2612CT Delft 2612CT
the Netherlands The Netherlands
Email: hans.stokking@tno.nl EMail: hans.stokking@tno.nl
 End of changes. 159 change blocks. 
503 lines changed or deleted 508 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/