One document matched: draft-williams-avtcore-clksrc-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-williams-avtcore-clksrc-00"
ipr="trust200902">
<front>
<title abbrev="RTP Clock Source Signalling">RTP Clock Source
Signalling</title>
<author fullname="Aidan Williams" initials="A.M." surname="Williams">
<organization>Audinate</organization>
<address>
<postal>
<street>Level 1, 458 Wattle St</street>
<city>Ultimo</city>
<code>2007</code>
<region>NSW</region>
<country>Australia</country>
</postal>
<phone>+61 2 8090 1000</phone>
<facsimile>+61 2 8090 1001</facsimile>
<email>aidan.williams@audinate.com</email>
<uri>http://www.audinate.com/</uri>
</address>
</author>
<author fullname="Ray van Brandenburg" initials="R."
surname="van Brandenburg">
<organization>TNO</organization>
<address>
<postal>
<street>Brassersplein 2</street>
<city>Delft</city>
<region></region>
<code></code>
<country>The Netherlands</country>
</postal>
<phone>+31 88 86 63609</phone>
<facsimile></facsimile>
<email>ray.vanbrandenburg@tno.nl</email>
<uri></uri>
</address>
</author>
<author fullname="Kevin Gross" initials="K." surname="Gross">
<organization>AVA Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="28" month="February" year="2012" />
<area>Real-time Applications and Infrastructure</area>
<workgroup>Audio/Video Transport Core Maintenance</workgroup>
<keyword>Clock</keyword>
<keyword>Source</keyword>
<abstract>
<t>NTP timestamps are used by several RTP protocols for synchronisation
and statistical measurement. This memo specificies SDP signalling
identifying NTP timestamp clock sources and SDP signalling identifying
the media clock sources in a multimedia session.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>RTP protocols use NTP format timestamps to facilitate media stream
synchronisation and for providing estimates of round trip time (RTT) and
other statistical parameters.</t>
<t>Information about media clock timing exchanged in NTP format
timestamps may come from a clock which is synchronised to a global time
reference, but this cannot be assumed nor is there a standardised
mechanism available to indicate that timestamps are derived from a
common reference clock. Therefore, RTP implementations typically assume
that NTP timestamps are taken using unsynchronised clocks and must
compensate for absolute time differences and rate differences. Without a
shared reference clock, RTP can time align flows from the same source at
a given receiver using relative timing, however tight synchronisation
between two or more different receivers (possibly with different network
paths) or between two or more senders is not possible.</t>
<t>High performance AV systems often use a reference media clock
distributed to all devices in the system. The reference media clock is
often distinct from the the reference clock used to provide timestamps.
A reference media clock may be provided along with a audio or video
signal interface, or via a dedicated clock signal (e.g. <eref
target="http://en.wikipedia.org/wiki/Genlock">genlock</eref> or <eref
target="http://en.wikipedia.org/wiki/Word_clock">audio word
clock</eref>. If sending and receiving media clocks are known to be
synchronised to a common reference clock, performance can improved by
minimising buffering and avoiding rate conversion.</t>
<t>This specification defines SDP signalling of timestamp clock sources
and media reference clock sources.</t>
</section>
<section title="Applications">
<t>Timestamp clock source and reference media clock signalling benefit
applications requiring synchronised media capture or playout and low
latency operation.</t>
<t>Exmaples include, but are not limited to:</t>
<t><list style="hanging">
<t hangText="Social TV"><xref target="I-D.ietf-avtcore-idms">RTCP
for inter-destination media synchronization</xref> defines social TV
as the combination of media content consumption by two or more users
at different devices and locations and real-time communication
between those users. An example of Social TV, is when two or more
users are watching the same television broadcast at different
devices and locations, while communicating with each other using
text, audio and/or video. A skew in the media play-out of the two or
more users can have adverse effects on their experience. A
well-known use case here is one friend experiencing a goal in a
football match well before or after other friend(s).</t>
<t hangText="Video Walls">A video wall consists of multiple computer
monitors, video projectors, or television sets tiled together
contiguously or overlapped in order to form one large screen. Each
of the screens reproduces a portion of the larger picture. In some
implementations, each screen may be individually connected to the
network and receive its portion of the overall image from a
network-connected video server or video scaler. Screens are
refreshed at 60 hertz (every 16-2/3 milliseconds) or potentially
faster. If the refresh is not synchronized, the effect of multiple
screens acting as one is broken.</t>
<t hangText="Netwoked Audio">Networked loudspeakers, amplifiers and
analogue I/O devices transmitting or receiving audio signals via RTP
can be connected to various parts of a building or campus network.
Such situations can for example be found in large conference rooms,
legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in audio
delay, this use case needs even more accuracy than the video wall
use case. Depending on the exact application, the need for accuracy
can then be <eref
target="http://www.ieee802.org/1/files/public/docs2007/as-dolsen-time-accuracy-0407.pdf">in
the range of microseconds</eref>.</t>
<t hangText="Sensor Arrays">Sensor arrays contain many synchronised
measurement elements producing signals which are then combined to
form an overall measurement. Accurate capture of the phase
relationships between the various signals arriving at each element
of the array is critically important for proper operation. Examples
include towed or fixed sonar arrays, seismic arrays and phased
arrays.</t>
</list></t>
</section>
<section anchor="definitions" title="Definitions">
<t>The definitions of streams, sources and levels of information in SDP
descriptions follow the definitions found in <xref
target="RFC5576">Source-Specific Media Attributes in the Session
Description Protocol (SDP)</xref>.<list style="hanging">
<t hangText="multimedia session">A set of multimedia senders and
receivers as well as the data streams flowing from senders to
receivers. The <xref target="RFC4566">Session Description Protocol
(SDP)</xref> describes multimedia sessions.</t>
<t hangText="media stream">An RTP session potentially containing
more than one RTP source. SDP media descriptions beginning with an
"m"-line define the parameters of a media stream.</t>
<t hangText="media source">A media source is single stream of RTP
packets, identified by an RTP SSRC.</t>
<t hangText="session-level">Session-level information applies to an
entire multimedia session. In an SDP description, session-level
information appears before the first "m"-line.</t>
<t hangText="media-level">Media-level information applies to a
single media stream (RTP session). In an SDP description,
media-level information appears after each "m"-line.</t>
<t hangText="source-level">Source-level information applies to a
single stream of RTP packets, identified by an RTP SSRC <xref
target="RFC5576">Source-Specific Media Attributes in the Session
Description Protocol (SDP)</xref> defines how source-level
information is included into an SDP session description.</t>
<t hangText="traceable time">A clock is considered to provide
traceable time if it can be proven to be synchronised to a global
time reference. GPS XXX is commonly used to provide a traceable time
reference. Some network time synchronisation protocols (e.g. XXX
PTP) can explicitly indicate that the master clock is providing a
traceable time reference over the network.</t>
</list></t>
</section>
<section title="Timestamp Reference Clock Source Signalling">
<t>The NTP timestamps used by RTP are taking by reading a local clock at
the sender or receiver. This local clock may be synchronised to another
clock (time source) by some means or it may be unsynchronised. A variety
of methods are available to synchronise local clocks to a reference time
source, including network time protocols (e.g. <xref
target="RFC5905">NTP</xref>) and radio clocks like GPS [XXX].</t>
<t>The following sections describe and define SDP signalling indicating
whether and how the local timestamping clock in an RTP sender/receiver
is synchronised to a reference clock.</t>
<section title="Equivalent Timestamp Clocks">
<t>Two or more local clocks that are sufficiently synchronised will
produce timestamps for a given event which are effectively identical
for the purposes of RTP. A local clock in one RTP sender/receiver can
be considered equivalent to a local clock in another RTP
sender/receiver providing they are sufficiently synchronised such that
timestamps produced by one clock are indistinguishable from timestamps
produced by the other. The timestamps produced by equivalent local
clocks in two or more RTP senders/receivers receivers can be directly
compared.</t>
<t>One or more local clocks are equivalent if they are synchronised to
a single master clock via a network time protocol (e.g. XXX NTP,
802.1AS, IEEE1588v2).</t>
<t>One or more local clocks are equivalent if they are synchronised to
any member of a set of master clocks provided that the set of master
clocks are synchronised.</t>
<t>One or more local clocks are equivalent if they are synchronised to
a clock master providing a global time reference (e.g. XXX GPS,
Gallileo). Some network time protocols (e.g. XXX PTP) may allow master
clocks to explicitly indicate that they are "traceable" back to a
global time reference.</t>
</section>
<section title="Identifying NTP Reference Clocks">
<t>A single NTP server is identified by identified by hostname (or IP
address) and an optional port number. If the port number is not
indicated, it is assumed to be the standard NTP port (123) XXX.</t>
<t>Two or more NTP servers may be listed to indicate that they are
interchangeable. RTP senders/receivers can use any of the listed NTP
servers to govern a local clock that is equivalent to a local clock
slaved to a difference server.</t>
<t>XXX Question: Does NTP carry traceability information? Or is this
implicit somehow in the stratum? Apparently there are some bits in the
leap seconds functionality which talk about "tracking"..</t>
</section>
<section title="Identifying PTP Reference Clocks">
<t>The IEEE1588 Precision Time Protocol (PTP) family of clock
synchronisation protocols provide a shared reference clock in an
network - typically a LAN. IEEE1588 provides sub-microsecond
synchronisation between devices on a LAN and typically locks within
seconds at startup. With support from Ethernet switches, IEEE1588
protocols can achieve nanosecond timing accuracy in LANs. Network
interface chips and cards supporting hardware time-stamping of timing
critical protocol messages are also available.</t>
<t>When using IEEE1588 clock synchronisation, networked AV systems can
achieve sub 1 microsecond time alignment accuracy when rendering AV
signals and can support latencies less than 1ms through a gigabit
LAN.</t>
<t>Three flavours of IEEE1588 are in use today:<list style="symbols">
<t><xref target="IEEE1588-2002">IEEE 1588-2002</xref>: the
original "Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems". This is often
called IEEE1588v1 or PTPv1.</t>
<t><xref target="IEEE1588-2008">IEEE 1588-2008</xref>: the second
version of the "Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems". This is a
revised version of the original IEEE1588-2002 standard and is
often called IEEE1588v2 or PTPv2.</t>
<t><xref target="IEEE802.1AS-2011">IEEE 802.1AS</xref>: "Timing
and Synchronization for Time Sensitive Applications in Bridged
Local Area Networks". This is a Layer-2 only profile of IEEE
1588-2008 for use in Audio/Video Bridged LANs.</t>
</list></t>
<t>Each IEEE1588 clock is identified by a globally unique EUI-64
called a "ClockIdentity". A slave clock using one of the IEEE1588
family of network time protocols acquires the ClockIdentity/EUI-64 of
the grandmaster clock that is the ultimate source of timing
information. A master clock which is itself slaved to another master
clock passes the grand master clock identity through to its
slaves.</t>
<t>Several instances of the IEEE1588v1/v2 protocol may operate
independently on a single network, forming distinct PTP network
protocol domains each of which may have a different master clock. As
the IEEE1588 standards have developed, the definition of PTP domains
has changed. IEEE1588v1 identifies protocol subdomains by a textual
name and IEEE1588v2 identifies protocol domains using a numeric domain
number. 802.1AS is a Layer2 profile of IEEE1588v2 supporting a single
numeric clock domain (0). This specification assumes that an IEEE1588
clock master for multiple domains will provide the same timing
information to all domains or that each clock domain has a different
master. In other words, this specification assumes that a timing
domain can be uniquely identified using the ClockIdentity of the
grandmaster clock alone.</t>
<t>The PTP family of protocols employ a distributed election protocol
called the "Best Master Clock Algorithm (BMCA) to determine the active
clock master. The clock master choices available to BMCA can be
restricted or favourably biased by setting stratum values, preffered
master clock bits, or other parameters to influence the election
process. In some systems it may be desirable to limit the number of
possible PTP clock masters to avoid re-signalling timestamp clock
sources when the clock master changes.</t>
<!--### what about transition from master->backup master clock?
Is the backup master identify known by all devices in the network?
If so, signalling can provide both the primary and backup master gmIds
### New clock gmID can be re-signalled without tearing down the stream if using SIP.
If not capable of re-signalling, should specify all possible gmIDs.
Might want to make use of the preferred master mechanism,
or stratum to limit the number of candidate master clocks.
### Can phase continuity during master->backup master be relied upon?
What about with 802.1AS? Recall some discussion that time would be
allowed to step.. hence the "uncertain" stuff.
### See Kevin's comments. Use multiple gmIds, just like multiple IP addresses are used for NTP servers.
Discovering them would not be part of this specification.
There are manual configuration methods which can also be used - preferred master, stratum, etc
to limit the potential gms to a smaller list.
### General issue about re-signalling.
Change of clock master for a sender could happily be re-signalled.
If the media packets had the "timestamp uncertain" bit set,
then the receiver would know not to update NTP->rtp timestamp
information from the incoming timestamps until clocks had settled
and resignalling had occurred.
-->
</section>
<section title="Identifying Global Reference Clocks">
<t>Global reference clocks provide a source of tracable time,
typically via a hardware radio receiver interface. Examples include
GPS and Gallileo. Apart from the name of the reference clock system,
no further identification is required.</t>
</section>
<section title="Other Reference Clocks">
<t>At the time of writing, it is common for RTP senders/receivers not
to synchronise their local timestamp clock to a master. An
unsynchronised clock such as a quartz oscillator is identified as a
"local" reference clock.</t>
<t>In some systems, all RTP senders/receivers may use a timetsamp
clock synchronised to a reference clock that is not provided by one of
the methods listed above. Examples may include the reference time
information provided by digital television or cellular services. These
sources are identified as "private" reference clocks. All RTP
senders/receivers in a session using a private reference clock are
assumed to have a mechanism outside this specification confirming that
their local timestamp clocks are equivalent.</t>
</section>
<section title="Traceable Reference Clocks">
<t>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 XXX.
Providing adjustments are made for differing time bases, timestamps
taken using a clocks synchronised to a traceable time source can be
directly compared even if the clocks are synchronised to different
servers or via different mechanisms. Any traceable timestamp clock
source can be considered equivalent to another traceable timestamp
clock source and the timestamps may be directly compared.</t>
<t>Since any NTP or PTP server providing traceable time can be
considered equivalent, it is not necessary to identify traceable time
servers by protocol address.</t>
</section>
<section title="Synchronisation Confidence">
<t>Network time protocols periodically exchange timestamped messages
between servers and clients. Assuming RTP sender/receiver clocks are
based on commonly available quartz crystal hardware, tight
synchronisation requires frequent exchange of synchronisation
messages.</t>
<t>Unfortunately, in some implementations, it is not possible to
control the frequency of synchronisation messages nor is it possible
to discover when the last sychronisation message occured. In order to
provide a measure of confidence that the timestamp clock is
sufficiently synchronised, an optional timestamp may be included in
the SDP clock source signalling. In addition, the frequency of
synchronisation message may also optionally be provided.</t>
<t>The optional timestamp and synchronisation frequency parameters
provide an indication of synchronisation quality to the receiver of
those parameters. If the synchronisation confidence timestamp is far
from the timestamp clock at the receiver of the parameters, it can be
assumed that synchronisation has not occured recently or the timestamp
reference clock source is wrongly configured or cannot be contacted.
In this case, the receiver can take action to prevent unsynchronised
playout or may fall back to assuming that the timestamp clocks are not
synchronised.</t>
<t>Synchronisation frequency is expressed as an <eref
target="http://en.wikipedia.org/wiki/Signed_number_representations#Excess-K">8-bit
excess-127 field</eref> which is the base 2 logarithm of the frequency
in HZ. The synchronisation frequencies represented by this field range
from 2^-127 Hz to 2^+128 Hz. The field value of 127 corresponds to an
update frequency of 1 Hz.</t>
</section>
<section title="SDP Signalling of Timestamp Clock Source">
<t>Specification of the timestamp reference clock source may at all
levels of an SDP description (see <xref target="definitions">level
definitions</xref> earlier in this document for more information).</t>
<t>Timestamp clock source signalling included at session-level
provides default parameters for all RTP sessions and sources in the
session description. More specific signalling included at the
media-level overrides default session-level signalling. Further,
source-level signalling overrides timestamp clock source signalling at
the enclosing media-level and session-level.</t>
<t>If timestamp clock source signalling is included anywhere in an SDP
description, it must be properly defined for all levels in the
description. This may simply be achieved by providing default
signalling at the session level.</t>
<t>Timestamp reference clock parameters may be repeated at a given
level (i.e. for a session or source) to provide information about
additional servers or clock sources. If the attribute is repeated at a
given level, all clocks described at that level are assumed to be
equivalent. Traceable clock sources MUST NOT be mixed with clock
sources having explicit addresses for a given source or session.
Unless synchronisation confidence information is available for each of
the reference clocks listed at a given level, it SHOULD only be
included with the first reference clock source attribute at that
level.</t>
<t>Note that clock source parameters may change from time to time, for
example, as a result of a PTP clock master election. The SIP XXX
protocol supports re-signalling of updated SDP information, however
other protocols may require additional notification mechanisms.</t>
<figure align="center" anchor="ebnf-ts-refclk"
title="Timestamp Reference Clock Source Signalling">
<artwork><![CDATA[
timestamp-refclk = "a=ts-refclk:" clksrc SP [sync-confidence] CRLF
clksrc = ntp / ptp / gps / gal / local / private
ntp = "ntp=" ntp-server-addr
ntp-server-addr = host [ ":" port ]
ntp-server-addr =/ "traceable" )
ptp = "ptp=" ptp-version ":" ptp-gmid
ptp-version = "IEEE1588-2002"
ptp-version =/ "IEEE1588-2008"
ptp-version =/ "IEEE802.1AS-2011"
ptp-gmid = EUI64
ptp-gmid =/ "traceable"
gps = "gps"
gal = "gal"
local = "local"
private = "private" [ ":" "traceable" ]
sync-confidence = sync-timestamp [SP sync-frequency]
sync-timestamp = sync-date SP sync-time SP sync-UTCoffset
sync-date = 4DIGIT "-" 2DIGIT "-" 2DIGIT
; yyyy-mm-dd (e.g., 1982-12-02)
sync-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT
; 00:00:00.000 - 23:59:59.999
sync-UTCoffset = ( "+" / "-" ) 2DIGIT ":" 2DIGIT
; +HH:MM or -HH:MM
sync-frequency = 2HEXDIG
; If N is the field value, HZ=2^(N-127)
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domainlabel = alphanum
=/ alphanum *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
EUI-64 = 7(HEXDIG "-") 2HEXDIG
]]></artwork>
</figure>
<section title="Examples">
<t><xref target="example-session-level"></xref> shows an example SDP
description with a timestamp reference clock source defined at the
session-level.</t>
<figure align="center" anchor="example-session-level"
title="Timestamp reference clock defintion at the session level">
<artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
a=ts-refclk:ntp=traceable
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
]]></artwork>
</figure>
<t></t>
<t><xref target="example-media-level"></xref> shows an example SDP
description with timestamp reference clock definitions at the
media-level overriding the session-level defaults. Note that the
synchronisation confidence timestamp appears on the first attribute
at the media-level only.</t>
<figure align="center" anchor="example-media-level"
title="Timestamp reference clock definition at the media-level">
<artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00
a=ts-refclk:ntp=198.51.100.22
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
]]></artwork>
</figure>
<t></t>
<t><xref target="example-source-level"></xref> shows an example SDP
description with a timestamp reference clock definition at the
source-level overriding the session-level default.</t>
<figure align="center" anchor="example-source-level"
title="Timestamp reference clock signalling at the source level">
<artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
a=ts-refclk:local
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Timescales, UTC TAI and leap seconds">
<t>RTP implementation is simplified by using a clock reference with a
timescale which does not include leap seconds. IEEE 1588, GPS and other
TAI (Inernational Atomic Time) references do not include leap seconds.
NTP time, operating system clocks and other UTC (Coordinated Universal
Time) references include leap seconds (though the ITU is studying a
proposal which could eventually eliminate leap seconds from UTC).</t>
<t>Leap seconds are potentially scheduled at the end of the last day of
December and June each year. NTP inserts a leap second at the beginning
of the last second of the day. This results in the clock freezing for
one second immediately prior to the last second of the affected day.
Most system clocks insert the leap second at the end of the last second.
This results in repetition of the last second of the day. Generating or
using timestamps during the entire last second of a day on which a leap
second has been scheduled should therefore be avoided. Note that the
period to be avoided has a real-time duration of two seconds.</t>
<t>It is also important that all participants correctly implement leap
seconds and have a working communications channel to receive
notification of leap second scheduling. Without prior knowledge of leap
second schedule, NTP servers and clients may be offset by exactly one
second with respect to their UTC reference. This potential discrepancy
begins when a leap second occurs and ends when all participants receive
a time update from a server or peer (which, depending on the operating
system and/or implementation, could be anywhere from a few minutes to a
week). Such a long-lived discrepancy can be particularly disruptive to
RTP operation.</t>
<t>Apart from the long-lived discrepancy due to dependence on both
timing (e.g. NTP) updates and leap seconds scheduling updates, there is
also the potential for a short-lived timing discontinuity having an
effect on RTP playout timing (even though leap seconds are quite
rare).</t>
<t>If a timescale with leap seconds is used for RTP:</t>
<t><list style="symbols">
<t>RTP Senders using a leap-second-bearing reference must not
generate sender reports (SR) containing an originating NTP timestamp
in the vicinity of a leap second. Receivers should ignore timestamps
in any such reports inadvertently generated.</t>
<t>Receivers working to a leap-second-bearing reference must be
careful to take leap seconds into account if a leap second occurs
between the time a RTP packet is originated and when it is to be
presented.</t>
</list></t>
</section>
<section title="Media Clock Source Signalling">
<t>A timestamp clock source (ie media clock is locked to a reference
clock like NTP, GPS, etc) Reference clock source..</t>
<t>An RTP session.. This should be an SSRC within an RTP session.
Include IP address and port.</t>
<t>An IEEE 1722 stream, identified by a Stream ID.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The SDP attribute "ts-clksrc" defined by this document is registered
with the IANA registry of SDP Parameters as follows:</t>
<figure>
<artwork><![CDATA[
SDP Attribute ("att-field"):
Attribute name: ts-refclk
Long form: Timestamp reference clock source
Type of name: att-field
Type of attribute: session, media and source level
Subject to charset: no
Purpose: See sections 1-4 of this document
Reference: This document
Values: see this document and registrations below
]]></artwork>
<postamble>The attribute has an extensible parameter field and
therefore a registry for these parameters is required. This document
creates an IANA registry called the Timestamp Reference Clock Source
Parameters Registry. It contains the six parameters defined in <xref
target="ebnf-ts-refclk"></xref>: "ntp", "ptp", "gps", "gal", "local",
"private".</postamble>
</figure>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5576"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5905"?>
<?rfc include="reference.I-D.ietf-avtcore-idms"?>
<reference anchor="IEEE1588-2002"
target="http://standards.ieee.org/findstds/standard/1588-2002.html">
<front>
<title>1588-2002 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date year="2002" />
</front>
<seriesInfo name="" value="IEEE Std 1588-2002" />
</reference>
<reference anchor="IEEE1588-2008"
target="http://standards.ieee.org/findstds/standard/1588-2008.html">
<front>
<title>1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date year="2008" />
</front>
<seriesInfo name="" value="IEEE Std 1588-2008" />
</reference>
<reference anchor="IEEE802.1AS-2011"
target="http://standards.ieee.org/findstds/standard/802.1AS-2011.html">
<front>
<title>Timing and Synchronization for Time-Sensitive Applications in
Bridged Local Area Networks</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
<section title="An Appendix">
<t></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:31 |