Audio/Video Transport Core Maintenance A. Williams
Internet-Draft Audinate
Intended status: Standards Track K. Gross
Expires: August 23, 2013 AVA Networks
R. van Brandenburg
H. Stokking
TNO
February 19, 2013
RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-02
Abstract
NTP timestamps are used by several RTP protocols for synchronisation
and statistical measurements. This memo specifies SDP signalling
identifying NTP timestamp clock sources and SDP signalling
identifying the media clock sources in a multimedia session.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Williams, et al. Expires August 23, 2013 [Page 1]
Internet-Draft RTP Clock Source Signalling February 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5
4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 5
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 6
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 6
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 7
4.5. Other Reference Clocks . . . . . . . . . . . . . . . . . . 8
4.6. Traceable Reference Clocks . . . . . . . . . . . . . . . . 8
4.7. SDP Signalling of Timestamp Clock Source . . . . . . . . . 8
4.7.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 12
5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 12
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 13
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 14
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Signalling considerations . . . . . . . . . . . . . . . . . . 17
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Williams, et al. Expires August 23, 2013 [Page 2]
Internet-Draft RTP Clock Source Signalling February 2013
1. Introduction
RTP protocols use NTP format timestamps to facilitate multimedia
session synchronisation and for providing estimates of round trip
time (RTT) and other statistical parameters.
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.
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 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. genlock [19] or audio word clock [20]). 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.
This specification defines SDP signalling of timestamp clock sources
and media reference clock sources.
2. Applications
Timestamp clock source and reference media clock signalling benefit
applications requiring synchronised media capture or playout and low
latency operation.
Examples include, but are not limited to:
Social TV : RTCP for inter-destination media synchronization [9]
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
Williams, et al. Expires August 23, 2013 [Page 3]
Internet-Draft RTP Clock Source Signalling February 2013
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.
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.
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 in the range of microseconds [21].
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.
3. Definitions
The following definitions are used in this draft:
media level : Media level information applies to a single SDP media
stream. In an SDP description, media-level information appears
after each "m"-line.
multimedia session : A set of multimedia senders and receivers as
well as the data streams flowing from senders to receivers. The
Session Description Protocol (SDP) [2] describes multimedia
sessions.
Williams, et al. Expires August 23, 2013 [Page 4]
Internet-Draft RTP Clock Source Signalling February 2013
RTP media stream : A single stream of RTP packets identified by an
RTP SSRC.
RTP media sender : The device generating an associated RTP media
stream
SDP media stream : An RTP session potentially containing more than
one RTP source. SDP media descriptions beginning with an "m"-line
define the parameters of an SDP media stream.
session level : Session level information applies to an entire
multimedia session. In an SDP description, session-level
information appears before the first "m"-line.
source level : Source level information applies to a RTP media
stream Source-Specific Media Attributes in the Session Description
Protocol (SDP) [3] defines how source-level information is
included into an SDP session description.
traceable time : A clock is considered to provide traceable time if
it can be proven to be synchronised to International Atomic Time
(TAI). Coordinated Universal Time (UTC) is a time standard
synchronized to TAI. UTC is therefore also considered traceable
time once leap seconds have been taken unto account. GPS [10] is
commonly used to provide a TAI traceable time reference. Some
network time synchronisation protocols (e.g. PTP [11], NTP) can
explicitly indicate that the master clock is providing a traceable
time reference over the network.
4. Timestamp Reference Clock Source Signalling
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. NTP [12]) and radio clocks (e.g. GPS [10]).
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.
4.1. Clock synchronization
Two or more local clocks that are sufficiently synchronised will
produce timestamps for a given RTP event can be used as if they came
from the same clock. Providing they are sufficiently synchronised,
Williams, et al. Expires August 23, 2013 [Page 5]
Internet-Draft RTP Clock Source Signalling February 2013
timestamps produced in one RTP sender or receiver can be directly
compared to a local clock in another RTP sender or receiver.
The accuracy of synchronisation required is application dependent.
See Applications (Section 2) section for a discussion of applications
and their corresponding requirements. To serve as a reference clock,
clocks must minimally be syntonised (exactly frequency matched) to
one another.
Sufficient synchronisation 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.
Another approach is to use clocks providing a global time reference
(e.g. GPS, Galileo). 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 providing
traceable time.
4.2. Identifying NTP Reference Clocks
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).
Two or more NTP servers may be listed at the same level in the
session description to indicate that they are interchangeable. RTP
senders or 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.
4.3. Identifying PTP Reference Clocks
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.
Three flavours of IEEE 1588 are in use today:
o IEEE 1588-2002 [13]: the original "Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems". This is also known as IEEE1588v1 or PTPv1.
Williams, et al. Expires August 23, 2013 [Page 6]
Internet-Draft RTP Clock Source Signalling February 2013
o IEEE 1588-2008 [11]: 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.
o IEEE 802.1AS [14]: "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
as described in IEEE 802.1BA-2011 [15].
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 boundary clock which is itself slaved to another
boundary clock or the grandmaster passes the grandmaster
ClockIdentity through to its slaves.
Several instances of the IEEE 1588 protocol may operate independently
on a single network, forming distinct PTP 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).
When PTP domains are signalled via SDP, senders and receivers SHOULD
check that both grandmaster ClockIdentity and PTP domain match when
determining clock equivalence.
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 biased by configuration parameters to influence the election
process. In some systems it may be desirable to limit the number of
possible PTP clock masters to avoid the need to re-signal timestamp
clock sources when the clock master changes.
4.4. Identifying Global Reference Clocks
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.
Williams, et al. Expires August 23, 2013 [Page 7]
Internet-Draft RTP Clock Source Signalling February 2013
4.5. Other Reference Clocks
RFC 3550 allows senders and receivers to either use a local wallclock
reference for their NTP timestamps or, by setting the timestamp field
to 0, to supply no timestamps at all. Both are common practice in
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 other systems, all RTP senders and 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 and receivers in a session using a private reference clock
are assumed to have a mechanism outside this specification for
determining whether their timestamp clocks are equivalent.
4.6. Traceable Reference Clocks
A timestamp clock source may be labelled "traceable" if it is known
to be to delivering traceable time. Providing adjustments are made
for differing epochs, timezones and leap seconds, 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.
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.
4.7. SDP Signalling of Timestamp Clock Source
Specification of the timestamp reference 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).
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. More specific signalling
included at the source level overrides default media level
signalling.
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
Williams, et al. Expires August 23, 2013 [Page 8]
Internet-Draft RTP Clock Source Signalling February 2013
signalling at the session level.
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 time sources MUST NOT be mixed with non-
traceable time sources at any given level.
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]
protocol supports re-signalling of updated SDP information, however
other protocols may require additional notification mechanisms.
Figure 1 shows the ABNF [5] grammar for the SDP reference clock
source information.
Williams, et al. Expires August 23, 2013 [Page 9]
Internet-Draft RTP Clock Source Signalling February 2013
timestamp-refclk = "a=ts-refclk:" clksrc CRLF
clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext
ntp = "ntp=" ntp-server-addr
ntp-server-addr = host [ ":" port ]
ntp-server-addr =/ "traceable"
ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002"
ptp-version =/ "IEEE1588-2008"
ptp-version =/ "IEEE802.1AS-2011"
ptp-version =/ ptp-version-ext
ptp-version-ext = token
ptp-server = ptp-gmid [":" ptp-domain] / "traceable"
ptp-gmid = EUI64
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" ]
clksrc-ext = token
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
EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 1: Timestamp Reference Clock Source Signalling
Williams, et al. Expires August 23, 2013 [Page 10]
Internet-Draft RTP Clock Source Signalling February 2013
4.7.1. Examples
Figure 2 shows an example SDP description with a timestamp reference
clock source defined at the session level.
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
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 233.252.0.1/64
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
Figure 2: Timestamp reference clock definition at the session level
Figure 3 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.
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
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 233.252.0.1/64
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
Figure 3: Timestamp reference clock definition at the media level
Figure 4 shows an example SDP description with a timestamp reference
clock definition at the source level overriding the session level
default.
Williams, et al. Expires August 23, 2013 [Page 11]
Internet-Draft RTP Clock Source Signalling February 2013
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
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 233.252.0.1/64
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
Figure 4: Timestamp reference clock signalling at the source level
5. Media Clock Source Signalling
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).
5.1. Asynchronously Generated Media Clock
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.
The asynchronously generated media clock is the assumed mode of
operation when there is no signalling of media clock source.
Alternatively, asynchronous media clock may be explicitly signalled.
a=mediaclk:sender
5.2. Direct-Referenced Media Clock
A media clock may be directly derived from a reference clock. For
this case it is required that a reference clock be specified with an
a=ts-refclk attribute (Section 4.7).
Williams, et al. Expires August 23, 2013 [Page 12]
Internet-Draft RTP Clock Source Signalling February 2013
The signalling optionally indicates a media clock offset value. The
offset indicates the RTP timestamp value at the epoch (time of
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 rate modifier may be specified. The modifier is expressed as the
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
A common synchronisation architecture for audio/visual systems
involves distributing a reference media clock from a master device to
a number of slave devices, typically by means of a cable. Examples
include audio word clock distribution and video black burst
distribution. In this case, the media clock is locally generated,
often by a crystal oscillator and is not locked to a timestamp
reference clock.
To support this architecture across a network, a master clock
identifier is associated with an RTP media stream carrying media
clock timing information from a master device. The master clock
identifier represents a media clock source in the master device.
Slave devices in turn associate the master media clock identifier
with streams they transmit, signalling the synchronisation
relationship between the master and slave devices.
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 RTP 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.
Williams, et al. Expires August 23, 2013 [Page 13]
Internet-Draft RTP Clock Source Signalling February 2013
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.
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 [16] 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:<media-clock-master-ssrc-id> mediaclk:master-id=<media-
clock-master-id>
An RTP media sender indicates that it is slaved to a clock master via
a clock master identifier:
a=mediaclk:master-id=<media-clock-master-id>
An RTP media sender indicates that it is slaved to an IEEE 1722 clock
master via a stream identifier (an EUI-64):
a=mediaclk:IEEE1722=<StreamID>
5.4. SDP Signalling of Media Clock Source
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).
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
Williams, et al. Expires August 23, 2013 [Page 14]
Internet-Draft RTP Clock Source Signalling February 2013
signalling overrides media clock source signalling at the enclosing
media level and session level.
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.
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.
Figure 5 shows the ABNF [5] grammar for the SDP media clock source
information.
mediaclk-master = "a=ssrc:" integer SP clk-master-id
clk-master-id = "mediaclk:master-id=" master-id
timestamp-mediaclk = "a=mediaclk:" mediaclock
mediaclock = sender / refclk / streamid / mediaclock-ext
sender = "sender" sender-ext
sender-ext = token
refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext]
rate = [ SP "rate=" integer "/" integer ]
direct-ext = token
streamid = "master-id=" master-id
streamid =/ "IEEE1722=" avb-stream-id
streamid =/ streamid-ext
master-id = EUI48
avb-stream-id = EUI64
EUI48 = 5(2HEXDIG ":") 2HEXDIG
EUI64 = 7(2HEXDIG ":") 2HEXDIG
streamid-ext = token
mediaclock-ext = token
Williams, et al. Expires August 23, 2013 [Page 15]
Internet-Draft RTP Clock Source Signalling February 2013
Figure 5: Media Clock Source Signalling
5.5. Examples
Figure 6 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.
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/8
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424
Figure 6: Media clock directly referenced to IEEE 1588-2008
Figure 7 shows an example SDP description 2 channels of 24-bit, 44056
kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-
2008 reference clock
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/44100/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 rate=1000/1001
Figure 7: "Oddball" sample rate directly referenced to IEEE 1588-2008
Figure 8 shows the same 48 kHz audio transmission from Figure 6 with
media clock derived from another RTP stream.
Williams, et al. Expires August 23, 2013 [Page 16]
Internet-Draft RTP Clock Source Signalling February 2013
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2
a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:master-id=00:60:2b:20:12:1f
Figure 8: RTP stream with media clock slaved to a master device
Figure 9 shows the same 48 kHz audio transmission from Figure 6 with
media clock derived from an IEEE 1722 AVB stream.
v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64
s=
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/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
Figure 9: RTP stream with media clock slaved to an IEEE1722 master
device
6. Signalling considerations
Signaling for timestamp clock source (Section 4.7) and media clock
source (Section 5.4) is defined to be used either by applications
that implement the SDP Offer/Answer model [8] or by applications that
use SDP to describe media and transport configurations.
A description or offer may include reference clock signalling, media
clock signalling or both. If no reference clock is specified, the
direct-referenced media clock (Section 5.2) is not allowed. If no
media clock is specified, an asynchronous media clock (Section 5.1)
is assumed. stream-referenced media clock (Section 5.3) may be used
with or without a reference clock specification. If a reference
clock is not signalled, the stream may be established as rate
synchronized however time synchronisation is not guaranteed.
Williams, et al. Expires August 23, 2013 [Page 17]
Internet-Draft RTP Clock Source Signalling February 2013
6.1. Usage in Offer/Answer
An answer to an offer with direct-referenced media clock and
reference clock specification must include the same media clock and
reference clock signalling in which case a connection is established
using the specified synchronisation. Alternatively the answer may
omit both the signals or return only the reference clock
specification. In this case, a connection is established assuming an
asynchronous media clock.
An answer to an offer with media-referenced media clock specification
must include the same media clock specification. The answer MUST
include the same reference clock signalling or may drop the reference
clock signalling. If reference clock signalling is not present in
the answer, either due to not being present in the offer or due to
being dropped by the answerer, the stream may be established as rate
synchronized but not time synchronized.
An asynchronous media clock is the default media clock mode. This
mode may be explicitly signalled or presumed due to lack of
signalling. Asynchronous media clocking does not require reference
clock signalling. An offer with asynchronous media clocking MAY
include reference clock signalling. Because the asynchronous media
clock is the default mode, the answerer is not required to explicitly
signal this even if it is explicitly signalled in the offer.
6.2. Usage Outside of Offer/Answer
SDP can be employed outside of the Offer/Answer context, for instance
for multimedia sessions that are announced through the Session
Announcement Protocol (SAP) [17], or streamed through the Real Time
Streaming Protocol (RTSP) [18]. The signaling model is simpler, as
the sender does not negotiate parameters, but the functionality
expected from specifying medial clock and reference clock attributes
is the same as in Offer/Answer.
7. Security Considerations
Entities receiving and acting upon an SDP message SHOULD be aware
that a session description cannot be trusted unless it has been
obtained by an authenticated transport protocol from a known and
trusted source. Many different transport protocols may be used to
distribute session description, and the nature of the authentication
will differ from transport to transport. For some transports,
security features are often not deployed. In case a session
description has not been obtained in a trusted manner, the endpoint
SHOULD exercise care because, among other attacks, the media sessions
Williams, et al. Expires August 23, 2013 [Page 18]
Internet-Draft RTP Clock Source Signalling February 2013
received may not be the intended ones, the destination where media is
sent to may not be the expected one, any of the parameters of the
session may be incorrect.
Incorrect reference or media clock parameters may cause devices or
streams to synchronize to unintended clock sources. Normally this
simply results in failure to make a media connection or failure to
synchronize once connected. Enough devices fraudulently assigned to
a specific clock source (e.g. a particular IEEE 1588 grandmaster)
may, however, constitute a successful a denial of service attack on
that source. Devices MAY wish to validate the integrity of the clock
description through some means before connecting to unfamiliar clock
sources.
8. IANA Considerations
The SDP attribute "ts-refclk" defined by this document is registered
with the IANA registry of SDP Parameters as follows:
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
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 Figure 1: "ntp",
"ptp", "gps", "gal", "local", "private".
The SDP attribute "mediaclk" defined by this document is registered
with the IANA registry of SDP Parameters as follows:
Williams, et al. Expires August 23, 2013 [Page 19]
Internet-Draft RTP Clock Source Signalling February 2013
SDP Attribute ("att-field"):
Attribute name: mediaclk
Long form: Media clock source
Type of name: att-field
Type of attribute: session and media level
Subject to charset: no
Purpose: See section 5 of this document
Reference: This document
Values: see this document and registrations below
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 Figure 5: "sender",
"direct", "master", "slave" and "IEEE1722".
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media
Attributes in the Session Description Protocol (SDP)",
RFC 5576, June 2009.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[6] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Williams, et al. Expires August 23, 2013 [Page 20]
Internet-Draft RTP Clock Source Signalling February 2013
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.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
9.2. Informative References
[9] Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
Montagud, M., and K. Gross, "Inter-destination Media
Synchronization using the RTP Control Protocol (RTCP)",
draft-ietf-avtcore-idms-08 (work in progress), January 2013.
[10] Global Positioning Systems Directorate, "Navstar GPS Space
Segment/Navigation User Segment Interfaces", September 2011.
[11] Institute of Electrical and Electronics Engineers, "1588-2008 -
IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", IEEE Std 1588-
2008, 2008,
<http://standards.ieee.org/findstds/standard/1588-2008.html>.
[12] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time
Protocol Version 4: Protocol and Algorithms Specification",
RFC 5905, June 2010.
[13] Institute of Electrical and Electronics Engineers, "1588-2002 -
IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", IEEE Std 1588-
2002, 2002,
<http://standards.ieee.org/findstds/standard/1588-2002.html>.
[14] "Timing and Synchronization for Time-Sensitive Applications in
Bridged Local Area Networks",
<http://standards.ieee.org/findstds/standard/
802.1AS-2011.html>.
[15] "Audio Video Bridging (AVB) Systems",
<http://standards.ieee.org/findstds/standard/
802.1BA-2011.html>.
[16] "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>.
Williams, et al. Expires August 23, 2013 [Page 21]
Internet-Draft RTP Clock Source Signalling February 2013
[17] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[18] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
URIs
[19] <http://en.wikipedia.org/wiki/Genlock>
[20] <http://en.wikipedia.org/wiki/Word_clock>
[21] <http://www.ieee802.org/1/files/public/docs2007/
as-dolsen-time-accuracy-0407.pdf>
Authors' Addresses
Aidan Williams
Audinate
Level 1, 458 Wattle St
Ultimo, NSW 2007
Australia
Phone: +61 2 8090 1000
Fax: +61 2 8090 1001
Email: aidan.williams@audinate.com
URI: http://www.audinate.com/
Kevin Gross
AVA Networks
Boulder, CO
US
Email: kevin.gross@avanw.com
URI: http://www.avanw.com/
Ray van Brandenburg
TNO
Brassersplein 2
Delft 2612CT
the Netherlands
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Williams, et al. Expires August 23, 2013 [Page 22]
Internet-Draft RTP Clock Source Signalling February 2013
Hans Stokking
TNO
Brassersplein 2
Delft 2612CT
the Netherlands
Email: hans.stokking@tno.nl
Williams, et al. Expires August 23, 2013 [Page 23]
