draft-ietf-avtcore-clksrc-05.txt   draft-ietf-avtcore-clksrc-06.txt 
Audio/Video Transport Core A. Williams Audio/Video Transport Core A. Williams
Maintenance Audinate Maintenance Audinate
Internet-Draft K. Gross Internet-Draft K. Gross
Intended status: Standards Track AVA Networks Intended status: Standards Track AVA Networks
Expires: January 15, 2014 R. van Brandenburg Expires: March 14, 2014 R. van Brandenburg
H. Stokking H. Stokking
TNO TNO
July 14, 2013 September 10, 2013
RTP Clock Source Signalling RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-05 draft-ietf-avtcore-clksrc-06
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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 15, 2014. This Internet-Draft will expire on March 14, 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
skipping to change at page 3, line 19 skipping to change at page 3, line 19
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Timestamp Reference Clock Source Signalling . . . . . . . . . 6 4. Timestamp Reference Clock Source Signalling . . . . . . . . . 6
4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 6 4.1. Clock synchronization . . . . . . . . . . . . . . . . . . 6
4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 7 4.2. Identifying NTP Reference Clocks . . . . . . . . . . . . . 7
4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 7 4.3. Identifying PTP Reference Clocks . . . . . . . . . . . . . 7
4.4. Identifying Global Reference Clocks . . . . . . . . . . . 9 4.4. Identifying Global Reference Clocks . . . . . . . . . . . 9
4.5. Private Reference Clocks . . . . . . . . . . . . . . . . . 9 4.5. Private Reference Clocks . . . . . . . . . . . . . . . . . 9
4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . . 9 4.6. Local Reference Clocks . . . . . . . . . . . . . . . . . . 9
4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . . 9 4.7. Traceable Reference Clocks . . . . . . . . . . . . . . . . 9
4.8. SDP Signalling of Timestamp Reference Clock Source . . . . 9 4.8. SDP Signalling of Timestamp Reference Clock Source . . . . 9
4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 4.8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11
5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 13 5. Media Clock Source Signalling . . . . . . . . . . . . . . . . 13
5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13 5.1. Asynchronously Generated Media Clock . . . . . . . . . . . 13
5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 14 5.2. Direct-Referenced Media Clock . . . . . . . . . . . . . . 13
5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14 5.3. Stream-Referenced Media Clock . . . . . . . . . . . . . . 14
5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 15 5.4. SDP Signalling of Media Clock Source . . . . . . . . . . . 16
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19 6. Signalling Considerations . . . . . . . . . . . . . . . . . . 19
6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19 6.1. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 19
6.1.1. Indicating Support for Clock Source Signalling . . . . 20 6.1.1. Indicating Support for Clock Source Signalling . . . . 20
6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20 6.1.2. Timestamp Reference Clock . . . . . . . . . . . . . . 20
6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20 6.1.3. Media Clock . . . . . . . . . . . . . . . . . . . . . 20
6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21 6.2. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22 8.1. Reference Clock SDP Parameter . . . . . . . . . . . . . . 22
8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 22 8.2. Media Clock SDP Parameter . . . . . . . . . . . . . . . . 22
8.3. Timestamp Reference Clock Source Parameters Registry . . . 23 8.3. Timestamp Reference Clock Source Parameters Registry . . . 23
8.4. Media Clock Source Parameters Registry . . . . . . . . . . 24 8.4. Media Clock Source Parameters Registry . . . . . . . . . . 24
8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 24 8.5. Source-level Attributes . . . . . . . . . . . . . . . . . 25
8.5.1. Source-level Reference Clock Attribute . . . . . . . . 24 8.5.1. Source-level Timestamp Reference Clock Attribute . . . 25
8.5.2. Source-level Media Clock Attribute . . . . . . . . . . 24 8.5.2. Source-level Media Clock Attribute . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 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.
skipping to change at page 6, line 19 skipping to change at page 6, line 19
stream stream
SDP media stream : An RTP session potentially containing more than SDP media stream : An RTP session potentially containing more than
one RTP source. SDP media descriptions beginning with an "m"-line one RTP source. SDP media descriptions beginning with an "m"-line
define the parameters of an SDP media stream. define the parameters of an SDP media stream.
session level : Session level information applies to an entire session level : Session level information applies to an entire
multimedia session. In an SDP description, session-level multimedia session. In an SDP description, session-level
information appears before the first "m"-line. information appears before the first "m"-line.
source level : Source level information applies to a RTP media source level : Source level information applies to a specific RTP
stream Source-Specific Media Attributes in the Session Description media stream. Source-Specific Media Attributes in the Session
Protocol (SDP) [RFC5576] defines how source-level information is Description Protocol (SDP) [RFC5576] defines how source-level
included into an SDP session description. information is included into an SDP session description.
traceable time : A clock is considered to provide traceable time if traceable time : A clock is considered to provide traceable time if
it can be proven to be synchronised to International Atomic Time it can be proven to be synchronised to International Atomic Time
(TAI). Coordinated Universal Time (UTC) is a time standard (TAI). Coordinated Universal Time (UTC) is a time standard
synchronized to TAI. UTC is therefore also considered traceable synchronized to TAI. UTC is therefore also considered traceable
time once leap seconds have been taken unto account. GPS time once leap seconds have been taken unto account. GPS
[IS-GPS-200F] is commonly used to provide a TAI traceable time [IS-GPS-200F] is commonly used to provide a TAI traceable time
reference. Some network time synchronisation protocols (e.g. PTP reference. Some network time synchronisation protocols (e.g. PTP
[IEEE1588-2008], NTP) can explicitly indicate that the master [IEEE1588-2008], NTP) can explicitly indicate that the master
clock is providing a traceable time reference over the network. clock is providing a traceable time reference over the network.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
Two or more local clocks that are sufficiently synchronised will Two or more local clocks that are sufficiently synchronised will
produce timestamps for a given RTP event can be used as if they came produce timestamps for a given RTP event can be used as if they came
from the same clock. Providing they are sufficiently synchronised, from the same clock. Providing they are sufficiently synchronised,
timestamps produced in one RTP sender or receiver can be directly timestamps produced in one RTP sender or receiver can be directly
compared to a local clock in another RTP sender or receiver. compared to a local clock in another RTP sender or receiver.
The accuracy of synchronisation required is application dependent. The accuracy of synchronisation required is application dependent.
See Applications (Section 2) section for a discussion of applications See Applications (Section 2) section for a discussion of applications
and their corresponding requirements. To serve as a reference clock, and their corresponding requirements. To serve as a reference clock,
clocks must minimally be syntonised (exactly frequency matched) to clocks must minimally be syntonized (exactly frequency matched) to
one another. one another.
Sufficient synchronisation can typically be achieving by using a Sufficient synchronisation can typically be achieving by using a
network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to
synchronize all devices to a single master clock. synchronize all devices to a single master clock.
Another approach is to use clocks providing a global time reference Another approach is to use clocks providing a global time reference
(e.g. GPS, Galileo). This concept may be used in conjunction with (e.g. GPS, Galileo). This concept may be used in conjunction with
network time protocols as some protocols (e.g. PTP, NTP) allow network time protocols as some protocols (e.g. PTP, NTP) allow
master clocks to indicate explicitly that they are providing master clocks to indicate explicitly that they are providing
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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
synchronization source they choose and, in support of fault synchronization source they choose and, in support of fault
tolerance, may switch refence clock source while streaming. tolerance, may switch reference clock source while streaming.
The PTP protocols employ a distributed election protocol called the The PTP protocols employ a distributed election protocol called the
"Best Master Clock Algorithm" (BMCA) to determine the active clock "Best Master Clock Algorithm" (BMCA) to determine the active clock
master. The clock master choices available to BMCA can be restricted master. The clock master choices available to BMCA can be restricted
or biased by configuration parameters to influence the election or biased by configuration parameters to influence the election
process. In some systems it may be desirable to limit the number of 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 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
skipping to change at page 9, line 27 skipping to change at page 9, line 27
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. Local Reference Clocks 4.6. Local Reference Clocks
RFC 3550 allows senders and receivers to either use a local wallclock RFC 3550 allows senders and receivers to either use a local wall
reference for their NTP timestamps or, by setting the timestamp field clock reference for their NTP timestamps or, by setting the timestamp
to 0, to supply no timestamps at all. Both are common practice in field to 0, to supply no timestamps at all. Both are common practice
embedded RTP implementations. These clocks are identified as "local" in embedded RTP implementations. These clocks are identified as
and can only be assumed to be equivalent to clocks originating from "local" and can only be assumed to be equivalent to clocks
the same device. originating from the same device.
4.7. Traceable Reference Clocks 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.
skipping to change at page 10, line 29 skipping to change at page 10, line 29
(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. "refclk-sl" is used to describe a reference clock at the mechanisms.
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 General forms of usage:
source information.
refclk-sl = "a=ssrc:" integer SP timestamp-refclk session level: a=ts-refclk:<clksrc>
timestamp-refclk = "a=ts-refclk:" clksrc CRLF media level: a=ts-refclk:<clksrc>
clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext
ntp = "ntp=" ntp-server-addr source level: a=ssrc:<ssrc-id> ts-refclk:<clksrc>
ntp-server-addr = host [ ":" port ]
ntp-server-addr =/ "traceable"
ptp = "ptp=" ptp-version ":" ptp-server ABNF [RFC5234] grammar for the timestamp reference clock attribute:
ptp-version = "IEEE1588-2002" ; external references:
ptp-version =/ "IEEE1588-2008" POS-DIGIT = <See RFC 4566>
ptp-version =/ "IEEE802.1AS-2011" token = <See RFC 4566>
ptp-version =/ ptp-version-ext byte-string = <See RFC 4566>
ptp-version-ext = token DIGIT = <See RFC 5324>
HEXDIG = <See RFC 5324>
CRLF = <See RFC 5324>
hostport = <See RFC 3261, with revisions from RFC 5954>
ptp-server = ptp-gmid [":" ptp-domain] / "traceable" timestamp-refclk = "ts-refclk:" clksrc CRLF
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" clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext
gal = "gal" clksrc-ext = clksrc-param-name clksrc-param-value
local = "local" clksrc-param-name = token
private = "private" [ ":" "traceable" ] clksrc-param-value = ["=" byte-string ]
clksrc-ext = token ntp = "ntp=" ntp-server-addr
ntp-server-addr = hostport / "traceable"
host = hostname / IPv4address / IPv6reference ptp = "ptp=" ptp-version ":" ptp-server
hostname = *( domainlabel "." ) toplabel [ "." ] ptp-version = "IEEE1588-2002"
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum / "IEEE1588-2008"
domainlabel = alphanum / "IEEE802.1AS-2011"
/ alphanum *( alphanum / "-" ) alphanum / ptp-version-ext
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT ptp-version-ext = token
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT ptp-server = ptp-gmid [":" ptp-domain]
/ "traceable"
ptp-gmid = EUI64
ptp-domain = ptp-domain-name / ptp-domain-nmbr
; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-name = "domain-name=" 1*16ptp-domain-char
ptp-domain-char = %x21-7E
; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
ptp-domain-n1 = DIGIT ; 0-9
ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99
ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119
/ "12" %x30-37 ; 120-127
gps = "gps"
gal = "gal"
local = "local"
private = "private" [ ":traceable" ]
EUI64 = 7(2HEXDIG "-") 2HEXDIG
EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 1: Timestamp Reference Clock Source Signalling Figure 1: Timestamp Reference Clock Source Signalling
4.8.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
skipping to change at page 14, line 16 skipping to change at page 14, line 10
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.8). 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. Implementations SHOULD use a TAI timestamp reference clock
to avoid complications due to leap seconds. The NTP/RTP timestamp
mapping provided by RTCP SRs takes precedence over that provided by
the SDP, however the media clock rate implied by the SRs MUST be
consistent with the rate announced in the SDP.
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
skipping to change at page 14, line 51 skipping to change at page 14, line 49
distribution. In this case, the media clock is locally generated, distribution. In this case, the media clock is locally generated,
often by a crystal oscillator and is not locked to a timestamp often by a crystal oscillator and is not locked to a timestamp
reference clock. reference clock.
To support this architecture across a network, a master clock To support this architecture across a network, a master clock
identifier is associated with an RTP media stream carrying media identifier is associated with an RTP media stream carrying media
clock timing information from a master device. The master clock clock timing information from a master device. The master clock
identifier represents a media clock source in the master device. identifier represents a media clock source in the master device.
Slave devices in turn associate the master media clock identifier Slave devices in turn associate the master media clock identifier
with streams they transmit, signalling the synchronisation with streams they transmit, signalling the synchronisation
relationship between the master and slave devices. relationship between the master and the transmitter's media clock.
Slave devices recover media clock timing from the clock master Slave devices recover media clock timing from the clock master
stream, using it to synchronise the slave media clock with the stream, using it to synchronise the slave media clock with the
master. Timestamps in the master clock RTP media stream are taken master. Timestamps in the master clock RTP media stream are taken
using the timestamp reference clock shared by the master and slave using the timestamp reference clock shared by the master and slave
devices. The timestamps communicate information about media clock devices. The timestamps communicate information about media clock
timing (rate, phase) from the master to the slave devices. timing (rate, phase) from the master to the slave devices.
Timestamps are communicated in the usual RTP fashion via RTCP SRs, or Timestamps are communicated in the usual RTP fashion via RTCP SRs, or
via the RFC6051 [RFC6051] header extension. The stream media format via the RFC6051 [RFC6051] header extension. The stream media format
may indicate other clock information, such as the nominal rate. may indicate other clock information, such as the nominal rate.
Note that slaving of a device media clock to a master device does not Note that slaving of a device media clock to a master device does not
affect the usual RTP lip sync / time alignment algorithms. Time affect the usual RTP lip sync / time alignment algorithms. Time
aligned playout of two or more RTP sources still relies upon NTP aligned playout of two or more RTP sources still relies upon NTP
timestamps supplied via RTCP SRs or by the RFC6051 timestamp header timestamps supplied via RTCP SRs or by the RFC6051 timestamp header
extension. extension.
In a given system, master clock identifiers must be unique. Such In a given system, master clock identifiers must uniquely identify a
identifiers MAY be manually configured, however 17 octet string single media clock source. Such identifiers MAY be manually
identifiers SHOULD be generated according to the "short-term configured, however identifiers SHOULD be generated according to the
persistent RTCP CNAME" algorithm as described in RFC6222 [RFC6222]. "short-term persistent RTCP CNAME" algorithm as described in RFC6222
[RFC6222] or RFC6222bis [I-D.ietf-avtcore-6222bis]. Master clock
identifiers not already in base64 format MUST be encoded as a base64
strings when used in SDP. Although the RTCP CNAME algorithm is used
to generate the master clock identifier, it is used to tag RTP
sources in SDP descriptions and does not appear in RTCP as a CNAME.
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 [RFC5576] and master clock identifier. If master clock by an SSRC [RFC5576] and master clock identifier. An RTP stream that
identifiers are declared at the media or session level, all RTP provides media clock timing directly from a reference media clock
sources at or below the level of declaration MUST provide equivalent (e.g. internal crystal, audio word clock or video blackburst signal)
timing to a slave receiver. SHOULD tag the stream as a master clock source using the "src:"
prefix. 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:<master-media-clock-stream-ssrc> mediaclk:master-id=<media- a=ssrc:<ssrc> mediaclk:id=src:<media-clktag> sender
clock-master-id>
An RTP media sender indicates that it is slaved to a media clock a=mediaclk:id=src:<media-clktag> sender
master via a clock master identifier:
a=mediaclk:master-id=<media-clock-master-id> A transmitted RTP stream slaved to media clock master is signaled by
including master clock identifier:
a=mediaclk:id=<media-clktag> sender
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>
An RTP media sender may gateway IEEE 1722 media clock timing to RTP:
a=mediaclk:id=src:<media-clktag> IEEE1722=<StreamID>
5.4. SDP Signalling of Media Clock Source 5.4. SDP Signalling of Media Clock Source
Specification of the media clock source may be at any or all levels Specification of the media clock source may be at any or all levels
(session, media or source) of an SDP description (see level (session, media or source) of an SDP description (see level
definitions (Section 3) earlier in this document for more definitions (Section 3) earlier in this document for more
information). information).
Media clock source signalling included at session level provides Media clock source signalling included at session level provides
default parameters for all RTP sessions and sources in the session default parameters for all RTP sessions and sources in the session
description. More specific signalling included at the media level description. More specific signalling included at the media level
skipping to change at page 16, line 23 skipping to change at page 16, line 35
Media clock source signalling may be present or absent on a per- Media clock source signalling may be present or absent on a per-
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 General forms of usage:
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
clk-master-id = "mediaclk:master-id=" master-id
timestamp-mediaclk-sl = "a:ssrc" integer SP timestamp-mediaclk
timestamp-mediaclk = "a=mediaclk:" mediaclock
mediaclock = sender / refclk / streamid / mediaclock-ext
sender = "sender" sender-ext
sender-ext = token session level: a=mediaclk:<mediaclock>
refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] media level: a=mediaclk:<mediaclock>
rate = [ SP "rate=" integer "/" integer ] source level: a=ssrc:<ssrc-id> mediaclk:<mediaclock>
ABNF [RFC5234] grammar for the media clock reference attribute:
; external references:
integer = <See RFC 4566>
token = <See RFC 4566>
byte-string = <See RFC 4566>
base64 = <See RFC 4566>
SP = <See RFC 5234>
DIGIT = <See RFC 5234>
HEXDIG = <See RFC 5234>
direct-ext = token media-clksrc = "mediaclk:" [media-clkid SP] mediaclock
streamid = "master-id=" master-id media-clkid = "id=" [ "src:" ] media-clktag
streamid =/ "IEEE1722=" avb-stream-id media-clktag = base64
streamid =/ streamid-ext
master-id = EUI48 mediaclock = sender / direct / ieee1722-streamid / mediaclock-ext
avb-stream-id = EUI64
EUI48 = 5(2HEXDIG ":") 2HEXDIG mediaclock-ext = mediaclock-param-name mediaclock-param-value
EUI64 = 7(2HEXDIG ":") 2HEXDIG mediaclock-param-name = token
mediaclock-param-value = [ "=" byte-string ]
streamid-ext = token sender = "sender"
direct = "direct" [ "=" 1*DIGIT ] [SP rate]
rate = "rate=" integer "/" integer
mediaclock-ext = token [SP byte-string] ieee1722-streamid = "IEEE1722=" avb-stream-id
avb-stream-id = EUI64
EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 5: Media Clock Source Signalling Figure 5: Media Clock Source Signalling
5.5. Examples 5.5. Examples
Figure 6 shows an example SDP description 8 channels of 24-bit, 48 Figure 6 shows an example SDP description 8 channels of 24-bit, 48
kHz audio transmitted as a multicast stream. Media clock is derived kHz audio transmitted as a multicast stream. Media clock is derived
directly from an IEEE 1588-2008 reference. directly from an IEEE 1588-2008 reference.
v=0 v=0
skipping to change at page 18, line 47 skipping to change at page 18, line 47
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/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:master-id=00:60:2b:20:12:1f a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender
Figure 8: RTP stream with media clock slaved to a master device Figure 8: RTP stream with media clock slaved to a master
Figure 9 shows the same 48 kHz audio transmission from Figure 6 with Figure 9 shows the same 48 kHz audio transmission from Figure 6 with
media clock derived from an IEEE 1722 AVB stream. media clock derived from an IEEE 1722 AVB stream.
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
skipping to change at page 19, line 28 skipping to change at page 19, line 28
6. Signalling Considerations 6. Signalling Considerations
Signaling of timestamp reference clock source (Section 4.8) and media Signaling of timestamp reference clock source (Section 4.8) and 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 SHOULD include both reference clock signalling and A description SHOULD include both reference clock signalling and
media clock signalling. If no reference clock is avaialble, this media clock signalling. If no reference clock is available, this
SHOULD be signalled as a local reference (Section 4.6). SHOULD be signalled as a local reference (Section 4.6).
When no media clock signalling is present, an asynchronous media When no media clock signalling is present, an asynchronous media
clock (Section 5.1) MUST be assumed. When no reference clock clock (Section 5.1) MUST be assumed. When no reference clock
signalling is present, a local reference clock (Section 4.6) MUST be signalling is present, a local reference clock (Section 4.6) MUST be
assumed. assumed.
If a reference clock is not signalled or a local reference is If a reference clock is not signalled or a local reference is
specified, the corresponding media clock may be established as rate specified, the corresponding media clock may be established as rate
synchronised with no assurance of time synchronisation. synchronised with no assurance of time synchronisation.
skipping to change at page 21, line 14 skipping to change at page 21, line 14
SHOULD be included in the rejection. 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]. Time Streaming Protocol (RTSP) [RFC2326].
Devices using published descriptions to join sessions SHOULD assess Devices using published descriptions to join sessions SHOULD assess
their synchronization compatiblity with the described session based their synchronization compatibility with the described session based
on the clock source signaling and SHOULD NOT attempt to join a on the clock source signaling and SHOULD NOT attempt to join a
session with incompatible reference or media clocks. 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
skipping to change at page 22, line 17 skipping to change at page 22, line 17
defines a second new IANA registry subordinate to the IANA SDP defines a second new IANA registry subordinate to the IANA SDP
Parameters registry: the Timestamp Reference Clock Source Parameters Parameters registry: the Timestamp Reference Clock Source Parameters
Registry. Within this new registry, this document defines an initial Registry. Within this new registry, this document defines an initial
six parameters. six parameters.
8.1. Reference Clock SDP Parameter 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 (both session and media level)"): SDP Attributes ( "att-field (both session and media level)" &
"att-field (source 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
skipping to change at page 23, line 5 skipping to change at page 23, line 5
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 new registry is registry for these parameters is required. This new registry is
defined in Section 8.3. defined in Section 8.3.
8.2. Media Clock SDP Parameter 8.2. Media Clock SDP Parameter
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 (both session and media level)"): SDP Attributes ( "att-field (both session and media level)" &
"att-field (source 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, media and source 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 section 8.4 of this document Values: See section 8.4 of this document
Figure 11 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. The new registry is registry for these parameters is required. The new registry is
defined in Section 8.4. defined in Section 8.4.
8.3. Timestamp Reference Clock Source Parameters Registry 8.3. Timestamp Reference Clock Source Parameters Registry
This document creates a new IANA sub-registry called the Timestamp This document creates a new IANA sub-registry called the Timestamp
Reference Clock Source Parameters Registry, subordinate to the IANA Reference Clock Source Parameters Registry, subordinate to the IANA
SDP Parameters registry. SDP Parameters registry. Each entry in the Timestamp Reference Clock
Source Parameters Registry contains:
Name: Token used in the SDP description (clksrc-param-name)
Long name: Descriptive name for the timestamp reference clock source
Reference: Reference to the document describing the SDP token
(clksrc-param-name) and syntax for the optional value associated
with the token (mediaclock-param-value)
Initial values for the Timestamp Reference Clock Source Parameters Initial values for the Timestamp Reference Clock Source Parameters
registry are given below; future assignments are to be made through registry are given below.
the Specification Required policy [RFC5226].
Future assignments are to be made through the Specification Required
policy [RFC5226]. The Name field in the table corresponds to a new
value corresponding to clksrc-param-name. The Reference must specify
a syntax corresponding to clksrc-param-value.
+---------+-------------------------+--------------------------+ +---------+-------------------------+--------------------------+
| Value | Long Name | Reference | | Name | Long Name | Reference |
+---------+-------------------------+--------------------------+ +---------+-------------------------+--------------------------+
| ntp | Network Time Protocol | This document, section 4 | | ntp | Network Time Protocol | This document, section 4 |
| ptp | Precision Time Protocol | This document, section 4 | | ptp | Precision Time Protocol | This document, section 4 |
| gps | Global Position System | This document, section 4 | | gps | Global Position System | This document, section 4 |
| gal | Galileo | This document, section 4 | | gal | Galileo | This document, section 4 |
| local | Local Clock | This document, section 4 | | local | Local Clock | This document, section 4 |
| private | Private Clock | This document, section 4 | | private | Private Clock | This document, section 4 |
+---------+-------------------------+--------------------------+ +---------+-------------------------+--------------------------+
8.4. Media Clock Source Parameters Registry 8.4. Media Clock Source Parameters Registry
This document creates a new IANA sub-registry called the Media Clock This document creates a new IANA sub-registry called the Media Clock
Source Parameters registry, subordinate to the IANA SDP Parameters Source Parameters registry, subordinate to the IANA SDP Parameters
registry. registry. Each entry in the Media Clock Source Parameters Registry
contains:
Name: Token used in the SDP description (mediaclock-param-name)
Long name: Descriptive name for the media clock source type
Reference: Reference to the document describing the SDP token
(mediaclock-param-name) and syntax for the optional value
associated with the token (mediaclock-param-value)
Initial values for the Media Clock Source Parameters registry are Initial values for the Media Clock Source Parameters registry are
given below; future assignments are to be made through the given below.
Specification Required policy [RFC5226].
+-----------+-------------------------------+-----------------------+ Future assignments are to be made through the Specification Required
| Value | Long Name | Reference | policy [RFC5226]. The Name field in the table corresponds to a new
+-----------+-------------------------------+-----------------------+ value corresponding to mediaclock-param-name. The Reference must
| sender | Asynchronously Generated | This document, | specify a syntax corresponding to mediaclock-param-value.
| | Media Clock | section 5 |
| direct | Direct-Referenced Media Clock | This document, | +----------+--------------------------------+-----------------------+
| | | section 5 | | Name | Long Name | Reference |
| master-id | Media Clock Master Identifier | This document, | +----------+--------------------------------+-----------------------+
| | | section 5 | | sender | Asynchronously Generated Media | This document, |
| IEEE1722 | IEEE1722 Media Stream | This document, | | | Clock | section 5 |
| | Identifier | section 5 | | direct | Direct-Referenced Media Clock | This document, |
+-----------+-------------------------------+-----------------------+ | | | section 5 |
| IEEE1722 | IEEE1722 Media Stream | This document, |
| | Identifier | section 5 |
+----------+--------------------------------+-----------------------+
8.5. Source-level Attributes 8.5. Source-level Attributes
[RFC5576] requires new source-level attributes to be registered with [RFC5576] requires new source-level attributes to be registered with
the IANA registry named "att-field (source level)". the IANA registry named "att-field (source level)".
8.5.1. Source-level Reference Clock Attribute 8.5.1. Source-level Timestamp Reference Clock Attribute
The source-level SDP attribute "ts-refclk" defined by this document The source-level SDP attribute "ts-refclk" defined by this document
is registered with the "att-field (source level)" IANA registry of is registered with the "att-field (source level)" IANA registry of
SDP Parameters according to Figure 10. SDP Parameters according to Figure 10.
8.5.2. Source-level Media Clock Attribute 8.5.2. Source-level Media Clock Attribute
The source-level SDP attribute "mediaclk" defined by this document is The source-level SDP attribute "mediaclk" defined by this document is
registered with the "att-field (source level)" IANA registry of SDP registered with the "att-field (source level)" IANA registry of SDP
Parameters according to Figure 11. Parameters according to Figure 11.
The source-level SDP attribute "master-id" defined by this document 9. References
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 9.1. Normative References
Reference: This document [I-D.ietf-avtcore-6222bis]
Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06
(work in progress), July 2013.
Values: EUI48 [IEEE1588-2002]
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>.
Figure 12 [IEEE1588-2008]
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>.
9. References [IEEE1722]
Institute of Electrical and Electronics Engineers, "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>.
9.1. Normative References [IEEE802.1AS-2011]
Institute of Electrical and Electronics Engineers, "Timing
and Synchronization for Time-Sensitive Applications in
Bridged Local Area Networks", <http://standards.ieee.org/
findstds/standard/802.1AS-2011.html>.
[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,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
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, with Session Description Protocol (SDP)", RFC 3264,
June 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.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Capability Negotiation", RFC 5939, September 2010. Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, November 2010.
[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-07 (work in progress), draft-ietf-avtcore-idms-12 (work in progress), July 2013.
October 2012.
[IEEE1588-2002]
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>.
[IEEE1588-2008]
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>.
[IEEE1722]
Institute of Electrical and Electronics Engineers, "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>.
[IEEE802.1AS-2011]
Institute of Electrical and Electronics Engineers, "Timing
and Synchronization for Time-Sensitive Applications in
Bridged Local Area Networks", <http://standards.ieee.org/
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://standards.ieee.org/ Video Bridging (AVB) Systems", <http://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", Segment/Navigation User Segment Interfaces",
September 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 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Time Protocol Version 4: Protocol and Algorithms A., Peterson, J., Sparks, R., Handley, M., and E.
Specification", RFC 5905, June 2010. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 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", <http://standards.smpte.org/>. Areas - Reference Signals", <http://standards.smpte.org/>.
URIs URIs
[1] <http://www.ieee802.org/1/files/public/docs2007/ [1] <http://www.ieee802.org/1/files/public/docs2007/
 End of changes. 67 change blocks. 
195 lines changed or deleted 223 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/