One document matched: draft-williams-avtcore-clksrc-01.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-01"
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="Kevin Gross" initials="K." surname="Gross">
<organization>AVA Networks</organization>
<address>
<postal>
<street></street>
<city>Boulder</city>
<region>CO</region>
<country>US</country>
</postal>
<email>kevin.gross@avanw.com</email>
<uri>http://www.avanw.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>
<code>2612CT</code>
<country>the Netherlands</country>
</postal>
<phone>+31-88-866-7000</phone>
<email>ray.vanbrandenburg@tno.nl</email>
</address>
</author>
<author fullname="Hans Stokking" initials="H.M." surname="Stokking">
<organization>TNO</organization>
<address>
<postal>
<street>Brassersplein 2</street>
<city>Delft</city>
<code>2612CT</code>
<country>the Netherlands</country>
</postal>
<phone></phone>
<email>stokking@tno.nl</email>
</address>
</author>
<date day="5" month="June" 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 an 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 anchor="applications" 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>Examples 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 where two or more
users are watching the same television broadcast at different
devices and/or locations, while communicating with each other using
text, audio and/or video. A skew in the media playout of the two or
more users can have adverse effects on their experience. A
well-known use case here is one friend experiencing a goal in a
football match well before or after other friends.</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 or projector may be individually connected to the
network and receive its portion of the overall image from a
network-connected video server or video scaler. Screens are
refreshed at 50 or 60 hertz or potentially faster. If the refresh is
not synchronized, the effect of multiple screens acting as one is
broken.</t>
<t hangText="Networked 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 used in radar applications, for instance.</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. <xref target="IS-GPS-200F">GPS</xref> is commonly
used to provide a traceable time reference. Some network time
synchronisation protocols (e.g. <xref
target="IEEE1588-2008">PTP</xref>, NTP) 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 taken by reading a local real-time
clock at the sender or receiver. This local clock may be synchronised to
another clock (time source) by some means or it may be unsynchronised. A
variety of methods are available to synchronise local clocks to a
reference time source, including network time protocols (e.g. <xref
target="RFC5905">NTP</xref>) and radio clocks like <xref
target="IS-GPS-200F">GPS</xref>.</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="Clock synchronization">
<t>Two or more local clocks that are sufficiently synchronised will
produce timestamps for a given RTP event can be used as if they cam from the same clock. Providing they are sufficiently synchronised, timestamps produced in one RTP sender/receiver can be directly compared to a local clock in another RTP
sender/receiver. The timestamps produced by synchronized local
clocks in two or more RTP senders/receivers can be directly
compared.</t>
<t>The accuracy of synchronization required is application dependent. See <xref target="applications">Applications</xref> section for a discussion of applications and their corresponding requirements. To serve as a reference clock, clocks must minimally be syntonized (exactly frequency matched) to one another.</t>
<t>Sufficient synchronization can typically be achieving by using a network time protocol (e.g. NTP, 802.1AS,
IEEE 1588-2008) to synchronize all devices to a single master clock.</t>
<t>Another apporach is to use clocks providing a global time reference (e.g. GPS, Gallileo).
This concept may be used in conjunction with network time protocols as some protocols (e.g. PTP, NTP) allow master clocks to
indicate explicitly 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 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).</t>
<t>Two or more NTP servers may be listed at the same level in the
session description 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 different
server.</t>
</section>
<section title="Identifying PTP Reference Clocks">
<t>The IEEE 1588 Precision Time Protocol (PTP) family of clock
synchronisation protocols provides a shared reference clock in an
network - typically a LAN. IEEE 1588 provides sub-microsecond
synchronisation between devices on a LAN and typically locks within
seconds at startup. With support from Ethernet switches, IEEE 1588
protocols can achieve nanosecond timing accuracy in LANs. Network
interface chips and cards supporting hardware time-stamping of timing
critical protocol messages are also available.</t>
<t>Three flavours of IEEE 1588 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 also known
as 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 also
known as IEEE1588v2 or PTPv2. IEEE 1588-2008 is not protocol compatible
with IEEE 1588-2002.</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 IEEE 1588 clock is identified by a globally unique EUI-64
called a "ClockIdentity". A slave clock using one of the IEEE 1588
family of network time protocols acquires the ClockIdentity/EUI-64 of
the grandmaster clock that is the ultimate source of timing
information for the network. A master clock which is itself slaved to another master
clock passes the grandmaster ClockIdentity through to its slaves.</t>
<t>Several instances of the IEEE 1588 protocol may operate
independently on a single network, forming distinct PTP network
protocol domains, each of which may have a different grandmaster clock. As
the IEEE 1588 standards have developed, the definition of PTP domains
has changed. IEEE 1588-2002 identifies protocol subdomains by a
textual name, but IEEE 1588-2008 identifies protocol domains using a
numeric domain number. 802.1AS is a Layer-2 profile of IEEE 1588-2008
supporting a single numeric clock domain (0).</t>
<t>When PTP subdomains are signalled via SDP, senders and receivers
SHOULD check that both grandmaster ClockIdentity and PTP subdomain
match when determining clock equivalence.</t>
<t>The PTP protocols employ a distributed election protocol called the
"Best Master Clock Algorithm" (BMCA) to determine the active clock
master. The clock master choices available to BMCA can be restricted
or favourably biased by setting stratum values, preferred 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>
</section>
<section title="Identifying Global Reference Clocks">
<t>Global reference clocks provide a source of traceable time,
typically via a hardware radio receiver interface. Examples include
GPS and Galileo. 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 clocks to a shared 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 timestamp
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.
Providing adjustments are made for differing time bases, timestamps
taken using clocks synchronised to a traceable time source can be
directly compared even if the clocks are synchronised to different
sources or via different mechanisms.</t>
<t>Since all NTP and PTP servers providing traceable time can be
directly compared, it is not necessary to identify traceable time
servers by protocol address or other identifiers.</t>
</section>
<section title="Synchronisation Confidence">
<t>Network time protocol services periodically exchange timestamped
messages between servers and clients. Assuming RTP sender/receiver
clocks are based on commonly available quartz crystal hardware which is subject to drif, 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 occurred. 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 be signalled.</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 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 a signed (two's-compliment) 8-bit
field which is the base-2 logarithm of the frequency
in Hz. The synchronisation frequencies represented by this field range
from 2^-128 Hz to 2^+127 Hz. The field value of 0 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 be at any
or all levels (session, media or source) 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
non-traceable clock sources at any given level. 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 <xref
target="RFC3261">SIP</xref> protocol supports re-signalling of updated
SDP information, however other protocols may require additional
notification mechanisms.</t>
<t><xref target="abnf-ts-refclk"></xref> shows the <xref
target="RFC2234">ABNF</xref> grammar for the SDP reference clock source
information.</t>
<figure align="center" anchor="abnf-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-domain]
ptp-version = "IEEE1588-2002"
ptp-version =/ "IEEE1588-2008"
ptp-version =/ "IEEE802.1AS-2011"
ptp-gmid = EUI64
ptp-gmid =/ "traceable"
ptp-domain = ptp-domain-name / ptp-domain-nmbr
ptp-domain-name = "domain-name=" 16ptp-domain-char
ptp-domain-char = %x21-7E / %x00
; allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-nmbr = "domain-nmbr=" %x00-7f
; allowed number range: 0-127 (IEEE 1588-2008)
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(2HEXDIG "-") 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 definition 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="Media Clock Source Signalling">
<t>The media clock source for a stream determines the timebase used to
advance the RTP timestamps included in RTP packets. The media clock
may be asynchronously generated by the sender, it may be generated in
fixed relationship to the reference clock or it may be generated with
respect to another stream on the network (which is presumably being
received by the sender).</t>
<section title="Asynchronously Generated Media Clock">
<t>In the simplest sender implementation, the sender generates media
by sampling audio or video according to a free-running local clock. The RTP
timestamps in media packets are advanced according to this media clock
and packet transmission is typically timed to regular intervals on
this timeline. The sender may or may not include an NTP timestamp in
sender reports to allow mapping of this asynchronous media clock to a
reference clock.</t>
<t>The asynchronously generated media clock is the assumed mode of
operation when there is no signalling of media clock source.
Alternatively, asynchronous media clock me be signaled.
<list><t>a=mediaclk:sender</t></list></t>
</section>
<section title="Direct-Referenced Media Clock">
<t>A media clock may be directly derived from a reference clock. For this
case it is required that a reference clock be specified. The
signalling indicates a media clock offset value at the epoch (time of
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.</t>
<t>The rate may optionally be expressed as the ratio of two integers. This provision is useful for accomodating certain "oddball rates" associated with NTSC video.
<list><t>a=mediaclk:offset=<offset>[ rate=<rate numerator>[/<rate denominator>]]</t></list></t>
</section>
<section title="Stream-Referenced Media Clock">
<t>The media clock for an outgoing stream may be generated based on
the media clock received with an incoming stream. In this case, the
signalling identifies the session and the stream source. The received
media clock is converted to a real-time clock which is used to
generate outgoing media clocks. In this way, the format of the
reference stream does not need to match the format of the outgoing
stream.</t>
<t>A reference stream can be either another RTP stream or AVB stream based on the IEEE 1722 standard. An RTP stream is identified by destination IP address (for a multicast stream) or source IP address (for a unicast stream), destination port number and CNAME of the source.
<list><t>a=mediaclk:rtp=<connection address>:<port> <CNAME></t></list></t>
<t>An IEEE 1722 stream is identified by its StreamID, an EUI-64.
<list><t>a=mediaclk:IEEE1722=<StreamID></t></list></t>
</section>
<section title="Signalling Grammar">
<t>Specification of the media clock source may be at any or all levels
(session, media or source) of an SDP description (see level
definitions (Section 3) earlier in this document for more
information).</t>
<t>Media clock source signalling included at session level provides
default parameters for all RTP sessions and sources in the session
description. More specific signalling included at the media level
overrides default session level signalling. Further, source-level
signalling overrides media clock source signalling at the enclosing
media level and session level.</t>
<t>Media clock source signalling may be present or absent on a
per-stream basis. In the absence of media clock source signals,
receivers assume an asynchronous media clock generated by the
sender.</t>
<t>Media clock source parameters may be repeated at a given level
(i.e. for a session or source) to provide information about additional
clock sources. If the attribute is repeated at a given level, all
clocks described at that level are comparable clock sources and may be used interchangeably.</t>
<t><xref target="abnf-mediaclk"></xref> shows the <xref
target="RFC2234">ABNF</xref> grammar for the SDP media clock source
information.</t>
<figure align="center" anchor="abnf-mediaclk"
title="Media Clock Source Signalling">
<artwork><![CDATA[
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=" EUI-64
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)
b1 = decimal-uchar
; less than "224"
; The following is consistent with RFC 2373 [30], Appendix B.
IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
; Generic for other address families
extn-addr = non-ws-string
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
port = 1*DIGIT
EUI-64 = 7(2HEXDIG "-") 2HEXDIG]]></artwork>
</figure>
</section>
<section title="Examples">
<t><xref target="example-mediaclk-1"></xref> shows an example SDP
description 8 channels of 24-bit, 48 kHz audio transmitted as a multicast stream. Media clock is derived directly from an IEEE 1588-2008 reference.</t>
<figure align="center" anchor="example-mediaclk-1"
title="Media clock directly referenced to IEEE 1588-2008">
<artwork><![CDATA[
v=0
o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 239.0.0.2/255
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24 L24/48000/8
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:offset=963214424
]]></artwork>
</figure>
<t><xref target="example-mediaclk-2"></xref> shows an example SDP
description 2 channels of 24-bit, 44056 kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-2008 reference clock</t>
<figure align="center" anchor="example-mediaclk-2"
title=""Oddball" sample rate directly refernced to IEEE 1588-2008">
<artwork><![CDATA[
v=0
o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 239.0.0.2/255
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24 L24/44056/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:offset=963214424 rate=44100000/1001
]]></artwork>
</figure>
<t><xref target="example-mediaclk-3"></xref> shows the same 48 kHz audio transmission from <xref target="example-mediaclk-1"></xref> with media clock derived from another RTP multicast stream. The stream providing the media clock must use the same reference clock as this stream that references it.</t>
<figure align="center" anchor="example-mediaclk-3"
title="Stream media clock derived from another RTP multicast stream">
<artwork><![CDATA[
v=0
o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 224.2.228.230/32
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24 L24/48000/2
a=sendonly
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
]]></artwork>
</figure>
<t><xref target="example-mediaclk-4"></xref> shows the same 48 kHz audio transmission from <xref target="example-mediaclk-1"></xref> with media clock derived from an IEEE 1722 AVB stream. The stream providing the media clock must be synchronized with the IEEE 1588-2008 reference clock used by this stream.</t>
<figure align="center" anchor="example-mediaclk-4"
title="Stream media clock derived from another RTP multicast stream">
<artwork><![CDATA[
v=0
o=- 1311738121 1311738121 IN IP4 192.168.1.1
c=IN IP4 224.2.228.230/32
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
]]></artwork>
</figure>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The SDP attribute "ts-refclk" 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 section 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="abnf-ts-refclk"></xref>: "ntp", "ptp", "gps", "gal", "local",
"private".</postamble>
</figure>
<t>The SDP attribute "mediaclk" 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: mediaclk
Long form: Media clock source
Type of name: att-field
Type of attribute: session abd media level
Subject to charset: no
Purpose: See section 6 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 Media Clock Source Parameters
Registry. It contains the three parameters defined in <xref
target="abnf-mediaclk"></xref>: "refclk", "ssrc",
"sender".</postamble>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2234"?>
<?rfc include="reference.RFC.3261"?>
<?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>
<reference anchor="IS-GPS-200F">
<front>
<title>Navstar GPS Space Segment/Navigation User Segment
Interfaces</title>
<author>
<organization>Global Positioning Systems
Directorate</organization>
</author>
<date day="21" month="September" year="2011" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:14 |