draft-ietf-avtcore-clksrc-04.txt   draft-ietf-avtcore-clksrc-05.txt 
Audio/Video Transport Core Maintenance A.M. Williams Audio/Video Transport Core A. Williams
Internet-Draft Audinate Maintenance Audinate
Intended status: Standards Track K. Gross Internet-Draft K. Gross
Expires: November 10, 2013 AVA Networks Intended status: Standards Track AVA Networks
R. van Brandenburg Expires: January 15, 2014 R. van Brandenburg
H.M. Stokking H. Stokking
TNO TNO
May 09, 2013 July 14, 2013
RTP Clock Source Signalling RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-04 draft-ietf-avtcore-clksrc-05
Abstract Abstract
NTP format timestamps are used by several RTP protocols for NTP format timestamps are used by several RTP protocols for
synchronisation and statistical measurements. This memo specifies synchronisation and statistical measurements. This memo specifies
SDP signalling identifying timestamp reference clock sources and SDP SDP signalling identifying timestamp reference clock sources and SDP
signalling identifying the media clock sources in a multimedia signalling identifying the media clock sources in a multimedia
session. session.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2013. This Internet-Draft will expire on January 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applications . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 5 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 6
4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 5 4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 6
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . 6 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 7
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . 6 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 7
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 8 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 9
4.5. Other Reference Clocks . . . . . . . . . . . . . . . . . 8 4.5. Private Reference Clocks . . . . . . . . . . . . . . . . . 9
4.6. Traceable Reference Clocks . . . . . . . . . . . . . . . 8 4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . . 9
4.7. SDP Signalling of Timestamp Reference Clock Source . . . 8 4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . . 9
4.7.1. Examples . . . . . . . . . . . . . . . . . . . . . . 10 4.8. SDP Signalling of Timestamp Reference Clock Source . . . . 9
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 11 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Asynchronously Generated Media Clock . . . . . . . . . . 12 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 13
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 12 5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 13 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 14
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . 14 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 15
6. Signalling considerations . . . . . . . . . . . . . . . . . . 17 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 17 6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 18 6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.1.1. Indicating Support for Clock Source Signalling . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20
8.1. Reference clock registry . . . . . . . . . . . . . . . . 19 6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20
8.2. Media clock registry . . . . . . . . . . . . . . . . . . 19 6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21 8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 22
8.3. Timestamp Reference Clock Source Parameters Registry . . . 23
8.4. Media Clock Source Parameters Registry . . . . . . . . . . 24
8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 24
8.5.1. Source-level Reference Clock Attribute . . . . . . . . 24
8.5.2. Source-level Media Clock Attribute . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
RTP protocols use NTP format timestamps to facilitate multimedia RTP protocols use NTP format timestamps to facilitate multimedia
session synchronisation and for providing estimates of round trip session synchronisation and for providing estimates of round trip
time (RTT) and other statistical parameters. time (RTT) and other statistical parameters.
Information about media clock timing exchanged in NTP format Information about media clock timing exchanged in NTP format
timestamps may come from a clock which is synchronised to a global timestamps may come from a clock which is synchronised to a global
time reference, but this cannot be assumed nor is there a time reference, but this cannot be assumed nor is there a
skipping to change at page 3, line 23 skipping to change at page 4, line 29
RTP can time align flows from the same source at a given receiver RTP can time align flows from the same source at a given receiver
using relative timing, however tight synchronisation between two or using relative timing, however tight synchronisation between two or
more different receivers (possibly with different network paths) or more different receivers (possibly with different network paths) or
between two or more senders is not possible. between two or more senders is not possible.
High performance AV systems often use a reference media clock High performance AV systems often use a reference media clock
distributed to all devices in the system. The reference media clock distributed to all devices in the system. The reference media clock
is often distinct from the reference clock used to provide is often distinct from the reference clock used to provide
timestamps. A reference media clock may be provided along with an timestamps. A reference media clock may be provided along with an
audio or video signal interface, or via a dedicated clock signal audio or video signal interface, or via a dedicated clock signal
(e.g. genlock [SMPTE-318-1999] or audio word clock [AES11-2009]). (e.g. genlock [SMPTE-318-1999] or audio word clock [AES11-2009]). If
If sending and receiving media clocks are known to be synchronised to sending and receiving media clocks are known to be synchronised to a
a common reference clock, performance can improved by minimising common reference clock, performance can improved by minimising
buffering and avoiding rate conversion. buffering and avoiding rate conversion.
This specification defines SDP signalling of timestamp reference This specification defines SDP signalling of timestamp reference
clock sources and media reference clock sources. clock sources and media reference clock sources.
2. Applications 2. Applications
Timestamp reference clock source and media clock signalling benefit Timestamp reference clock source and media clock signalling benefit
applications requiring synchronised media capture or playout and low applications requiring synchronised media capture or playout and low
latency operation. latency operation.
skipping to change at page 4, line 13 skipping to change at page 5, line 20
video projectors, or television sets tiled together contiguously video projectors, or television sets tiled together contiguously
or overlapped in order to form one large screen. Each of the or overlapped in order to form one large screen. Each of the
screens reproduces a portion of the larger picture. In some screens reproduces a portion of the larger picture. In some
implementations, each screen or projector may be individually implementations, each screen or projector may be individually
connected to the network and receive its portion of the overall connected to the network and receive its portion of the overall
image from a network-connected video server or video scaler. image from a network-connected video server or video scaler.
Screens are refreshed at 50 or 60 hertz or potentially faster. If Screens are refreshed at 50 or 60 hertz or potentially faster. If
the refresh is not synchronized, the effect of multiple screens the refresh is not synchronized, the effect of multiple screens
acting as one is broken. acting as one is broken.
Networked Audio : Networked loudspeakers, amplifiers and analogue I/ Networked Audio : Networked loudspeakers, amplifiers and analogue
O devices transmitting or receiving audio signals via RTP can be I/O devices transmitting or receiving audio signals via RTP can be
connected to various parts of a building or campus network. Such connected to various parts of a building or campus network. Such
situations can for example be found in large conference rooms, situations can for example be found in large conference rooms,
legislative chambers, classrooms (especially those supporting legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as distance learning) and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in stadiums. Since humans are more susceptible to differences in
audio delay, this use case needs even more accuracy than the video audio delay, this use case needs even more accuracy than the video
wall use case. Depending on the exact application, the need for wall use case. Depending on the exact application, the need for
accuracy can then be in the range of microseconds [1]. accuracy can then be in the range of microseconds [1].
Sensor Arrays : Sensor arrays contain many synchronised measurement Sensor Arrays : Sensor arrays contain many synchronised measurement
skipping to change at page 7, line 30 skipping to change at page 8, line 31
grandmaster clock that is the ultimate source of timing information grandmaster clock that is the ultimate source of timing information
for the network. A boundary clock which is itself slaved to another for the network. A boundary clock which is itself slaved to another
boundary clock or the grandmaster passes the grandmaster boundary clock or the grandmaster passes the grandmaster
ClockIdentity through to its slaves. ClockIdentity through to its slaves.
Several instances of the IEEE 1588 protocol may operate independently Several instances of the IEEE 1588 protocol may operate independently
on a single network, forming distinct PTP domains, each of which may on a single network, forming distinct PTP domains, each of which may
have a different grandmaster clock. As the IEEE 1588 standards have have a different grandmaster clock. As the IEEE 1588 standards have
developed, the definition of PTP domains has changed. IEEE 1588-2002 developed, the definition of PTP domains has changed. IEEE 1588-2002
identifies protocol subdomains by a textual name, but IEEE 1588-2008 identifies protocol subdomains by a textual name, but IEEE 1588-2008
identifies protocol domains using a numeric domain number. 802.1AS identifies protocol domains using a numeric domain number. 802.1AS is
is a Layer-2 profile of IEEE 1588-2008 supporting a single numeric a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock
clock domain (0). domain (0).
When PTP domains are signalled via SDP, senders and receivers SHOULD When PTP domains are signalled via SDP, senders and receivers SHOULD
check that both grandmaster ClockIdentity and PTP domain match when check that both grandmaster ClockIdentity and PTP domain match when
determining clock equivalence. determining clock equivalence.
Two or more IEEE 1588 clocks MAY be listed at the same level in the Two or more IEEE 1588 clocks MAY be listed at the same level in the
session description to indicate that all of the listed clocks are session description to indicate that all of the listed clocks are
candidate grandmaster clocks for the domain or deliver the same candidate grandmaster clocks for the domain or deliver the same
reference time and may be used interchangeably. RTP senders and reference time and may be used interchangeably. RTP senders and
receivers are assured proper synchronization regardless of which receivers are assured proper synchronization regardless of which
skipping to change at page 8, line 12 skipping to change at page 9, line 14
possible PTP clock masters to avoid the need to re-signal timestamp possible PTP clock masters to avoid the need to re-signal timestamp
reference clock sources when the clock master changes. reference clock sources when the clock master changes.
4.4. Identifying Global Reference Clocks 4.4. Identifying Global Reference Clocks
Global reference clocks provide a source of traceable time, typically Global reference clocks provide a source of traceable time, typically
via a hardware radio receiver interface. Examples include GPS and via a hardware radio receiver interface. Examples include GPS and
Galileo. Apart from the name of the reference clock system, no Galileo. Apart from the name of the reference clock system, no
further identification is required. further identification is required.
4.5. Other Reference Clocks 4.5. Private 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 In other systems, all RTP senders and receivers may use a timestamp
reference clock that is not provided by one of the methods listed reference clock that is not provided by one of the methods listed
above. Examples may include the reference time information provided above. Examples may include the reference time information provided
by digital television or cellular services. These sources are by digital television or cellular services. These sources are
identified as "private" reference clocks. All RTP senders and identified as "private" reference clocks. All RTP senders and
receivers in a session using a private reference clock are assumed to receivers in a session using a private reference clock are assumed to
have a mechanism outside this specification for determining whether have a mechanism outside this specification for determining whether
their timestamp reference clocks are equivalent. their timestamp reference clocks are equivalent.
4.6. Traceable Reference Clocks 4.6. Local 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.
4.7. Traceable Reference Clocks
A timestamp reference clock source may be labelled "traceable" if it A timestamp reference clock source may be labelled "traceable" if it
is known to be to delivering traceable time. Providing adjustments is known to be to delivering traceable time. Providing adjustments
are made for differing epochs, timezones and leap seconds, timestamps are made for differing epochs, timezones and leap seconds, timestamps
taken using clocks synchronised to a traceable time source can be taken using clocks synchronised to a traceable time source can be
directly compared even if the clocks are synchronised to different directly compared even if the clocks are synchronised to different
sources or via different mechanisms. sources or via different mechanisms.
Since all NTP and PTP servers providing traceable time can be Since all NTP and PTP servers providing traceable time can be
directly compared, it is not necessary to identify traceable time directly compared, it is not necessary to identify traceable time
servers by protocol address or other identifiers. servers by protocol address or other identifiers.
4.7. SDP Signalling of Timestamp Reference Clock Source 4.8. SDP Signalling of Timestamp Reference Clock Source
Specification of the timestamp reference clock source may be at any Specification of the timestamp reference clock source may be at any
or all levels (session, media or source) of an SDP description (see or all levels (session, media or source) of an SDP description (see
level definitions (Section 3) earlier in this document for more level definitions (Section 3) earlier in this document for more
information). information).
Timestamp reference clock source signalling included at session-level Timestamp reference clock source signalling included at session-level
provides default parameters for all RTP sessions and sources in the provides default parameters for all RTP sessions and sources in the
session description. More specific signalling included at the media session description. More specific signalling included at the media
level overrides default session level signalling. More specific level overrides default session level signalling. More specific
signalling included at the source level overrides default media level signalling included at the source level overrides default media level
signalling. signalling.
If timestamp reference clock source signalling is included anywhere If timestamp reference clock source signalling is included anywhere
in an SDP description, it must be properly defined for all levels in in an SDP description, it must be properly defined for all levels in
the description. This may simply be achieved by providing default the description. This may simply be achieved by providing default
signalling at the session level. signalling at the session level.
Timestamp reference clock parameters may be repeated at a given level Timestamp reference clock parameters may be repeated at a given level
(i.e. for a session or source) to provide information about (i.e. for a session or source) to provide information about
additional servers or clock sources. If the attribute is repeated at additional servers or clock sources. If the attribute is repeated at
a given level, all clocks described at that level are assumed to be a given level, all clocks described at that level are assumed to be
equivalent. Traceable time sources MUST NOT be mixed with non- equivalent. Traceable time sources MUST NOT be mixed with non-
traceable time sources at any given level. traceable time sources at any given level.
Note that clock source parameters may change from time to time, for Note that clock source parameters may change from time to time, for
example, as a result of a PTP clock master election. The SIP example, as a result of a PTP clock master election. The SIP
[RFC3261] protocol supports re-signalling of updated SDP information, [RFC3261] protocol supports re-signalling of updated SDP information,
however other protocols may require additional notification however other protocols may require additional notification
mechanisms. mechanisms. "refclk-sl" is used to describe a reference clock at the
source level. "refclk" is used to describe a reference clock at
session or media levels.
Figure 1 shows the ABNF [RFC5234] grammar for the SDP reference clock Figure 1 shows the ABNF [RFC5234] grammar for the SDP reference clock
source information. source information.
refclk-sl = "a=ssrc:" integer SP timestamp-refclk
timestamp-refclk = "a=ts-refclk:" clksrc CRLF timestamp-refclk = "a=ts-refclk:" clksrc CRLF
clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext
ntp = "ntp=" ntp-server-addr ntp = "ntp=" ntp-server-addr
ntp-server-addr = host [ ":" port ] ntp-server-addr = host [ ":" port ]
ntp-server-addr =/ "traceable" ntp-server-addr =/ "traceable"
ptp = "ptp=" ptp-version ":" ptp-server ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002" ptp-version = "IEEE1588-2002"
ptp-version =/ "IEEE1588-2008" ptp-version =/ "IEEE1588-2008"
skipping to change at page 10, line 10 skipping to change at page 11, line 35
ptp-domain-char = %x21-7E / %x00 ptp-domain-char = %x21-7E / %x00
; allowed characters: 0x21-0x7E (IEEE 1588-2002) ; allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-nmbr = "domain-nmbr=" %x00-7f ptp-domain-nmbr = "domain-nmbr=" %x00-7f
; allowed number range: 0-127 (IEEE 1588-2008) ; allowed number range: 0-127 (IEEE 1588-2008)
gps = "gps" gps = "gps"
gal = "gal" gal = "gal"
local = "local" local = "local"
private = "private" [ ":" "traceable" ] private = "private" [ ":" "traceable" ]
clksrc-ext = token clksrc-ext = token
host = hostname / IPv4address / IPv6reference host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ] hostname = *( domainlabel "." ) toplabel [ "." ]
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domainlabel = alphanum domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum / alphanum *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]" IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ] IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
skipping to change at page 10, line 27 skipping to change at page 12, line 4
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]" IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ] IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG hex4 = 1*4HEXDIG
port = 1*DIGIT port = 1*DIGIT
EUI64 = 7(2HEXDIG "-") 2HEXDIG EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 1: Timestamp Reference Clock Source Signalling Figure 1: Timestamp Reference Clock Source Signalling
4.7.1. Examples 4.8.1. Examples
Figure 2 shows an example SDP description with a timestamp reference Figure 2 shows an example SDP description with a timestamp reference
clock source defined at the session level. clock source defined at the session level.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
skipping to change at page 11, line 9 skipping to change at page 12, line 31
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
Figure 2: Timestamp reference clock definition at the session level Figure 2: Timestamp reference clock definition at the session level
Figure 3 shows an example SDP description with timestamp reference Figure 3 shows an example SDP description with timestamp reference
clock definitions at the media level overriding the session level clock definitions at the media level overriding the session level
defaults. defaults.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
a=ts-refclk:local a=ts-refclk:local
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=ts-refclk:ntp=203.0.113.10 a=ts-refclk:ntp=203.0.113.10
a=ts-refclk:ntp=198.51.100.22 a=ts-refclk:ntp=198.51.100.22
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 3: Timestamp reference clock definition at the media level Figure 3: Timestamp reference clock definition at the media level
Figure 4 shows an example SDP description with a timestamp reference Figure 4 shows an example SDP description with a timestamp reference
clock definition at the source level overriding the session level clock definition at the source level overriding the session level
default. default.
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar s=SDP Seminar
skipping to change at page 12, line 29 skipping to change at page 14, line 9
The asynchronously generated media clock is the assumed mode of The asynchronously generated media clock is the assumed mode of
operation when there is no signalling of media clock source. operation when there is no signalling of media clock source.
Alternatively, asynchronous media clock may be explicitly signalled. Alternatively, asynchronous media clock may be explicitly signalled.
a=mediaclk:sender a=mediaclk:sender
5.2. Direct-Referenced Media Clock 5.2. Direct-Referenced Media Clock
A media clock may be directly derived from a reference clock. For A media clock may be directly derived from a reference clock. For
this case it is required that a reference clock be specified with an this case it is required that a reference clock be specified with an
a=ts-refclk attribute (Section 4.7). a=ts-refclk attribute (Section 4.8).
The signalling optionally indicates a media clock offset value. The The signalling optionally indicates a media clock offset value. The
offset indicates the RTP timestamp value at the epoch (time of offset indicates the RTP timestamp value at the epoch (time of
origin) of the reference clock. If no offset is signalled, the origin) of the reference clock. If no offset is signalled, the
offset can be inferred at the receiver by examining RTCP sender offset can be inferred at the receiver by examining RTCP sender
reports which contain NTP and RTP timestamps which combined define a reports which contain NTP and RTP timestamps which combined define a
mapping. mapping.
A rate modifier may be specified. The modifier is expressed as the A rate modifier may be specified. The modifier is expressed as the
ratio of two integers and modifies the rate specified or implied by ratio of two integers and modifies the rate specified or implied by
the media description by this ratio. If omitted, the rate is assumed the media description by this ratio. If omitted, the rate is assumed
to be the exact rate specified or implied by the media format. For to be the exact rate specified or implied by the media format. For
example, without a rate specification, the media clock for an 8 kHz example, without a rate specification, the media clock for an 8 kHz
G.711 audio stream will advance exactly 8000 units for each second G.711 audio stream will advance exactly 8000 units for each second
advance in the reference clock from which it is derived. advance in the reference clock from which it is derived.
The rate modifier is primarily useful for accommodating certain The rate modifier is primarily useful for accommodating certain
"oddball" audio sample rates associated with NTSC video (see Figure "oddball" audio sample rates associated with NTSC video (see
7). Modified rates are not advised for video streams which generally Figure 7). Modified rates are not advised for video streams which
use a 90 kHz RTP clock regardless of frame rate or sample rate used generally use a 90 kHz RTP clock regardless of frame rate or sample
for embedded audio. rate used for embedded audio.
a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
denominator>] denominator>]
5.3. Stream-Referenced Media Clock 5.3. Stream-Referenced Media Clock
A common synchronisation architecture for audio/visual systems A common synchronisation architecture for audio/visual systems
involves distributing a reference media clock from a master device to involves distributing a reference media clock from a master device to
a number of slave devices, typically by means of a cable. Examples a number of slave devices, typically by means of a cable. Examples
include audio word clock distribution and video black burst include audio word clock distribution and video black burst
skipping to change at page 13, line 51 skipping to change at page 15, line 30
In a given system, master clock identifiers must be unique. Such In a given system, master clock identifiers must be unique. Such
identifiers MAY be manually configured, however 17 octet string identifiers MAY be manually configured, however 17 octet string
identifiers SHOULD be generated according to the "short-term identifiers SHOULD be generated according to the "short-term
persistent RTCP CNAME" algorithm as described in RFC6222 [RFC6222]. persistent RTCP CNAME" algorithm as described in RFC6222 [RFC6222].
A reference stream can be an RTP stream or AVB stream based on the A reference stream can be an RTP stream or AVB stream based on the
IEEE 1722 [IEEE1722] standard. IEEE 1722 [IEEE1722] standard.
An RTP clock master stream SHOULD be identified at the source level An RTP clock master stream SHOULD be identified at the source level
by an SSRC and master clock identifier. If master clock identifiers by an SSRC [RFC5576] and master clock identifier. If master clock
are declared at the media or session level, all RTP sources at or identifiers are declared at the media or session level, all RTP
below the level of declaration MUST provide equivalent timing to a sources at or below the level of declaration MUST provide equivalent
slave receiver. timing to a slave receiver.
a=ssrc:<media-clock-master-ssrc-id> mediaclk:master-id=<media- a=ssrc:<master-media-clock-stream-ssrc> mediaclk:master-id=<media-
clock-master-id> clock-master-id>
An RTP media sender indicates that it is slaved to a clock master via An RTP media sender indicates that it is slaved to a media clock
a clock master identifier: master via a clock master identifier:
a=mediaclk:master-id=<media-clock-master-id> a=mediaclk:master-id=<media-clock-master-id>
An RTP media sender indicates that it is slaved to an IEEE 1722 clock An RTP media sender indicates that it is slaved to an IEEE 1722 clock
master via a stream identifier (an EUI-64): master via a stream identifier (an EUI-64):
a=mediaclk:IEEE1722=<StreamID> a=mediaclk:IEEE1722=<StreamID>
5.4. SDP Signalling of Media Clock Source 5.4. SDP Signalling of Media Clock Source
skipping to change at page 14, line 45 skipping to change at page 16, line 24
stream basis. In the absence of media clock source signals, stream basis. In the absence of media clock source signals,
receivers assume an asynchronous media clock generated by the sender. receivers assume an asynchronous media clock generated by the sender.
Media clock source parameters may be repeated at a given level (i.e. Media clock source parameters may be repeated at a given level (i.e.
for a session or source) to provide information about additional for a session or source) to provide information about additional
clock sources. If the attribute is repeated at a given level, all clock sources. If the attribute is repeated at a given level, all
clocks described at that level are comparable clock sources and may clocks described at that level are comparable clock sources and may
be used interchangeably. be used interchangeably.
Figure 5 shows the ABNF [RFC5234] grammar for the SDP media clock Figure 5 shows the ABNF [RFC5234] grammar for the SDP media clock
source information. source information. "mediaclk-master" is used to declare a master
media clock reference at the source level. "timestamp-mediaclk-sl" is
a media clock description used at the source level. "timestamp-
mediaclk" is a media clock description at the session or media level.
mediaclk-master = "a=ssrc:" integer SP clk-master-id mediaclk-master = "a=ssrc:" integer SP clk-master-id
clk-master-id = "mediaclk:master-id=" master-id clk-master-id = "mediaclk:master-id=" master-id
timestamp-mediaclk = "a=mediaclk:" mediaclock timestamp-mediaclk-sl = "a:ssrc" integer SP timestamp-mediaclk
mediaclock = sender / refclk / streamid / mediaclock-ext
sender = "sender" sender-ext timestamp-mediaclk = "a=mediaclk:" mediaclock
sender-ext = token mediaclock = sender / refclk / streamid / mediaclock-ext
refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] sender = "sender" sender-ext
rate = [ SP "rate=" integer "/" integer ] sender-ext = token
direct-ext = token refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext]
streamid = "master-id=" master-id rate = [ SP "rate=" integer "/" integer ]
streamid =/ "IEEE1722=" avb-stream-id
streamid =/ streamid-ext
master-id = EUI48 direct-ext = token
avb-stream-id = EUI64
EUI48 = 5(2HEXDIG ":") 2HEXDIG streamid = "master-id=" master-id
EUI64 = 7(2HEXDIG ":") 2HEXDIG streamid =/ "IEEE1722=" avb-stream-id
streamid =/ streamid-ext
streamid-ext = token master-id = EUI48
avb-stream-id = EUI64
mediaclock-ext = token [SP byte-string] EUI48 = 5(2HEXDIG ":") 2HEXDIG
EUI64 = 7(2HEXDIG ":") 2HEXDIG
streamid-ext = token
mediaclock-ext = token [SP byte-string]
Figure 5: Media Clock Source Signalling Figure 5: Media Clock Source Signalling
5.5. Examples 5.5. Examples
Figure 6 shows an example SDP description 8 channels of 24-bit, 48 Figure 6 shows an example SDP description 8 channels of 24-bit, 48
kHz audio transmitted as a multicast stream. Media clock is derived kHz audio transmitted as a multicast stream. Media clock is derived
directly from an IEEE 1588-2008 reference. directly from an IEEE 1588-2008 reference.
v=0 v=0
skipping to change at page 16, line 6 skipping to change at page 18, line 19
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/8 a=rtpmap:96 L24/48000/8
a=sendonly a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:direct=963214424 a=mediaclk:direct=963214424
Figure 6: Media clock directly referenced to IEEE 1588-2008 Figure 6: Media clock directly referenced to IEEE 1588-2008
Figure 7 shows an example SDP description 2 channels of 24-bit, 44056 Figure 7 shows an example SDP description 2 channels of 24-bit, 44056
kHz NTSC "pull-down" media clock derived directly from an IEEE kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-
1588-2008 reference clock 2008 reference clock
v=0 v=0
o=- 1311738121 1311738121 IN IP4 192.0.2.1 o=- 1311738121 1311738121 IN IP4 192.0.2.1
c=IN IP4 233.252.0.1/64 c=IN IP4 233.252.0.1/64
s= s=
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/44100/2 a=rtpmap:96 L24/44100/2
a=sendonly a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
skipping to change at page 17, line 19 skipping to change at page 19, line 19
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
a=rtpmap:96 L24/48000/2 a=rtpmap:96 L24/48000/2
a=sendonly a=sendonly
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
Figure 9: RTP stream with media clock slaved to an IEEE1722 master Figure 9: RTP stream with media clock slaved to an IEEE1722 master
device device
6. Signalling considerations 6. Signalling Considerations
Signaling for timestamp reference clock source (Section 4.7) and Signaling of timestamp reference clock source (Section 4.8) and media
media clock source (Section 5.4) is defined to be used either by clock source (Section 5.4) is defined to be used either by
applications that implement the SDP Offer/Answer model [RFC3264] or applications that implement the SDP Offer/Answer model [RFC3264] or
by applications that use SDP to describe media and transport by applications that use SDP to describe media and transport
configurations. configurations.
A description or offer may include reference clock signalling, media A description SHOULD include both reference clock signalling and
clock signalling neither or both. When a direct-referenced media media clock signalling. If no reference clock is avaialble, this
clock (Section 5.2) is specified, reference clock signalling is SHOULD be signalled as a local reference (Section 4.6).
REQUIRED. If no media clock is signalled, an asynchronous media
clock (Section 5.1) is assumed. Asynchronous and stream-referenced When no media clock signalling is present, an asynchronous media
media clocks (Section 5.3) may be used with or without reference clock (Section 5.1) MUST be assumed. When no reference clock
clock signalling. If a reference clock is not signalled, the signalling is present, a local reference clock (Section 4.6) MUST be
corresponding media clock may be established as rate synchronized assumed.
with no assurance of time synchronisation.
If a reference clock is not signalled or a local reference is
specified, the corresponding media clock may be established as rate
synchronised with no assurance of time synchronisation.
When the description signals a direct-referenced media clock
(Section 5.2), reference clock signalling is REQUIRED. Asynchronous
and stream-referenced media clocks (Section 5.3) MAY be specified
with or without a reference clock signalling.
6.1. Usage in Offer/Answer 6.1. Usage in Offer/Answer
Usage of reference clock and media clock signalling in offer/answer During offer/answer, clock source signalling via SDP uses a
allows the offerer to declare the reference clock and media clock in declarative model. Supported media and/or reference clocks are
use and allows the answerer to acknowledge that a connection specified in the offered SDP description. The answerer may accept or
according to these declarations will be successful or, in limited reject the offer in an application-specific way depending on the
cases described below, specify a simplified synchronization mode. clocks that are available and the clocks that are offered. For
example, an answerer may choose to accept an offer that lacks a
common clock by falling back to a lower performance mode of operation
(e.g. by assuming reference or media clocks are local rather than
shared). Conversely, the answerer may choose to reject the offer
when the offered clock specifications indicate that the available
reference and/or media clocks are incompatible.
While full negotiation of reference clock and media clock attributes While negotiation of reference clock and media clock attributes is
is not directly supported in the clock source signalling defined in not defined in this document, negotiation MAY be accomplished using
this document, negotiation MAY be accomplished using capabilities the capabilities negotiation procedures defined in [RFC5939].
negotiation procedures defined in [RFC5939].
An answer to an offer with direct-referenced media clock SHOULD 6.1.1. Indicating Support for Clock Source Signalling
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 signals or include only the An offerer or answerer indicates support for media clock signalling
reference clock specified in the offer. In this case, a connection by including a reference or media clock specification in the SDP
with asynchronous media clock is established. description. An offerer or answerer without specific reference or
media clocks to signal SHOULD indicate support for clock source
signalling by including a local reference clock (Section 4.6)
specification in the SDP description.
An answer to an offer with stream-referenced media clock signalling 6.1.2. Timestamp Reference Clock
SHOULD include the same media clock specification. If the offer
contains reference clock signalling, the answer SHOULD include the
same reference clock specification. The answer MAY omit 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 in the answer, the stream may be established as rate
synchronised but not time synchronised.
An asynchronous media clock is the default media clock mode. This If one or more of the reference clocks specified in the offer are
mode may be explicitly signalled (a=mediaclk:sender) or presumed due usable by the answerer, the answerer SHOULD respond with an answer
to lack of signalling. If explicit signalling of asynchronous media containing the subset of reference clock specifications in the offer
clock is included in the offer, it SHOULD also be included in the that are usable by the answerer. If the answerer rejects the offer
answer. An offer with asynchronous media clocking MAY include because the available reference clocks are incompatible, the
reference clock signalling. An answer to an asynchronous media clock rejection MUST contain at least one timestamp reference clock
offer with reference clock signalling SHOULD include the same specification usable by the answerer. If no external reference clock
reference clock specification. Alternatively, the answer MAY drop is available to the answerer a local reference clock (Section 4.6)
reference clock signalling in which case the connection may be specification SHOULD be included in the rejection.
established as rate synchronised but not time synchronised.
In both offers and answers, multiple reference clock specifications
indicate equivalent clocks from different sources which may be used
interchangeably. RTP senders and receivers are assured proper
synchronization regardless of which of the specified sources is
chosen and, in support of fault tolerance, may switch clock sources
while streaming.
6.1.3. Media Clock
If the media clock mode specified in the offer is acceptable to the
answerer, the answerer SHOULD respond with an answer containing the
same media clock specification as the offer. If the answerer rejects
the offer because the available reference clocks are incompatible,
the rejection MUST contain a media clock specification supported by
the answerer. If no shared media clocks are available to the
answerer an asynchronous media clock (Section 5.1) specification
SHOULD be included in the rejection.
6.2. Usage Outside of Offer/Answer 6.2. Usage Outside of Offer/Answer
SDP can be employed outside of the Offer/Answer context, for instance SDP can be employed outside of the Offer/Answer context, for instance
for multimedia sessions that are announced through the Session for multimedia sessions that are announced through the Session
Announcement Protocol (SAP) [RFC2974], or streamed through the Real Announcement Protocol (SAP) [RFC2974], or streamed through the Real
Time Streaming Protocol (RTSP) [RFC2326]. The signaling model is Time Streaming Protocol (RTSP) [RFC2326].
simpler, as the sender does not negotiate parameters, but the
functionality expected from specifying media clock and reference Devices using published descriptions to join sessions SHOULD assess
clock attributes is the same as in Offer/Answer. their synchronization compatiblity with the described session based
on the clock source signaling and SHOULD NOT attempt to join a
session with incompatible reference or media clocks.
7. Security Considerations 7. Security Considerations
Entities receiving and acting upon an SDP message SHOULD be aware Entities receiving and acting upon an SDP message SHOULD be aware
that a session description cannot be trusted unless it has been that a session description cannot be trusted unless it has been
obtained by an authenticated transport protocol from a known and obtained by an authenticated transport protocol from a known and
trusted source. Many different transport protocols may be used to trusted source. Many different transport protocols may be used to
distribute session description, and the nature of the authentication distribute session description, and the nature of the authentication
will differ from transport to transport. For some transports, will differ from transport to transport. For some transports,
security features are often not deployed. In case a session security features are often not deployed. In case a session
description has not been obtained in a trusted manner, the endpoint description has not been obtained in a trusted manner, the endpoint
SHOULD exercise care because, among other attacks, the media sessions SHOULD exercise care because, among other attacks, the media sessions
received may not be the intended ones, the destination where media is 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 sent to may not be the expected one, any of the parameters of the
session may be incorrect. session may be incorrect.
Incorrect reference or media clock parameters may cause devices or Incorrect reference or media clock parameters may cause devices or
streams to synchronize to unintended clock sources. Normally this streams to synchronize to unintended clock sources. Normally this
simply results in failure to make a media connection or failure to simply results in failure to establish a session or failure to
synchronize once connected. Enough devices fraudulently assigned to synchronize once connected. Enough devices fraudulently assigned to
a specific clock source (e.g. a particular IEEE 1588 grandmaster) a specific clock source (e.g. a particular IEEE 1588 grandmaster)
may, however, constitute a successful a denial of service attack on may, however, constitute a successful a denial of service attack on
that source. Devices MAY wish to validate the integrity of the clock that source. Devices MAY wish to validate the integrity of the clock
description through some means before connecting to unfamiliar clock description through some means before connecting to unfamiliar clock
sources. sources.
8. IANA Considerations 8. IANA Considerations
8.1. Reference clock registry This document defines two new SDP attributes: 'ts-refclk' and
'mediaclk', within the existing Internet Assigned Numbers Authority
(IANA) registry of SDP Parameters.
This document also defines a new IANA registry subordinate to the
IANA SDP Parameters registry: the Media Clock Source Parameters
Registry. Within this new registry, this document defines an initial
set of three media clock source parameters. Further, this document
defines a second new IANA registry subordinate to the IANA SDP
Parameters registry: the Timestamp Reference Clock Source Parameters
Registry. Within this new registry, this document defines an initial
six parameters.
8.1. Reference Clock SDP Parameter
The SDP attribute "ts-refclk" defined by this document is registered The SDP attribute "ts-refclk" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"): SDP Attribute ("att-field (both session and media level)"):
Attribute name: ts-refclk Attribute name: ts-refclk
Long form: Timestamp reference clock source Long form: Timestamp reference clock source
Type of name: att-field Type of name: att-field
Type of attribute: Session, media and source level Type of attribute: Session, media and source level
Subject to charset: No Subject to charset: No
Purpose: See section 4 of this document Purpose: See section 4 of this document
Reference: This document Reference: This document
Values: See this document and registrations below Values: See section 8.3 of this document
Figure 10
The attribute has an extensible parameter field and therefore a The attribute has an extensible parameter field and therefore a
registry for these parameters is required. This document creates an registry for these parameters is required. This new registry is
IANA registry called the Timestamp Reference Clock Source Parameters defined in Section 8.3.
Registry. It contains the six parameters defined in Figure 1: "ntp",
"ptp", "gps", "gal", "local", "private". New entries MAY be added to 8.2. Media Clock SDP Parameter
this registry according to well-known Specification Required policy
[RFC5226].
8.2. Media clock registry
The SDP attribute "mediaclk" defined by this document is registered The SDP attribute "mediaclk" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"): SDP Attribute ("att-field (both session and media level)"):
Attribute name: mediaclk Attribute name: mediaclk
Long form: Media clock source Long form: Media clock source
Type of name: att-field Type of name: att-field
Type of attribute: session and media level Type of attribute: session and media level
Subject to charset: No Subject to charset: No
Purpose: See section 5 of this document Purpose: See section 5 of this document
Reference: This document Reference: This document
Values: See this document and registrations below Values: See section 8.4 of this document
Figure 11
The attribute has an extensible parameter field and therefore a The attribute has an extensible parameter field and therefore a
registry for these parameters is required. This document creates an registry for these parameters is required. The new registry is
IANA registry called the Media Clock Source Parameters Registry. It defined in Section 8.4.
contains the three parameters defined in Figure 5: "sender",
"direct", "master", "slave" and "IEEE1722". New entries MAY be added 8.3. Timestamp Reference Clock Source Parameters Registry
to this registry according to well-known Specification Required
policy [RFC5226]. This document creates a new IANA sub-registry called the Timestamp
Reference Clock Source Parameters Registry, subordinate to the IANA
SDP Parameters registry.
Initial values for the Timestamp Reference Clock Source Parameters
registry are given below; future assignments are to be made through
the Specification Required policy [RFC5226].
+---------+-------------------------+--------------------------+
| Value | Long Name | Reference |
+---------+-------------------------+--------------------------+
| ntp | Network Time Protocol | This document, section 4 |
| ptp | Precision Time Protocol | This document, section 4 |
| gps | Global Position System | This document, section 4 |
| gal | Galileo | This document, section 4 |
| local | Local Clock | This document, section 4 |
| private | Private Clock | This document, section 4 |
+---------+-------------------------+--------------------------+
8.4. Media Clock Source Parameters Registry
This document creates a new IANA sub-registry called the Media Clock
Source Parameters registry, subordinate to the IANA SDP Parameters
registry.
Initial values for the Media Clock Source Parameters registry are
given below; future assignments are to be made through the
Specification Required policy [RFC5226].
+-----------+-------------------------------+-----------------------+
| Value | Long Name | Reference |
+-----------+-------------------------------+-----------------------+
| sender | Asynchronously Generated | This document, |
| | Media Clock | section 5 |
| direct | Direct-Referenced Media Clock | This document, |
| | | section 5 |
| master-id | Media Clock Master Identifier | This document, |
| | | section 5 |
| IEEE1722 | IEEE1722 Media Stream | This document, |
| | Identifier | section 5 |
+-----------+-------------------------------+-----------------------+
8.5. Source-level Attributes
[RFC5576] requires new source-level attributes to be registered with
the IANA registry named "att-field (source level)".
8.5.1. Source-level Reference Clock Attribute
The source-level SDP attribute "ts-refclk" defined by this document
is registered with the "att-field (source level)" IANA registry of
SDP Parameters according to Figure 10.
8.5.2. Source-level Media Clock Attribute
The source-level SDP attribute "mediaclk" defined by this document is
registered with the "att-field (source level)" IANA registry of SDP
Parameters according to Figure 11.
The source-level SDP attribute "master-id" defined by this document
is registered with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field (source level)"):
Attribute name: master-id
Long form: Media clock source
Type of name: att-field
Type of attribute: source level
Subject to charset: No
Purpose: See section 5 of this document
Reference: This document
Values: EUI48
Figure 12
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264,
2002. June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 21, line 34 skipping to change at page 26, line 24
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011. (CNAMEs)", RFC 6222, April 2011.
9.2. Informative References 9.2. Informative References
[AES11-2009] [AES11-2009]
Audio Engineering Society, "AES11-2009: AES recommended Audio Engineering Society, "AES11-2009: AES recommended
practice for digital audio engineering - Synchronization practice for digital audio engineering - Synchronization
of digital audio equipment in studio operations ", , of digital audio equipment in studio operations",
<http://www.aes.org/standards/>. <http://www.aes.org/standards/>.
[I-D.ietf-avtcore-idms] [I-D.ietf-avtcore-idms]
Brandenburg, R., Stokking, H., Deventer, O., Boronat, F., Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
Montagud, M., and K. Gross, "Inter-destination Media Montagud, M., and K. Gross, "Inter-destination Media
Synchronization using the RTP Control Protocol (RTCP)", Synchronization using the RTP Control Protocol (RTCP)",
draft-ietf-avtcore-idms-09 (work in progress), March 2013. draft-ietf-avtcore-idms-07 (work in progress),
October 2012.
[IEEE1588-2002] [IEEE1588-2002]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers, "1588-
"1588-2002 - IEEE Standard for a Precision Clock 2002 - IEEE Standard for a Precision Clock Synchronization
Synchronization Protocol for Networked Measurement and Protocol for Networked Measurement and Control Systems",
Control Systems", IEEE Std 1588-2002, 2002, <http:// IEEE Std 1588-2002, 2002, <http://standards.ieee.org/
standards.ieee.org/findstds/standard/1588-2002.html>. findstds/standard/1588-2002.html>.
[IEEE1588-2008] [IEEE1588-2008]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers, "1588-
"1588-2008 - IEEE Standard for a Precision Clock 2008 - IEEE Standard for a Precision Clock Synchronization
Synchronization Protocol for Networked Measurement and Protocol for Networked Measurement and Control Systems",
Control Systems", IEEE Std 1588-2008, 2008, <http:// IEEE Std 1588-2008, 2008, <http://standards.ieee.org/
standards.ieee.org/findstds/standard/1588-2008.html>. findstds/standard/1588-2008.html>.
[IEEE1722] [IEEE1722]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Layer 2 Transport Protocol for Time Sensitive Standard for Layer 2 Transport Protocol for Time Sensitive
Applications in a Bridged Local Area Network", , <http:// Applications in a Bridged Local Area Network", <http://
standards.ieee.org/findstds/standard/1722-2011.html>. standards.ieee.org/findstds/standard/1722-2011.html>.
[IEEE802.1AS-2011] [IEEE802.1AS-2011]
Institute of Electrical and Electronics Engineers, "Timing Institute of Electrical and Electronics Engineers, "Timing
and Synchronization for Time-Sensitive Applications in and Synchronization for Time-Sensitive Applications in
Bridged Local Area Networks", , <http://standards.ieee.org Bridged Local Area Networks", <http://standards.ieee.org/
/findstds/standard/802.1AS-2011.html>. findstds/standard/802.1AS-2011.html>.
[IEEE802.1BA-2011] [IEEE802.1BA-2011]
Institute of Electrical and Electronics Engineers, "Audio Institute of Electrical and Electronics Engineers, "Audio
Video Bridging (AVB) Systems", , <http:// Video Bridging (AVB) Systems", <http://standards.ieee.org/
standards.ieee.org/findstds/standard/802.1BA-2011.html>. findstds/standard/802.1BA-2011.html>.
[IS-GPS-200F] [IS-GPS-200F]
Global Positioning Systems Directorate, "Navstar GPS Space Global Positioning Systems Directorate, "Navstar GPS Space
Segment/Navigation User Segment Interfaces", September Segment/Navigation User Segment Interfaces",
2011. September 2011.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[SMPTE-318-1999] [SMPTE-318-1999]
Society of Motion Picture & Television Engineers, Society of Motion Picture & Television Engineers,
"Television and Audio - Synchronization of 59.94- or 50-Hz "Television and Audio - Synchronization of 59.94- or 50-Hz
Related Video and Audio Systems in Analog and Digital Related Video and Audio Systems in Analog and Digital
Areas - Reference Signals", , Areas - Reference Signals", <http://standards.smpte.org/>.
<http://standards.smpte.org/>.
URIs
[1] <http://www.ieee802.org/1/files/public/docs2007/
as-dolsen-time-accuracy-0407.pdf>
Authors' Addresses Authors' Addresses
Aidan Williams Aidan Williams
Audinate Audinate
Level 1, 458 Wattle St Level 1, 458 Wattle St
Ultimo, NSW 2007 Ultimo, NSW 2007
Australia Australia
Phone: +61 2 8090 1000 Phone: +61 2 8090 1000
 End of changes. 69 change blocks. 
203 lines changed or deleted 348 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/