draft-ietf-avtcore-clksrc-00.txt   draft-ietf-avtcore-clksrc-01.txt 
Audio/Video Transport Core A. Williams Audio/Video Transport Core A. Williams
Maintenance Audinate Maintenance Audinate
Internet-Draft K. Gross Internet-Draft K. Gross
Intended status: Standards Track AVA Networks Intended status: Standards Track AVA Networks
Expires: January 4, 2013 R. van Brandenburg Expires: April 25, 2013 R. van Brandenburg
H. Stokking H. Stokking
TNO TNO
July 3, 2012 October 22, 2012
RTP Clock Source Signalling RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-00 draft-ietf-avtcore-clksrc-01
Abstract Abstract
NTP timestamps are used by several RTP protocols for synchronisation NTP timestamps are used by several RTP protocols for synchronisation
and statistical measurement. This memo specifies SDP signalling and statistical measurement. This memo specifies SDP signalling
identifying NTP timestamp clock sources and SDP signalling identifying NTP timestamp clock sources and SDP signalling
identifying the media clock sources in a multimedia session. identifying the media clock sources in a multimedia session.
Requirements Language Requirements Language
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 January 4, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5
4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 5 4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 5
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 6 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 6
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 6 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 6
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 7 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 7
4.5. Other Reference Clocks . . . . . . . . . . . . . . . . . . 8 4.5. Other Reference Clocks . . . . . . . . . . . . . . . . . . 8
4.6. Traceable Reference Clocks . . . . . . . . . . . . . . . . 8 4.6. Traceable Reference Clocks . . . . . . . . . . . . . . . . 8
4.7. Synchronisation Confidence . . . . . . . . . . . . . . . . 8 4.7. Synchronisation Quality . . . . . . . . . . . . . . . . . 8
4.8. SDP Signalling of Timestamp Clock Source . . . . . . . . . 9 4.8. SDP Signalling of Timestamp Clock Source . . . . . . . . . 9
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12
5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13 5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 13 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 13
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 13 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.4. Signalling Grammar . . . . . . . . . . . . . . . . . . . . 14 5.4. Signalling Grammar . . . . . . . . . . . . . . . . . . . . 15
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
RTP protocols use NTP format timestamps to facilitate media stream RTP protocols use NTP format timestamps to facilitate media stream
synchronisation and for providing estimates of round trip time (RTT) synchronisation and for providing estimates of round trip time (RTT)
and other statistical parameters. 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 3, line 29 skipping to change at page 3, line 29
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 is often distinct from the reference clock used to provide
timestamps. A reference media clock may be provided along with an timestamps. A reference media clock may be provided along with an
audio or video signal interface, or via a dedicated clock signal audio or video signal interface, or via a dedicated clock signal
(e.g. genlock [12] or audio word clock [13]). If sending and (e.g. genlock [16] or audio word clock [17]). If sending and
receiving media clocks are known to be synchronised to a common receiving media clocks are known to be synchronised to a common
reference clock, performance can improved by minimising buffering and reference clock, performance can improved by minimising buffering and
avoiding rate conversion. avoiding rate conversion.
This specification defines SDP signalling of timestamp clock sources This specification defines SDP signalling of timestamp clock sources
and media reference clock sources. and media reference clock sources.
2. Applications 2. Applications
Timestamp clock source and reference media clock signalling benefit Timestamp clock source and reference 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 [6] Social TV RTCP for inter-destination media synchronization [8]
defines social TV as the combination of media content consumption defines social TV as the combination of media content consumption
by two or more users at different devices and locations and real- by two or more users at different devices and locations and real-
time communication between those users. An example of Social TV, time communication between those users. An example of Social TV,
is where two or more users are watching the same television is where two or more users are watching the same television
broadcast at different devices and/or locations, while broadcast at different devices and/or locations, while
communicating with each other using text, audio and/or video. A communicating with each other using text, audio and/or video. A
skew in the media playout of the two or more users can have skew in the media playout of the two or more users can have
adverse effects on their experience. A well-known use case here adverse effects on their experience. A well-known use case here
is one friend experiencing a goal in a football match well before is one friend experiencing a goal in a football match well before
or after other friends. or after other friends.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
Networked Audio Networked loudspeakers, amplifiers and analogue I/O Networked Audio Networked loudspeakers, amplifiers and analogue I/O
devices transmitting or receiving audio signals via RTP can be 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 [14]. accuracy can then be in the range of microseconds [18].
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 which 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 used
in radar applications, for instance. in radar applications, for instance.
3. Definitions 3. Definitions
skipping to change at page 5, line 28 skipping to change at page 5, line 28
appears after each "m"-line. appears after each "m"-line.
source level Source level information applies to a single stream of source level Source level information applies to a single stream of
RTP packets, identified by an RTP SSRC Source-Specific Media RTP packets, identified by an RTP SSRC Source-Specific Media
Attributes in the Session Description Protocol (SDP) [2] defines Attributes in the Session Description Protocol (SDP) [2] defines
how source-level information is included into an SDP session how source-level information is included into an SDP session
description. description.
traceable time A clock is considered to provide traceable time if it traceable time A clock is considered to provide traceable time if it
can be proven to be synchronised to a global time reference. GPS can be proven to be synchronised to a global time reference. GPS
[7] is commonly used to provide a traceable time reference. Some [9] is commonly used to provide a traceable time reference. Some
network time synchronisation protocols (e.g. PTP [8], NTP) can network time synchronisation protocols (e.g. PTP [10], NTP) can
explicitly indicate that the master clock is providing a traceable explicitly indicate that the master clock is providing a traceable
time reference over the network. time reference over the network.
4. Timestamp Reference Clock Source Signalling 4. Timestamp Reference Clock Source Signalling
The NTP timestamps used by RTP are taken by reading a local real-time The NTP timestamps used by RTP are taken by reading a local real-time
clock at the sender or receiver. This local clock may be 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 [9]) and radio clocks like GPS [7]. protocols (e.g. NTP [11]) and radio clocks (e.g. GPS [9]).
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 cam 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/receiver can be directly timestamps produced in one RTP sender or receiver can be directly
compared to a local clock in another RTP sender/receiver. The compared to a local clock in another RTP sender or receiver.
timestamps produced by synchronized local clocks in two or more RTP
senders/receivers can be directly compared.
The accuracy of synchronization required is application dependent. The accuracy of synchronization 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 synchronization can typically be achieving by using a Sufficient synchronization 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.
skipping to change at page 6, line 32 skipping to change at page 6, line 30
to a global time reference. to a global time reference.
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 they are interchangeable. RTP session description to indicate that they are interchangeable. RTP
senders/receivers can use any of the listed NTP servers to govern a senders or receivers can use any of the listed NTP servers to govern
local clock that is equivalent to a local clock slaved to a different a local clock that is equivalent to a local clock slaved to a
server. different server.
4.3. Identifying PTP Reference Clocks 4.3. Identifying PTP Reference Clocks
The IEEE 1588 Precision Time Protocol (PTP) family of clock The IEEE 1588 Precision Time Protocol (PTP) family of clock
synchronisation protocols provides a shared reference clock in an synchronisation protocols provides a shared reference clock in an
network - typically a LAN. IEEE 1588 provides sub-microsecond network - typically a LAN. IEEE 1588 provides sub-microsecond
synchronisation between devices on a LAN and typically locks within synchronisation between devices on a LAN and typically locks within
seconds at startup. With support from Ethernet switches, IEEE 1588 seconds at startup. With support from Ethernet switches, IEEE 1588
protocols can achieve nanosecond timing accuracy in LANs. Network protocols can achieve nanosecond timing accuracy in LANs. Network
interface chips and cards supporting hardware time-stamping of timing interface chips and cards supporting hardware time-stamping of timing
critical protocol messages are also available. critical protocol messages are also available.
Three flavours of IEEE 1588 are in use today: Three flavours of IEEE 1588 are in use today:
o IEEE 1588-2002 [10]: the original "Standard for a Precision Clock o IEEE 1588-2002 [12]: the original "Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control Synchronization Protocol for Networked Measurement and Control
Systems". This is also known as IEEE1588v1 or PTPv1. Systems". This is also known as IEEE1588v1 or PTPv1.
o IEEE 1588-2008 [8]: the second version of the "Standard for a o IEEE 1588-2008 [10]: the second version of the "Standard for a
Precision Clock Synchronization Protocol for Networked Measurement Precision Clock Synchronization Protocol for Networked Measurement
and Control Systems". This is a revised version of the original and Control Systems". This is a revised version of the original
IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2. IEEE1588-2002 standard and is also known as IEEE1588v2 or PTPv2.
IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002. IEEE 1588-2008 is not protocol compatible with IEEE 1588-2002.
o IEEE 802.1AS [11]: "Timing and Synchronization for Time Sensitive o IEEE 802.1AS [13]: "Timing and Synchronization for Time Sensitive
Applications in Bridged Local Area Networks". This is a Layer-2 Applications in Bridged Local Area Networks". This is a Layer-2
only profile of IEEE 1588-2008 for use in Audio/Video Bridged only profile of IEEE 1588-2008 for use in Audio/Video Bridged LANs
LANs. as described in IEEE 802.1BA-2011 [14].
Each IEEE 1588 clock is identified by a globally unique EUI-64 called Each IEEE 1588 clock is identified by a globally unique EUI-64 called
a "ClockIdentity". A slave clock using one of the IEEE 1588 family a "ClockIdentity". A slave clock using one of the IEEE 1588 family
of network time protocols acquires the ClockIdentity/EUI-64 of the of 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 master clock which is itself slaved to another for the network. A boundary clock which is itself slaved to another
master clock passes the grandmaster ClockIdentity through to its boundar clock or the grandmaster passes the grandmaster ClockIdentity
slaves. 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 network protocol domains, on a single network, forming distinct PTP domains, each of which may
each of which may have a different grandmaster clock. As the IEEE have a different grandmaster clock. As the IEEE 1588 standards have
1588 standards have developed, the definition of PTP domains has developed, the definition of PTP domains has changed. IEEE 1588-2002
changed. IEEE 1588-2002 identifies protocol subdomains by a textual identifies protocol subdomains by a textual name, but IEEE 1588-2008
name, but IEEE 1588-2008 identifies protocol domains using a numeric identifies protocol domains using a numeric domain number. 802.1AS is
domain number. 802.1AS is a Layer-2 profile of IEEE 1588-2008 a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock
supporting a single numeric clock domain (0). domain (0).
When PTP subdomains are signalled via SDP, senders and receivers When PTP domains are signalled via SDP, senders and receivers SHOULD
SHOULD check that both grandmaster ClockIdentity and PTP subdomain check that both grandmaster ClockIdentity and PTP domain match when
match when determining clock equivalence. determining clock equivalence.
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 favourably biased by setting stratum values, preferred master or biased by configuration parameters to influence the election
clock bits, or other parameters to influence the election process. process. In some systems it may be desirable to limit the number of
In some systems it may be desirable to limit the number of possible possible PTP clock masters to avoid the need to re-signal timestamp
PTP clock masters to avoid re-signalling timestamp clock sources when clock sources when the clock master changes.
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 and
Galileo. Apart from the name of the reference clock system, no Galileo. Apart from the name of the reference clock system, no
further identification is required. further identification is required.
4.5. Other Reference Clocks 4.5. Other Reference Clocks
At the time of writing, it is common for RTP senders/receivers not to RFC 3550 allows senders and receivers to either use a local wallclock
synchronise their local timestamp clocks to a shared master. An reference for their NTP timestamps or, by setting the timestamp field
unsynchronised clock such as a quartz oscillator is identified as a to 0, to supply no timstamps at all. Both are common practice in
"local" reference clock. embedded RTP implementations. These clocks are identified as "local"
and can only be assumed to be equivalent to clocks originating from
the same device.
In some systems, all RTP senders/receivers may use a timestamp clock In other systems, all RTP senders and receivers may use a timestamp
synchronised to a reference clock that is not provided by one of the clock synchronised to a reference clock that is not provided by one
methods listed above. Examples may include the reference time of the methods listed above. Examples may include the reference time
information provided by digital television or cellular services. information provided by digital television or cellular services.
These sources are identified as "private" reference clocks. All RTP These sources are identified as "private" reference clocks. All RTP
senders/receivers in a session using a private reference clock are senders and receivers in a session using a private reference clock
assumed to have a mechanism outside this specification confirming are assumed to have a mechanism outside this specification for
that their local timestamp clocks are equivalent. determining whether their timestamp clocks are equivalent.
4.6. Traceable Reference Clocks 4.6. Traceable Reference Clocks
A timestamp clock source may be labelled "traceable" if it is known A timestamp clock source may be labelled "traceable" if it is known
to be sourced from a global time reference such as TAI or UTC. to be sourced from a global time reference such as TAI or UTC.
Providing adjustments are made for differing time bases, timestamps Providing adjustments are made for differing time bases, 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 Since all NTP and PTP servers providing traceable time can be
directly compared, it is not necessary to identify traceable time directly compared, it is not necessary to identify traceable time
servers by protocol address or other identifiers. servers by protocol address or other identifiers.
4.7. Synchronisation Confidence 4.7. Synchronisation Quality
Network time protocol services periodically exchange timestamped Network time protocol services periodically exchange timestamped
messages between servers and clients. Assuming RTP sender/receiver messages between servers and clients. Assuming RTP device clocks are
clocks are based on commonly available quartz crystal hardware which based on commonly available quartz crystal hardware which is subject
is subject to drift, tight synchronisation requires frequent exchange to drift, tight synchronisation requires frequent exchange of
of synchronisation messages. synchronisation messages.
Unfortunately, in some implementations, it is not possible to control Unfortunately, in some implementations, it is not possible to control
the frequency of synchronisation messages nor is it possible to the frequency of synchronisation messages nor is it possible to
discover when the last synchronisation message occurred. In order to discover when the last synchronisation message occurred. In order to
provide a measure of confidence that the timestamp clock is provide a measure of synchronization quality, an optional timestamp
sufficiently synchronised, an optional timestamp may be included in may be included in the SDP clock source signalling. In addition, the
the SDP clock source signalling. In addition, the frequency of frequency of synchronisation messages may also be signalled.
synchronisation message may also be signalled.
The optional timestamp and synchronisation frequency parameters The optional timestamp and synchronisation frequency parameters
provide an indication of synchronisation quality to the receiver of provide an indication of synchronisation quality to the receiver of
those parameters. If the synchronisation confidence timestamp is far those parameters. If the synchronisation quality timestamp is far
from the timestamp clock at the receiver of the parameters, it can be from the timestamp clock at the receiver of the parameters, it can be
assumed that synchronisation has not occurred recently or the assumed that synchronisation has not occurred recently, the timestamp
timestamp reference clock source cannot be contacted. In this case, reference clock source cannot be contacted or the SDP information has
the receiver can take action to prevent unsynchronised playout or may not been recently refreshed. To eliminate the latter possiblity,
fall back to assuming that the timestamp clocks are not synchronised. updated SDP information should be retrieved. If the synchronisation
quality timestamp is still far from the timestamp clock the receiver
can take action to prevent unsynchronised playout or may fall back to
assuming that the timestamp clocks are not synchronised.
Synchronisation frequency is expressed as a signed (two's-compliment) Synchronisation frequency is expressed as a signed (two's-compliment)
8-bit field which is the base-2 logarithm of the frequency in Hz. 8-bit field which is the base-2 logarithm of the frequency in Hz.
The synchronisation frequencies represented by this field range from The synchronisation frequencies represented by this field range from
2^-128 Hz to 2^+127 Hz. The field value of 0 corresponds to an 2^-128 Hz to 2^+127 Hz. The field value of 0 corresponds to an
update frequency of 1 Hz. update frequency of 1 Hz.
When multiple reference clocks are specified, a sender or receiver
may wish to base selection of the clock used based on most recent or
most frequent update as indicated by the synchronization quality
signalling.
4.8. SDP Signalling of Timestamp Clock Source 4.8. SDP Signalling of Timestamp 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 clock source signalling included at session-level provides Timestamp 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 default session level signalling.
signalling overrides timestamp clock source signalling at the
enclosing media level and session level.
If timestamp clock source signalling is included anywhere in an SDP If timestamp clock source signalling is included anywhere in an SDP
description, it must be properly defined for all levels in the description, it must be properly defined for all levels in the
description. This may simply be achieved by providing default 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 clock sources MUST NOT be mixed with non- equivalent. Traceable clock sources MUST NOT be mixed with non-
traceable clock sources at any given level. Unless synchronisation traceable clock sources at any given level. Unless synchronisation
confidence information is available for each of the reference clocks quality information is available for each of the reference clocks
listed at a given level, it SHOULD only be included with the first listed at a given level, it SHOULD only be included with the first
reference clock source attribute at that level. reference clock source attribute at that 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 [4] example, as a result of a PTP clock master election. The SIP [4]
protocol supports re-signalling of updated SDP information, however protocol supports re-signalling of updated SDP information, however
other protocols may require additional notification mechanisms. other protocols may require additional notification mechanisms.
Figure 1 shows the ABNF [5] grammar for the SDP reference clock Figure 1 shows the ABNF [5] grammar for the SDP reference clock
source information. source information.
timestamp-refclk = "a=ts-refclk:" clksrc [ SP sync-confidence ] CRLF timestamp-refclk = "a=ts-refclk:" clksrc [ SP sync-quality ] CRLF
clksrc = ntp / ptp / gps / gal / local / private clksrc = ntp / ptp / gps / gal / local / private
ntp = "ntp=" ntp-server-addr ntp = "ntp=" ntp-server-addr
ntp-server-addr = host [ ":" port ] ntp-server-addr = host [ ":" port ]
ntp-server-addr =/ "traceable" ) ntp-server-addr =/ "traceable" )
ptp = "ptp=" ptp-version ":" ptp-gmid [":" ptp-domain] ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002" ptp-version = "IEEE1588-2002"
ptp-version =/ "IEEE1588-2008" ptp-version =/ "IEEE1588-2008"
ptp-version =/ "IEEE802.1AS-2011" ptp-version =/ "IEEE802.1AS-2011"
ptp-server = ptp-gmid [":" ptp-domain] / "traceable"
ptp-gmid = EUI64 ptp-gmid = EUI64
ptp-gmid =/ "traceable"
ptp-domain = ptp-domain-name / ptp-domain-nmbr ptp-domain = ptp-domain-name / ptp-domain-nmbr
ptp-domain-name = "domain-name=" 16ptp-domain-char ptp-domain-name = "domain-name=" 16ptp-domain-char
ptp-domain-char = %x21-7E / %x00 ptp-domain-char = %x21-7E / %x00
; allowed characters: 0x21-0x7E (IEEE 1588-2002) ; allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-nmbr = "domain-nmbr=" %x00-7f ptp-domain-nmbr = "domain-nmbr=" %x00-7f
; allowed number range: 0-127 (IEEE 1588-2008) ; allowed number range: 0-127 (IEEE 1588-2008)
gps = "gps" gps = "gps"
gal = "gal" gal = "gal"
local = "local" local = "local"
private = "private" [ ":" "traceable" ] private = "private" [ ":" "traceable" ]
sync-confidence = sync-timestamp [SP sync-frequency] sync-quality = sync-timestamp [SP sync-frequency]
sync-timestamp = sync-date SP sync-time SP sync-UTCoffset sync-timestamp = sync-date SP sync-time SP sync-UTCoffset
sync-date = 4DIGIT "-" 2DIGIT "-" 2DIGIT sync-date = 4DIGIT "-" 2DIGIT "-" 2DIGIT
; yyyy-mm-dd (e.g., 1982-12-02) ; yyyy-mm-dd (e.g., 1982-12-02)
sync-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT sync-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT
; 00:00:00.000 - 23:59:59.999 ; 00:00:00.000 - 23:59:59.999
sync-UTCoffset = ( "+" / "-" ) 2DIGIT ":" 2DIGIT sync-UTCoffset = ( "+" / "-" ) 2DIGIT ":" 2DIGIT
; +HH:MM or -HH:MM ; +HH:MM or -HH:MM
sync-frequency = 2HEXDIG sync-frequency = 2HEXDIG
; If N is the field value, HZ=2^(N-127) ; If N is the field value, HZ=2^(N-127)
host = hostname / IPv4address / IPv6reference host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ] hostname = *( domainlabel "." ) toplabel [ "." ]
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domainlabel = alphanum domainlabel = alphanum
=/ alphanum *( alphanum / "-" ) alphanum =/ alphanum *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]" IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ] IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG hex4 = 1*4HEXDIG
port = 1*DIGIT port = 1*DIGIT
EUI64 = 7(2HEXDIG "-") 2HEXDIG EUI64 = 7(2HEXDIG "-") 2HEXDIG
skipping to change at page 13, line 18 skipping to change at page 13, line 18
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 intervals
on this timeline. The sender may or may not include an NTP timestamp on this timeline. The sender may or may not include an NTP timestamp
in sender reports to allow mapping of this asynchronous media clock in sender reports to allow mapping of this asynchronous media clock
to a reference 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 media clock source.
Alternatively, asynchronous media clock me be signaled. Alternatively, 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. The this case it is required that a reference clock be specified with an
signalling indicates a media clock offset value at the epoch (time of a=ts-refclk attribute (Section 4.8).
origin) of the reference clock. A rate for the media clock may also
be specified. If include, the rate specification here overrides that
specified or implied by the media description. If omitted, the rate
is assumed to be the exact rate used by the media format. For
example, the media clock for an 8 kHz G.711 audio stream will advance
exactly 8000 units for each second advance in the reference clock
from which it is derived.
A rate modifier may optionally be expressed as the ratio of two The signalling optionally indicates a media clock offset value. The
integers. This provision is useful for accommodating certain offset indicates the RTP timestamp value at the epoch (time of
"oddball rates" associated with NTSC video (see Figure 7). origin) of the reference clock. If no offset is signalled, the
offset can be inferred at the receiver by examining RTCP sender
reports which contain NTP and RTP timestamps which combined define a
mapping.
a=mediaclk:offset=<offset>[ rate=<rate numerator>/<rate A rate modifier may be specified. The modifier is expressed as the
denominator> ] ratio of two integers and modifies the rate specified or implied by
the media description by this ratio. If omitted, the rate is assumed
to be the exact rate specified or implied by the media format. For
example, without a rate specification, the media clock for an 8 kHz
G.711 audio stream will advance exactly 8000 units for each second
advance in the reference clock from which it is derived.
The rate modifier is primarily useful for accommodating certain
"oddball" audio sample rates associated with NTSC video (see
Figure 7). Modified rates are not advised for video streams which
generally use a 90 kHz RTP clock regardless of frame rate or sample
rate used for embedded audio.
a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
denominator>]
5.3. Stream-Referenced Media Clock 5.3. Stream-Referenced Media Clock
The media clock for an outgoing stream may be generated based on the A common synchronisation architecture for audio/visual systems
media clock received with an incoming stream. In this case, the involves distributing a reference media clock from a master device to
signalling identifies the session and the stream source. The a number of slave devices, typically by means of a cable. Examples
received media clock may be converted to a real-time clock which can include audio word clock distribution and video black burst
then be used to generate outgoing media clocks. In this way, the distribution. In this case, the media clock is locally generated,
format of the reference stream does not need to match the format of often by a crystal oscillator and is not locked to a timestamp
the outgoing stream. reference clock.
A reference stream can be either another RTP stream or AVB stream To support this architecture across a network, a master clock
based on the IEEE 1722 standard. An RTP stream is identified by identifier is associated with media sources carrying media clock
destination IP address (for a multicast stream) or source IP address timing information from a master device. The master clock identifier
(for a unicast stream), destination port number and CNAME of the represents a media clock source in the master device. Slave devices
source. in turn associate the master media clock identifer with streams they
transmit, signalling the synchronisation relationship between the
master and slave devices.
a=mediaclk:rtp=<connection address>:<port> <CNAME> Slave devices recover media clock timing from the clock master
stream, using it to synchronise the slave media clock with the
master. Timestamps in the master clock media stream are taken using
the timestamp reference clock shared by the master and slave devices.
The timestamps communicate information about media clock timing
(rate, phase) from the master to the slave devices. Timestamps are
communicated in the usual RTP fashion via RTCP SRs, or via the
RFC6051 [6] header extension. The stream media format may indicate
other clock information, such as the nominal rate.
An IEEE 1722 stream is identified by its StreamID, an EUI-64. Note that slaving of a device media clock to a master device does not
affect the usual RTP lip sync / time alignment algorithms. Time
aligned playout of two or more RTP sources still relies upon NTP
timestamps supplied via RTCP SRs or by the RFC6051 timestamp header
extension.
In a given system, master clock identifiers must be unique. Such
identifiers MAY be manually configured, however 17 octet string
identifiers SHOULD be generated according to the "short-term
persistent RTCP CNAME" algorithm as described in RFC6222 [7].
A reference stream can be an RTP stream or AVB stream based on the
IEEE 1722 [15] standard.
An RTP clock master stream SHOULD be identified at the source level
by an SSRC and master clock identifier. If master clock identifiers
are declared at the media or session level, all RTP sources at or
below the level of declaration MUST provide equivalent timing to a
slave receiver.
a=ssrc:12345 mediaclk:master id=<media-clock-master-id>
An RTP media source indicates that it is slaved to a clock master via
a clock master identifier:
a=mediaclk:slave id=<media-clock-master-id>
An RTP media source indicates that it is slaved to an IEEE 1722 clock
master via a stream identifier (an EUI-64):
a=mediaclk:IEEE1722=<StreamID> a=mediaclk:IEEE1722=<StreamID>
5.4. Signalling Grammar 5.4. Signalling Grammar
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).
skipping to change at page 14, line 44 skipping to change at page 16, line 5
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.
Figure 5 shows the ABNF [5] grammar for the SDP media clock source Figure 5 shows the ABNF [5] grammar for the SDP media clock source
information. information.
timestamp-mediaclk = "a=mediaclk:" mediaclock timestamp-mediaclk = "a=mediaclk:" mediaclock
mediaclock = refclk / rtp / streamid / sender
refclk = "offset=" 1*DIGIT [ SP "rate=" 1*DIGIT "/" 1*DIGIT ]
rtp = "rtp=" nettype SP addrtype SP connection-address SP port SP cname
streamid = "IEEE1722=" EUI64
sender = "sender"
cname = non-ws-string
nettype = token
;typically "IN"
addrtype = token
;typically "IP4" or "IP6"
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A
/ %x5E-7E
token = 1*(token-char)
connection-address = multicast-address / unicast-address
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN / extn-addr
IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT )
IP6-multicast = hexpart [ "/" integer ]
; IPv6 address starting with FF
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
IP4-address = b1 3("." decimal-uchar) mediaclock = refclk / streamid / sender
b1 = decimal-uchar rate = [ SP "rate=" 1*DIGIT "/" 1*DIGIT ]
; less than "224"
; The following is consistent with RFC 2373 [30], Appendix B. refclk = "direct" [ "=" 1*DIGIT ] rate
IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] streamid = "master-id=" clk-master-id
hexseq = hex4 *( ":" hex4) streamid =/ "slave-to=" clk-master-id
hex4 = 1*4HEXDIG streamid =/ "IEEE1722=" EUI64
; Generic for other address families
extn-addr = non-ws-string
non-ws-string = 1*(VCHAR/%x80-FF) clk-master-id = EUI48
;string of visible characters
port = 1*DIGIT sender = "sender"
EUI64 = 7(2HEXDIG "-") 2HEXDIG EUI48 = 5(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.168.1.1 o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 239.0.0.2/255 c=IN IP4 239.0.0.2/255
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:offset=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 1588- kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-
2008 reference clock 2008 reference clock
v=0 v=0
o=- 1311738121 1311738121 IN IP4 192.168.1.1 o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 239.0.0.2/255 c=IN IP4 239.0.0.2/255
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
a=mediaclk:offset=963214424 rate=1000/1001 a=mediaclk:direct=963214424 rate=1000/1001
Figure 7: "Oddball" sample rate directly referenced to IEEE 1588-2008
Figure 7: "Oddball" sample rate directly refernced 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 multicast stream. The stream media clock derived from another RTP stream.
providing the media clock must use the same reference clock as this
stream that references it.
v=0 v=0
o=- 1311738121 1311738121 IN IP4 192.168.1.1 o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 224.2.228.230/32 c=IN IP4 224.2.228.230/32
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:rtp=IN IP4 239.0.0.1 5004 00:60:2b:20:12:if a=mediaclk:slave id=00:60:2b:20:12:1f
Figure 8: Stream media clock derived from another RTP multicast Figure 8: RTP stream with media clock slaved to a master device
stream
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. The stream media clock derived from an IEEE 1722 AVB stream.
providing the media clock must be synchronized with the IEEE 1588-
2008 reference clock used by this stream.
v=0 v=0
o=- 1311738121 1311738121 IN IP4 192.168.1.1 o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 224.2.228.230/32 c=IN IP4 224.2.228.230/32
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: Stream media clock derived from another RTP multicast Figure 9: RTP stream with media clock slaved to an IEEE1722 master
stream device
6. IANA Considerations 6. IANA Considerations
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 Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: ts-refclk Attribute name: ts-refclk
skipping to change at page 19, line 6 skipping to change at page 19, line 26
Purpose: See section 6 of this document Purpose: See section 6 of this document
Reference: This document Reference: This document
Values: see this document and registrations below Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a The attribute has an extensible parameter field and therefore a
registry for these parameters is required. This document creates an registry for these parameters is required. This document creates an
IANA registry called the Media Clock Source Parameters Registry. It IANA registry called the Media Clock Source Parameters Registry. It
contains the three parameters defined in Figure 5: "refclk", "ssrc", contains the three parameters defined in Figure 5: "sender",
"sender". "direct", "master", "slave" and "IEEE1722".
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media [2] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media
Attributes in the Session Description Protocol (SDP)", Attributes in the Session Description Protocol (SDP)",
skipping to change at page 19, line 30 skipping to change at page 19, line 50
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[6] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.
[7] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing
RTP Control Protocol (RTCP) Canonical Names (CNAMEs)",
RFC 6222, April 2011.
7.2. Informative References 7.2. Informative References
[6] Brandenburg, R., Stokking, H., Boronat, F., Montagud, M., and [8] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
K. Gross, "RTCP for inter-destination media synchronization", Montagud, M., and K. Gross, "Inter-destination Media
draft-ietf-avtcore-idms-04 (work in progress), May 2012. Synchronization using the RTP Control Protocol (RTCP)",
draft-ietf-avtcore-idms-07 (work in progress), October 2012.
[7] Global Positioning Systems Directorate, "Navstar GPS Space [9] Global Positioning Systems Directorate, "Navstar GPS Space
Segment/Navigation User Segment Interfaces", September 2011. Segment/Navigation User Segment Interfaces", September 2011.
[8] Institute of Electrical and Electronics Engineers, "1588-2008 - [10] Institute of Electrical and Electronics Engineers, "1588-2008 -
IEEE Standard for a Precision Clock Synchronization Protocol IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", IEEE Std 1588- for Networked Measurement and Control Systems", IEEE Std 1588-
2008, 2008, 2008, 2008,
<http://standards.ieee.org/findstds/standard/1588-2008.html>. <http://standards.ieee.org/findstds/standard/1588-2008.html>.
[9] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time [11] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time
Protocol Version 4: Protocol and Algorithms Specification", Protocol Version 4: Protocol and Algorithms Specification",
RFC 5905, June 2010. RFC 5905, June 2010.
[10] Institute of Electrical and Electronics Engineers, "1588-2002 - [12] Institute of Electrical and Electronics Engineers, "1588-2002 -
IEEE Standard for a Precision Clock Synchronization Protocol IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", IEEE Std 1588- for Networked Measurement and Control Systems", IEEE Std 1588-
2002, 2002, 2002, 2002,
<http://standards.ieee.org/findstds/standard/1588-2002.html>. <http://standards.ieee.org/findstds/standard/1588-2002.html>.
[11] "Timing and Synchronization for Time-Sensitive Applications in [13] "Timing and Synchronization for Time-Sensitive Applications in
Bridged Local Area Networks", Bridged Local Area Networks",
<http://standards.ieee.org/findstds/standard/ <http://standards.ieee.org/findstds/standard/
802.1AS-2011.html>. 802.1AS-2011.html>.
[14] "Audio Video Bridging (AVB) Systems",
<http://standards.ieee.org/findstds/standard/
802.1BA-2011.html>.
[15] "IEEE Standard for Layer 2 Transport Protocol for Time
Sensitive Applications in a Bridged Local Area Network",
<http://standards.ieee.org/findstds/standard/1722-2011.html>.
URIs URIs
[12] <http://en.wikipedia.org/wiki/Genlock> [16] <http://en.wikipedia.org/wiki/Genlock>
[13] <http://en.wikipedia.org/wiki/Word_clock> [17] <http://en.wikipedia.org/wiki/Word_clock>
[14] <http://www.ieee802.org/1/files/public/docs2007/ [18] <http://www.ieee802.org/1/files/public/docs2007/
as-dolsen-time-accuracy-0407.pdf> as-dolsen-time-accuracy-0407.pdf>
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
 End of changes. 85 change blocks. 
199 lines changed or deleted 210 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/