draft-ietf-avtcore-clksrc-09.txt   draft-ietf-avtcore-clksrc-10.txt 
Audio/Video Transport Core Maintenance A. Williams Audio/Video Transport Core A. Williams
Internet-Draft Audinate Maintenance Audinate
Intended status: Standards Track K. Gross Internet-Draft K. Gross
Expires: June 9, 2014 AVA Networks Intended status: Standards Track AVA Networks
R. van Brandenburg Expires: September 15, 2014 R. van Brandenburg
H. Stokking H. Stokking
TNO TNO
December 6, 2013 March 14, 2014
RTP Clock Source Signalling RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-09 draft-ietf-avtcore-clksrc-10
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 SDP signalling identifying timestamp reference clock sources and SDP
signalling identifying the media clock sources in a multimedia signalling identifying the media clock sources in a multimedia
session. session.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 9, 2014. This Internet-Draft will expire on September 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 6
4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 5 4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 6
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . 6 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 7
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . 6 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 7
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 9
4.5. Private Reference Clocks . . . . . . . . . . . . . . . . 8 4.5. Private Reference Clocks . . . . . . . . . . . . . . . . . 9
4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . 8 4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . . 9
4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . 8 4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . . 9
4.8. SDP Signalling of Timestamp Reference Clock Source . . . 8 4.8. SDP Signalling of Timestamp Reference Clock Source . . . . 10
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . 10 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 12
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 13
5.1. Asynchronously Generated Media Clock . . . . . . . . . . 12 5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 13
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 15
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . 15 5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 16
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Signalling Considerations . . . . . . . . . . . . . . . . . . 18 6. Signalling Considerations . . . . . . . . . . . . . . . . . . 20
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19 6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 20
6.1.1. Indicating Support for Clock Source Signalling . . . 19 6.1.1. Indicating Support for Clock Source Signalling . . . . 21
6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 19 6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 21
6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 19 6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 21
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 20 6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 21 8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 23
8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 21 8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 24
8.3. Timestamp Reference Clock Source Parameters Registry . . 22 8.3. Timestamp Reference Clock Source Parameters Registry . . . 24
8.4. Media Clock Source Parameters Registry . . . . . . . . . 23 8.4. Media Clock Source Parameters Registry . . . . . . . . . . 25
8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 23 8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 26
8.5.1. Source-level Timestamp Reference Clock Attribute . . 24 8.5.1. Source-level Timestamp Reference Clock Attribute . . . 26
8.5.2. Source-level Media Clock Attribute . . . . . . . . . 24 8.5.2. Source-level Media Clock Attribute . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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 for providing estimates of round trip
time (RTT) and other statistical parameters. time (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 which 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
skipping to change at page 4, line 23 skipping to change at page 5, line 20
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 synchronized, the effect of multiple screens
acting as one is broken. acting as one is broken.
Networked Audio : Networked loudspeakers, amplifiers and analogue I/ Networked Audio : Networked loudspeakers, amplifiers and analogue
O devices transmitting or receiving audio signals via RTP can be I/O devices transmitting or receiving audio signals via RTP can be
connected to various parts of a building or campus network. Such connected to various parts of a building or campus network. Such
situations can for example be found in large conference rooms, situations can for example be found in large conference rooms,
legislative chambers, classrooms (especially those supporting legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as distance learning) and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in stadiums. Since humans are more susceptible to differences in
audio delay, this use case needs even more accuracy than the video audio delay, this use case needs even more accuracy than the video
wall use case. Depending on the exact application, the need for wall use case. Depending on the exact application, the need for
accuracy can then be in the range of microseconds [Olsen]. 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
skipping to change at page 5, line 32 skipping to change at page 6, line 30
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 synchronized 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 unto 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. PTP
[IEEE1588-2008], NTP) can explicitly indicate that the master [IEEE1588-2008], NTP) can explicitly indicate that the master
clock is providing a traceable time reference over the network. 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], PTP [IEEE1588-2008]) and radio clocks
(e.g. GPS [IS-GPS-200F]). (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/
receiver is synchronised to a reference clock. receiver is synchronised to a reference clock.
4.1. Clock synchronization 4.1. Clock synchronization
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 can be used as if they came
from the same clock. Providing they are sufficiently synchronised, from the same clock. Providing they are sufficiently synchronised,
timestamps produced in one RTP sender or receiver can be directly timestamps produced in one RTP sender or receiver can be directly
compared to a local clock in another RTP sender or receiver. compared to a local clock in another RTP 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) section for a discussion of applications
and their corresponding requirements. To serve as a reference clock, and their corresponding requirements. To serve as a reference clock,
clocks must minimally be syntonized (exactly frequency matched) to clocks must minimally be syntonized (exactly frequency matched) to
skipping to change at page 6, line 17 skipping to change at page 7, line 15
timestamps produced in one RTP sender or receiver can be directly timestamps produced in one RTP sender or receiver can be directly
compared to a local clock in another RTP sender or receiver. compared to a local clock in another RTP 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) section for a discussion of applications
and their corresponding requirements. To serve as a reference clock, and their corresponding requirements. To serve as a reference clock,
clocks must minimally be syntonized (exactly frequency matched) to clocks must minimally be syntonized (exactly frequency matched) to
one another. one another.
Sufficient synchronisation can typically be achieving by using a Sufficient synchronisation can typically be achieving by using a
network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to
synchronize all devices to a single master clock. synchronize 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). This concept may be used in conjunction with (e.g. GPS, Galileo, GLONASS). This concept may be used in
network time protocols as some protocols (e.g. PTP, NTP) allow master conjunction with network time protocols as some protocols (e.g. PTP,
clocks to indicate explicitly that they are providing traceable time. NTP) allow master clocks to indicate explicitly that they are
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 hostname (or IP address) and an
optional port number. If the port number is not indicated, it is 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
skipping to change at page 7, line 21 skipping to change at page 8, line 18
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 Layer-2 only profile of IEEE 1588-2008 for use in Audio/Video
Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011]. Bridged LANs as described in IEEE 802.1BA-2011 [IEEE802.1BA-2011].
Each IEEE 1588 clock is identified by a globally unique EUI-64 called Each IEEE 1588 clock is identified by an EUI-64 called a
a "ClockIdentity". A slave clock using one of the IEEE 1588 family "ClockIdentity". A slave clock using one of the IEEE 1588 family of
of network time protocols acquires the ClockIdentity/EUI-64 of the network time protocols acquires the ClockIdentity/EUI-64 of the
grandmaster clock that is the ultimate source of timing information grandmaster clock that is the ultimate source of timing information
for the network. A boundary clock which is itself slaved to another for the network. A boundary clock which is itself slaved to another
boundary clock or the grandmaster passes the grandmaster boundary clock or the grandmaster passes the grandmaster
ClockIdentity through to its slaves. 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 developed, 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
skipping to change at page 8, line 12 skipping to change at page 9, line 10
"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 and via a hardware radio receiver interface. Examples include GPS,
Galileo. Apart from the name of the reference clock system, no Galileo and GLONASS. Apart from the name of the reference clock
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
skipping to change at page 8, line 45 skipping to change at page 9, line 43
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 to delivering traceable time. Providing adjustments
are made for differing epochs, timezones and leap seconds, timestamps are 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.
Since all NTP and PTP servers providing traceable time can be Marking a clock as traceable allows additional information (e.g. IP
directly compared, it is not necessary to identify traceable time addresses, PTP master identifiers and the like) to be omitted from
servers by protocol address or other identifiers. the SDP since any traceable clock available at the answerer is
considered to be an appropriate timestamp reference clock. For
example, an offerer could could specify ts-refclk:ntp=/traceable/ and
the answerer could use GPS as a reference clock since GPS is a source
of 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 (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 session-level
provides default parameters for all RTP sessions and sources in the provides default parameters for all RTP sessions and sources in the
session description. More specific signalling included at the media session description. More specific signalling included at the media
level overrides default session level signalling. More specific level overrides default session level signalling. More specific
signalling included at the source level overrides default media level signalling included at the source level overrides default media level
skipping to change at page 9, line 43 skipping to change at page 10, line 46
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 5324>
HEXDIG = <See RFC 5324> HEXDIG = <See RFC 5324>
CRLF = <See RFC 5324> CRLF = <See RFC 5324>
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 / 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 10, line 41 skipping to change at page 11, line 43
; PTP domain allowed number range: 0-127 (IEEE 1588-2008) ; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
ptp-domain-n1 = DIGIT ; 0-9 ptp-domain-n1 = DIGIT ; 0-9
ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99
ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119
/ "12" %x30-37 ; 120-127 / "12" %x30-37 ; 120-127
gps = "gps" gps = "gps"
gal = "gal" gal = "gal"
glonass = "glonass"
local = "local" local = "local"
private = "private" [ ":traceable" ] private = "private" [ ":traceable" ]
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
skipping to change at page 11, line 27 skipping to change at page 12, line 30
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
skipping to change at page 13, line 21 skipping to change at page 14, line 24
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 representation in the RTP header would have been 2,460,938,240 at 00:
00:00:00 1 January 2013. If an offset of 23,465 had been signalled, 00:00 1 January 2013. If an offset of 23,465 had been signalled, the
the clock value would have been 2,460,961,705. 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 computed. 2,208,988,800 seconds elapsed between the NTP epoch and 00:
00:00:00 1 January 1970 [RFC0868]. Between the beginning of 1970 and 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 total
of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1 January of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1 January
2013. A 90 kHz RTP clock for a video stream would have advanced 2013. A 90 kHz RTP clock for a video stream would have advanced
320,938,850,250,000 units over this period. With a signalled offset 320,938,850,250,000 units over this period. With a signalled offset
of 0, the RTP clock value modulo the 32-bit unsigned representation of 0, the RTP clock value modulo the 32-bit unsigned representation
would have been 1,714,023,696 at 00:00:00 1 January 2013. 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 which contain NTP and RTP timestamps
skipping to change at page 14, line 6 skipping to change at page 15, line 7
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 Figure "oddball" audio sample rates associated with NTSC video (see
7). Modified rates are not advised for video streams which generally Figure 7). Modified rates are not advised for video streams which
use a 90 kHz RTP clock regardless of frame rate or sample rate used generally use a 90 kHz RTP clock regardless of frame rate or sample
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
skipping to change at page 17, line 26 skipping to change at page 19, line 19
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 6: Media clock directly referenced to IEEE 1588-2008
Figure 7 shows an example SDP description 2 channels of 24-bit, 44056 Figure 7 shows an example SDP description 2 channels of 24-bit, 44056
kHz NTSC "pull-down" media clock derived directly from an IEEE kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-
1588-2008 reference clock 2008 reference clock
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/44100/2 a=rtpmap:96 L24/44100/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
skipping to change at page 19, line 14 skipping to change at page 21, line 6
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 19, line 40 skipping to change at page 21, line 32
specification in the SDP description. specification in the SDP description.
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. If no external reference clock specification usable by the answerer so that appropriate information
is available to the answerer a local reference clock (Section 4.6) is available for debugging. If no external reference clock is
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 which 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 synchronization 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
skipping to change at page 20, line 4 skipping to change at page 21, line 45
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 which 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 synchronization 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. If no shared media clocks are available to the the answerer so that appropriate information is available for
answerer an asynchronous media clock (Section 5.1) specification debugging. If no shared media clocks are available to the answerer
SHOULD be included in the rejection. an asynchronous media clock (Section 5.1) specification 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 instance
for multimedia sessions that are announced through the Session for multimedia sessions that are announced through the Session
Announcement Protocol (SAP) [RFC2974], or streamed through the Real Announcement Protocol (SAP) [RFC2974], or streamed through the Real
Time Streaming Protocol (RTSP) [RFC2326]. 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 synchronization 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 be aware Entities receiving and acting upon an SDP message should note that a
that a session description cannot be trusted unless it has been session description cannot be trusted unless it has been obtained by
obtained by an authenticated transport protocol from a known and an authenticated transport protocol from a known and trusted source.
trusted source. Many different transport protocols may be used to Many different transport protocols may be used to distribute session
distribute session description, and the nature of the authentication description, and the nature of the authentication will differ from
will differ from transport to transport. For some transports, transport to transport. For some transports, security features are
security features are often not deployed. In case a session often not deployed. In case a session description has not been
description has not been obtained in a trusted manner, the endpoint obtained in a trusted manner, the endpoint SHOULD exercise care
SHOULD exercise care because, among other attacks, the media sessions because, among other attacks, the media sessions received may not be
received may not be the intended ones, the destination where media is the intended ones, the destination where media is sent to may not be
sent to may not be the expected one, any of the parameters of the the expected one, any of the parameters of the session may be
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 synchronize 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 synchronize 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 a 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
to provide media timing information to RTP. Negotiated timestamp
reference clocks SHOULD NOT be relied upon to provide a secure time
reference for security critical operations (e.g. the expiration of
public key certificates).
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
skipping to change at page 23, line 5 skipping to change at page 25, line 10
with the token (mediaclock-param-value) 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 4 | | ntp | Network Time Protocol | This document, section |
| ptp | Precision Time Protocol | This document, section 4 | | | | 4 |
| gps | Global Position System | This document, section 4 | | ptp | Precision Time Protocol | This document, section |
| gal | Galileo | This document, section 4 | | | | 4 |
| local | Local Clock | This document, section 4 | | gps | Global Position System | This document, section |
| private | Private Clock | This document, section 4 | | | | 4 |
+---------+-------------------------+--------------------------+ | gal | Galileo | This document, section |
| | | 4 |
| glonass | Global Navigation Satellite | This document, section |
| | System | 4 |
| local | Local 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 sub-registry 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)
skipping to change at page 23, line 39 skipping to change at page 26, line 5
associated with the token (mediaclock-param-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 Media | This document, |
| | Clock | section 5 | | | Clock | section 5 |
| direct | Direct-Referenced Media Clock | This document, | | direct | Direct-Referenced Media Clock | This document, |
| | | section 5 | | | | section 5 |
| IEEE1722 | IEEE1722 Media Stream | This document, | | IEEE1722 | IEEE1722 Media Stream | This document, |
| | Identifier | section 5 | | | Identifier | section 5 |
+-------------+---------------------------------+-------------------+ +----------+--------------------------------+-----------------------+
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
skipping to change at page 24, line 31 skipping to change at page 26, line 44
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 which resulted in important improvements to
this document. this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IEEE1588-2002] [IEEE1588-2002]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers, "1588-
"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", IEEE Std 1588-2002, 2002, <http:// IEEE Std 1588-2002, 2002, <http://standards.ieee.org/
standards.ieee.org/findstds/standard/1588-2002.html>. findstds/standard/1588-2002.html>.
[IEEE1588-2008] [IEEE1588-2008]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers, "1588-
"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", IEEE Std 1588-2008, 2008, <http:// IEEE Std 1588-2008, 2008, <http://standards.ieee.org/
standards.ieee.org/findstds/standard/1588-2008.html>. findstds/standard/1588-2008.html>.
[IEEE1722] [IEEE1722]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Layer 2 Transport Protocol for Time Sensitive Standard for Layer 2 Transport Protocol for Time Sensitive
Applications in a Bridged Local Area Network", <http:// Applications in a Bridged Local Area Network", <http://
standards.ieee.org/findstds/standard/1722-2011.html>. standards.ieee.org/findstds/standard/1722-2011.html>.
[IEEE802.1AS-2011] [IEEE802.1AS-2011]
Institute of Electrical and Electronics Engineers, "Timing Institute of Electrical and Electronics Engineers, "Timing
and Synchronization for Time-Sensitive Applications in and Synchronization for Time-Sensitive Applications in
Bridged Local Area Networks", <http://standards.ieee.org/ Bridged Local Area Networks", <http://standards.ieee.org/
findstds/standard/802.1AS-2011.html>. 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, June with Session Description Protocol (SDP)", RFC 3264,
2002. June 2002.
[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 26, line 7 skipping to change at page 28, line 18
[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",
<http://www.aes.org/standards/>. <http://www.aes.org/standards/>.
[I-D.ietf-avtcore-idms] [I-D.ietf-avtcore-idms]
Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
Montagud, M., and K. Gross, "Inter-destination Media Montagud, M., and K. Gross, "Inter-destination Media
Synchronization using the RTP Control Protocol (RTCP)", Synchronization using the RTP Control Protocol (RTCP)",
draft-ietf-avtcore-idms-13 (work in progress), August draft-ietf-avtcore-idms-13 (work in progress),
2013. August 2013.
[I-D.ietf-avtcore-leap-second] [I-D.ietf-avtcore-leap-second]
Gross, K. and R. Brandenburg, "RTP and Leap Seconds", Gross, K. and R. Brandenburg, "RTP and Leap Seconds",
draft-ietf-avtcore-leap-second-06 (work in progress), draft-ietf-avtcore-leap-second-07 (work in progress),
November 2013. December 2013.
[IEEE802.1BA-2011] [IEEE802.1BA-2011]
Institute of Electrical and Electronics Engineers, "Audio Institute of Electrical and Electronics Engineers, "Audio
Video Bridging (AVB) Systems", <http://standards.ieee.org/ Video Bridging (AVB) Systems", <http://standards.ieee.org/
findstds/standard/802.1BA-2011.html>. 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", September Segment/Navigation User Segment Interfaces",
2011. September 2011.
[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, <http://www.ieee802.org/1/files/public/
docs2007/as-dolsen-time-accuracy-0407.pdf>. 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.
 End of changes. 43 change blocks. 
153 lines changed or deleted 180 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/