doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc7273.txt b/doc/rfc/rfc7273.txt
new file mode 100644
index 0000000..42e8ed1
--- /dev/null
+++ b/doc/rfc/rfc7273.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       A. Williams
+Request for Comments: 7273                                      Audinate
+Category: Standards Track                                       K. Gross
+ISSN: 2070-1721                                             AVA Networks
+                                                      R. van Brandenburg
+                                                             H. Stokking
+                                                                     TNO
+                                                               June 2014
+
+
+                      RTP Clock Source Signalling
+
+Abstract
+
+   NTP format timestamps are used by several RTP protocols for
+   synchronisation and statistical measurements.  This memo specifies
+   Session Description Protocol (SDP) signalling that identifies
+   timestamp reference clock sources and SDP signalling that identifies
+   the media clock sources in a multimedia session.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7273.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Williams, et al.             Standards Track                    [Page 1]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Timestamp Reference Clock Source Signalling . . . . . . . . .   5
+     4.1.  Clock Synchronisation . . . . . . . . . . . . . . . . . .   5
+     4.2.  Identifying NTP Reference Clocks  . . . . . . . . . . . .   6
+     4.3.  Identifying PTP Reference Clocks  . . . . . . . . . . . .   6
+     4.4.  Identifying Global Reference Clocks . . . . . . . . . . .   8
+     4.5.  Private Reference Clocks  . . . . . . . . . . . . . . . .   8
+     4.6.  Local Reference Clocks  . . . . . . . . . . . . . . . . .   8
+     4.7.  Traceable Reference Clocks  . . . . . . . . . . . . . . .   8
+     4.8.  SDP Signalling of Timestamp Reference Clock Source  . . .   9
+       4.8.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  11
+   5.  Media Clock Source Signalling . . . . . . . . . . . . . . . .  12
+     5.1.  Asynchronously Generated Media Clock  . . . . . . . . . .  12
+     5.2.  Direct-Referenced Media Clock . . . . . . . . . . . . . .  12
+     5.3.  Stream-Referenced Media Clock . . . . . . . . . . . . . .  14
+     5.4.  SDP Signalling of Media Clock Source  . . . . . . . . . .  15
+     5.5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  17
+   6.  Signalling Considerations . . . . . . . . . . . . . . . . . .  19
+     6.1.  Usage in Offer/Answer . . . . . . . . . . . . . . . . . .  19
+       6.1.1.  Indicating Support for Clock Source Signalling  . . .  20
+       6.1.2.  Timestamp Reference Clock . . . . . . . . . . . . . .  20
+       6.1.3.  Media Clock . . . . . . . . . . . . . . . . . . . . .  20
+     6.2.  Usage Outside of Offer/Answer . . . . . . . . . . . . . .  21
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
+     8.1.  Reference Clock SDP Parameter . . . . . . . . . . . . . .  22
+     8.2.  Media Clock SDP Parameter . . . . . . . . . . . . . . . .  23
+     8.3.  Timestamp Reference Clock Source Parameters Registry  . .  23
+     8.4.  Media Clock Source Parameters Registry  . . . . . . . . .  24
+     8.5.  Source-Level Attributes . . . . . . . . . . . . . . . . .  25
+       8.5.1.  Source-Level Timestamp Reference Clock Attribute  . .  25
+       8.5.2.  Source-Level Media Clock Attribute  . . . . . . . . .  25
+   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  25
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  27
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                    [Page 2]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+1.  Introduction
+
+   RTP protocols use NTP format timestamps to facilitate multimedia
+   session synchronisation and to provide estimates of round-trip time
+   (RTT) and other statistical parameters.
+
+   Information about media clock timing exchanged in NTP format
+   timestamps may come from a clock that is synchronised to a global
+   time reference, but this cannot be assumed, nor is there a
+   standardised mechanism available to indicate that timestamps are
+   derived from a common reference clock.  Therefore, RTP
+   implementations typically assume that NTP timestamps are taken using
+   unsynchronised clocks and must compensate for absolute time
+   differences and rate differences.  Without a shared reference clock,
+   RTP can time align flows from the same source at a given receiver
+   using relative timing; however, tight synchronisation between two or
+   more different receivers (possibly with different network paths) or
+   between two or more senders is not possible.
+
+   High performance AV systems often use a reference media clock
+   distributed to all devices in the system.  The reference media clock
+   may be distinct from the reference clock used to provide timestamps.
+   A reference media clock may be provided along with an audio or video
+   signal interface, or via a dedicated clock signal (e.g., genlock
+   [SMPTE-318M-1999] or audio word clock [AES11-2009]).  If sending and
+   receiving media clocks are known to be synchronised to a common
+   reference clock, performance can be improved by minimising buffering
+   and avoiding rate conversion.
+
+   This specification defines SDP signalling of timestamp reference
+   clock sources and media reference clock sources.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Applications
+
+   Timestamp reference clock source and media clock signalling benefit
+   applications requiring synchronised media capture or playout and low
+   latency operation.
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                    [Page 3]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   Examples include, but are not limited to:
+
+   Social TV:  "Inter-Destination Media Synchronization (IDMS) Using the
+      RTP Control Protocol (RTCP)" [RFC7272] defines social TV as the
+      combination of media content consumption by two or more users at
+      different devices and locations and real-time communication
+      between those users.  An example of social TV is where two or more
+      users are watching the same television broadcast at different
+      devices and/or locations while communicating with each other using
+      text, audio, and/or video.  A skew in the media playout of the two
+      or more users can have adverse effects on their experience.  A
+      well-known use case here is one friend experiencing a goal in a
+      football match well before or after other friends.
+
+   Video Walls:  A video wall consists of multiple computer monitors,
+      video projectors, or television sets tiled together contiguously
+      or overlapped in order to form one large screen.  Each of the
+      screens reproduces a portion of the larger picture.  In some
+      implementations, each screen or projector may be individually
+      connected to the network and receive its portion of the overall
+      image from a network-connected video server or video scaler.
+      Screens are refreshed at 50 or 60 hertz or potentially faster.  If
+      the refresh is not synchronised, the effect of multiple screens
+      acting as one is broken.
+
+   Networked Audio:  Networked loudspeakers, amplifiers, and analogue
+      input/output (I/O) devices transmitting or receiving audio signals
+      via RTP can be connected to various parts of a building or campus
+      network.  Such situations can, for example, be found in large
+      conference rooms, legislative chambers, classrooms (especially
+      those supporting distance learning), and other large-scale
+      environments such as stadiums.  Since humans are more sensitive to
+      differences in audio delay, this use case needs even more accuracy
+      than the video wall use case.  Depending on the exact application,
+      the need for accuracy can then be in the range of microseconds
+      [Olsen].
+
+   Sensor Arrays:  Sensor arrays contain many synchronised measurement
+      elements producing signals that are then combined to form an
+      overall measurement.  Accurate capture of the phase relationships
+      between the various signals arriving at each element of the array
+      is critically important for proper operation.  Examples include
+      towed or fixed sonar arrays, seismic arrays, and phased arrays
+      used in radar applications, for instance.
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                    [Page 4]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+3.  Definitions
+
+   The following definitions are used in this document:
+
+   media level:  Media-level information applies to a single SDP media
+      stream.  In an SDP description, media-level information appears
+      after each "m"-line.
+
+   multimedia session:  A set of multimedia senders and receivers as
+      well as the data streams flowing from senders to receivers.  SDP
+      [RFC4566] describes multimedia sessions.
+
+   RTP media stream:  A single stream of RTP packets identified by an
+      RTP Synchronisation Source (SSRC).
+
+   RTP sender:  The device generating an associated RTP media stream.
+
+   session level:  Session-level information applies to an entire
+      multimedia session.  In an SDP description, session-level
+      information appears before the first "m"-line.
+
+   source level:  Source-level information applies to a specific RTP
+      media stream.  "Source-Specific Media Attributes in the Session
+      Description Protocol (SDP)" [RFC5576] defines how source-level
+      information is included into an SDP session description.
+
+   traceable time:  A clock is considered to provide traceable time if
+      it can be proven to be synchronised to International Atomic Time
+      (TAI).  Coordinated Universal Time (UTC) is a time standard
+      synchronised to TAI.  UTC is, therefore, also considered traceable
+      time once leap seconds have been taken into account.  GPS
+      [IS-GPS-200F] is commonly used to provide a TAI traceable time
+      reference.  Some network time synchronisation protocols (e.g.,
+      Precision Time Protocol (PTP) [IEEE1588-2008] and NTP) can
+      explicitly indicate that the master clock is providing a traceable
+      time reference over the network.
+
+4.  Timestamp Reference Clock Source Signalling
+
+   The NTP format timestamps used by RTP are taken by reading a local
+   real-time clock at the sender or receiver.  This local clock may be
+   synchronised to another clock (time source) by some means, or it may
+   be unsynchronised.  A variety of methods are available to synchronise
+   local clocks to a reference time source, including network time
+   protocols (e.g., NTP [RFC5905] and PTP [IEEE1588-2008]) and radio
+   clocks (e.g., GPS [IS-GPS-200F]).
+
+
+
+
+
+Williams, et al.             Standards Track                    [Page 5]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   The following sections describe and define SDP signalling, indicating
+   whether and how the local timestamping clock in an RTP sender or
+   receiver is synchronised to a reference clock.
+
+4.1.  Clock Synchronisation
+
+   Two or more local clocks that are sufficiently synchronised will
+   produce timestamps for a given RTP event that can be used as if they
+   came from the same clock.  Timestamps produced in one RTP sender or
+   receiver can be directly compared to a local clock in another RTP
+   sender or receiver.
+
+   The accuracy of synchronisation required is application dependent.
+   See "Applications" (Section 2) for a discussion of applications and
+   their corresponding requirements.  To serve as a reference clock,
+   clocks must minimally be "syntonised" (exactly frequency matched) to
+   one another.
+
+   Sufficient synchronisation can typically be achieved by using a
+   network time protocol (e.g., NTP, 802.1AS, and IEEE 1588-2008) to
+   synchronise all devices to a single master clock.
+
+   Another approach is to use clocks providing a global time reference
+   (e.g., GPS, Galileo, and GLONASS).  This concept may be used in
+   conjunction with network time protocols as some protocols (e.g., PTP
+   and NTP) allow master clocks to indicate explicitly that they are
+   providing traceable time.
+
+4.2.  Identifying NTP Reference Clocks
+
+   A single NTP server is identified by a hostname (or IP address) and
+   an optional port number.  If the port number is not indicated, it is
+   assumed to be the standard NTP port (123).
+
+   Two or more NTP servers MAY be listed at the same level in the
+   session description to indicate that all of the listed servers
+   deliver the same reference time and may be used interchangeably.  RTP
+   senders and receivers are assured proper synchronisation regardless
+   of which server they choose and, in support of fault tolerance, may
+   switch servers while streaming.
+
+4.3.  Identifying PTP Reference Clocks
+
+   The Precision Time Protocol (PTP) as standardised in IEEE 1588
+   provides a shared reference clock in a network.  IEEE 1588 provides
+   sub-microsecond synchronisation between devices on a LAN and
+   typically locks within seconds at startup.  With support from
+   Ethernet switches, IEEE 1588 protocols can achieve nanosecond timing
+
+
+
+Williams, et al.             Standards Track                    [Page 6]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   accuracy in LANs.  Network interface chips and cards supporting
+   hardware timestamping of timing-critical protocol messages are also
+   available.
+
+   Three flavours of IEEE 1588 are in use today:
+
+   o  IEEE 1588-2002 [IEEE1588-2002]: the original "Standard for a
+      Precision Clock Synchronization Protocol for Networked Measurement
+      and Control Systems".  This is also known as IEEE1588v1 or PTPv1.
+
+   o  IEEE 1588-2008 [IEEE1588-2008]: the second version of the
+      "Standard for a Precision Clock Synchronization Protocol for
+      Networked Measurement and Control Systems".  This is a revised
+      version of the original IEEE1588-2002 standard and is also known
+      as IEEE1588v2 or PTPv2.  IEEE 1588-2008 is not protocol compatible
+      with IEEE 1588-2002.
+
+   o  IEEE 802.1AS [IEEE802.1AS-2011]: "Timing and Synchronization for
+      Time Sensitive Applications in Bridged Local Area Networks".  This
+      is a profile of IEEE 1588-2008 that is Layer 2 only and is for use
+      in Audio/Video Bridged LANs as described in IEEE 802.1BA-2011
+      [IEEE802.1BA-2011].
+
+   Each IEEE 1588 clock is identified by a 64-bit Extended Unique
+   Identifier (EUI-64) called a "ClockIdentity".  A slave clock using
+   one of the IEEE 1588 family of network time protocols acquires the
+   ClockIdentity of the grandmaster clock that is the ultimate source of
+   timing information for the network.  A boundary clock, which is
+   itself slaved to another boundary clock, or the grandmaster passes
+   the grandmaster ClockIdentity through to its slaves.
+
+   Several instances of the IEEE 1588 protocol may operate independently
+   on a single network, forming distinct PTP domains, each of which may
+   have a different grandmaster clock.  As the IEEE 1588 standards have
+   evolved, the definition of PTP domains has changed.  IEEE 1588-2002
+   identifies protocol subdomains by a textual name, but IEEE 1588-2008
+   identifies protocol domains using a numeric domain number. 802.1AS is
+   a Layer 2 profile of IEEE 1588-2008 supporting a single numeric clock
+   domain (0).
+
+   When PTP domains are signalled via SDP, senders and receivers SHOULD
+   check that both grandmaster ClockIdentity and the PTP domain match
+   when determining clock equivalence.
+
+   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
+   candidate grandmaster clocks for the domain or deliver the same
+   reference time and may be used interchangeably.  RTP senders and
+
+
+
+Williams, et al.             Standards Track                    [Page 7]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   receivers are assured proper synchronisation regardless of which
+   synchronisation source they choose and, in support of fault
+   tolerance, may switch the reference clock source while streaming.
+
+   The PTP protocols employ a distributed election protocol called the
+   "Best Master Clock Algorithm" (BMCA) to determine the active clock
+   master.  The clock master choices available to BMCA can be restricted
+   or biased by configuration parameters to influence the election
+   process.  In some systems, it may be desirable to limit the number of
+   possible PTP clock masters to avoid the need to re-signal timestamp
+   reference clock sources when the clock master changes.
+
+4.4.  Identifying Global Reference Clocks
+
+   Global reference clocks provide a source of traceable time, typically
+   via a hardware radio receiver interface.  Examples include GPS,
+   Galileo, and GLONASS.  Apart from the name of the reference clock
+   system, no further identification is required.
+
+4.5.  Private Reference Clocks
+
+   In other systems, all RTP senders and receivers may use a timestamp
+   reference clock that is not provided by one of the methods listed
+   above.  Examples may include the reference time information provided
+   by digital television or cellular services.  These sources are
+   identified as "private" reference clocks.  All RTP senders and
+   receivers in a session using a private reference clock are assumed to
+   have a mechanism outside this specification for determining whether
+   their timestamp reference clocks are equivalent.
+
+4.6.  Local Reference Clocks
+
+   [RFC3550] allows senders and receivers to either use a local
+   wallclock reference for their NTP timestamps or, by setting the
+   timestamp field to 0, supply no timestamps at all.  Both are common
+   practice in embedded RTP implementations.  These clocks are
+   identified as "local" and can, at best, 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
+   is known to be delivering traceable time, provided adjustments are
+   made for differing epochs, timezones, and leap seconds.  Timestamps
+   taken using clocks synchronised to a traceable time source can be
+   directly compared even if the clocks are synchronised to different
+   sources or via different mechanisms.
+
+
+
+
+Williams, et al.             Standards Track                    [Page 8]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   Marking a clock as traceable allows additional information (e.g., IP
+   addresses, PTP master identifiers, and the like) to be omitted from
+   the SDP since any traceable clock available at the answerer is
+   considered to be an appropriate timestamp reference clock.  For
+   example, an offerer could specify ts-refclk:ntp=/traceable/ and the
+   answerer could use GPS as a reference clock since GPS is a source of
+   traceable time.
+
+4.8.  SDP Signalling of Timestamp Reference Clock Source
+
+   Specification of the timestamp reference clock source may be at any
+   or all levels (session, media, or source) of an SDP description (see
+   level definitions in Section 3 earlier in this document for more
+   information).
+
+   Timestamp reference clock source signalling included at the session
+   level provides default parameters for all RTP sessions and sources in
+   the session description.  More specific signalling included at the
+   media level overrides session-level signalling.  More specific
+   signalling included at the source level overrides media-level
+   signalling.
+
+   If timestamp reference clock source signalling is included anywhere
+   in an SDP description, it must be properly defined for all levels in
+   the description.  This may simply be achieved by providing default
+   signalling at the session level.
+
+   Timestamp reference clock parameters may be repeated at a given level
+   (i.e., for a session or source) to provide information about
+   additional servers or clock sources.  If the attribute is repeated at
+   a given level, all clocks described at that level are assumed to be
+   equivalent.  Traceable time sources MUST NOT be mixed with non-
+   traceable time sources at any given level.
+
+   Note that clock source parameters may change from time to time, for
+   example, as a result of a PTP grandmaster election.  SIP [RFC3261]
+   supports the re-signalling of updated SDP information; however, other
+   protocols may require additional notification mechanisms.
+
+   General forms of usage:
+
+   session level:  a=ts-refclk:<clksrc>
+
+   media level:  a=ts-refclk:<clksrc>
+
+   source level:  a=ssrc:<ssrc-id> ts-refclk:<clksrc>
+
+
+
+
+
+Williams, et al.             Standards Track                    [Page 9]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   ABNF [RFC5234] grammar for the timestamp reference clock attribute:
+
+   ; external references:
+   POS-DIGIT   = <See RFC 4566>
+   token       = <See RFC 4566>
+   byte-string = <See RFC 4566>
+   DIGIT       = <See RFC 5234>
+   HEXDIG      = <See RFC 5234>
+   CRLF        = <See RFC 5234>
+   hostport    = <See RFC 3261, with revisions from RFC 5954>
+
+   timestamp-refclk = "ts-refclk:" clksrc CRLF
+
+   clksrc = ntp / ptp / gps / gal / glonass / local / private /
+            clksrc-ext
+
+   clksrc-ext         = clksrc-param-name clksrc-param-value
+   clksrc-param-name  = token
+   clksrc-param-value = ["=" byte-string ]
+
+   ntp             = "ntp=" ntp-server-addr
+   ntp-server-addr = hostport / "/traceable/"
+
+   ptp             = "ptp=" ptp-version ":" ptp-server
+   ptp-version     = "IEEE1588-2002"
+                   / "IEEE1588-2008"
+                   / "IEEE802.1AS-2011"
+                   / ptp-version-ext
+   ptp-version-ext = token
+
+   ptp-server      = ptp-gmid [":" ptp-domain]
+                   / "traceable"
+   ptp-gmid        = EUI64
+   ptp-domain      = ptp-domain-name / ptp-domain-nmbr
+
+   ; PTP domain 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"
+
+
+
+Williams, et al.             Standards Track                   [Page 10]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   gal      =  "gal"
+   glonass  =  "glonass"
+   local    =  "local"
+   private  =  "private" [ ":traceable" ]
+
+   EUI64 = 7(2HEXDIG "-") 2HEXDIG
+
+           Figure 1: Timestamp Reference Clock Source Signalling
+
+4.8.1.  Examples
+
+   Figure 2 shows an example SDP description with a timestamp reference
+   clock source defined at the session level.
+
+   v=0
+   o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
+   s=SDP Seminar
+   i=A Seminar on the session description protocol
+   u=http://www.example.com/seminars/sdp.pdf
+   e=j.doe@example.com (Jane Doe)
+   c=IN IP4 233.252.0.1/64
+   t=2873397496 2873404696
+   a=recvonly
+   a=ts-refclk:ntp=/traceable/
+   m=audio 49170 RTP/AVP 0
+   m=video 51372 RTP/AVP 99
+   a=rtpmap:99 h263-1998/90000
+
+    Figure 2: Timestamp Reference Clock Definition at the Session Level
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 11]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   Figure 3 shows an example SDP description with timestamp reference
+   clock definitions at the media level overriding the session-level
+   defaults.
+
+   v=0
+   o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
+   s=SDP Seminar
+   i=A Seminar on the session description protocol
+   u=http://www.example.com/seminars/sdp.pdf
+   e=j.doe@example.com (Jane Doe)
+   c=IN IP4 233.252.0.1/64
+   t=2873397496 2873404696
+   a=recvonly
+   a=ts-refclk:local
+   m=audio 49170 RTP/AVP 0
+   a=ts-refclk:ntp=203.0.113.10
+   a=ts-refclk:ntp=198.51.100.22
+   m=video 51372 RTP/AVP 99
+   a=rtpmap:99 h263-1998/90000
+   a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
+
+     Figure 3: Timestamp Reference Clock Definition at the Media Level
+
+   Figure 4 shows an example SDP description with a timestamp reference
+   clock definition at the source level overriding the session-level
+   default.
+
+   v=0
+   o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
+   s=SDP Seminar
+   i=A Seminar on the session description protocol
+   u=http://www.example.com/seminars/sdp.pdf
+   e=j.doe@example.com (Jane Doe)
+   c=IN IP4 233.252.0.1/64
+   t=2873397496 2873404696
+   a=recvonly
+   a=ts-refclk:local
+   m=audio 49170 RTP/AVP 0
+   m=video 51372 RTP/AVP 99
+   a=rtpmap:99 h263-1998/90000
+   a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
+
+    Figure 4: Timestamp Reference Clock Signalling at the Source Level
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 12]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+5.  Media Clock Source Signalling
+
+   The media clock source for a stream determines the timebase used to
+   advance the RTP timestamps included in RTP packets.  The media clock
+   may be asynchronously generated by the sender, it may be generated in
+   fixed relationship to the reference clock, or it may be generated
+   with respect to another stream on the network (which is presumably
+   being received by the sender).
+
+5.1.  Asynchronously Generated Media Clock
+
+   In the simplest sender implementation, the sender generates media by
+   sampling audio or video according to a free-running local clock.  The
+   RTP timestamps in media packets are advanced according to this media
+   clock, and packet transmission is typically timed to regular
+   intervals on this timeline.  The sender may or may not include an NTP
+   timestamp in sender reports to allow mapping of this asynchronous
+   media clock to a reference clock.
+
+   The asynchronously generated media clock is the assumed mode of
+   operation when there is no signalling of the media clock source.
+   Alternatively, an asynchronous media clock may be explicitly
+   signalled.
+
+      a=mediaclk:sender
+
+5.2.  Direct-Referenced Media Clock
+
+   A media clock may be directly derived from a reference clock.  For
+   this case, it is required that a reference clock be specified with an
+   a=ts-refclk attribute (Section 4.8).
+
+   The signalling optionally indicates a media clock offset value.  The
+   offset indicates the RTP timestamp value at the epoch (time of
+   origin) of the reference clock.  To use the offset, implementations
+   need to compute RTP timestamps from reference clocks.  To simplify
+   these calculations, streams utilizing offset signalling SHOULD use a
+   TAI timestamp reference clock to avoid complications introduced by
+   leap seconds.  See [RFC7164] for further discussion of leap-second
+   issues in timestamp reference clocks.
+
+   To compute the RTP timestamp against an IEEE 1588 (TAI-based)
+   reference, the time elapsed between the 00:00:00 1 January 1970 IEEE
+   1588 epoch and the current time must be computed.  Between the epoch
+   and 1 January 2013, there were 15,706 days (including extra days
+   during leap years).  Since there are no leap seconds in a TAI
+   reference, there are exactly 86,400 seconds during each of these days
+   or a total of 1,356,998,400 seconds from the epoch to 00:00:00 1
+
+
+
+Williams, et al.             Standards Track                   [Page 13]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   January 2013.  A 90 kHz RTP clock for a video stream would have
+   advanced 122,129,856,000,000 units over this period.  With a
+   signalled offset of 0, the RTP clock value modulo the 32-bit unsigned
+   RTP timestamp representation in the RTP header would have been
+   2,460,938,240 at 00:00:00 1 January 2013.  If an offset of 23,465 had
+   been signalled, the clock value would have been 2,460,961,705.
+
+   In order to use an NTP reference, the actual time elapsed between the
+   00:00:00 1 January 1900 NTP epoch to the current time must be
+   computed. 2,208,988,800 seconds elapsed between the NTP epoch and
+   00:00:00 1 January 1970 [RFC0868].  Between the beginning of 1970 and
+   2013, there were 15,706 days elapsed (including extra days during
+   leap years) and 25 leap seconds inserted.  There is, therefore, a
+   total of 3,565,987,225 seconds from the NTP epoch to 00:00:00 1
+   January 2013.  A 90 kHz RTP clock for a video stream would have
+   advanced 320,938,850,250,000 units over this period.  With a
+   signalled offset of 0, the RTP clock value modulo the 32-bit unsigned
+   representation would have been 1,714,023,696 at 00:00:00 1 January
+   2013.
+
+   If no offset is signalled, the offset can be inferred at the receiver
+   by examining RTCP sender reports that contain NTP and RTP timestamps,
+   which combined define a mapping.  The NTP/RTP timestamp mapping
+   provided by RTCP sender reports (SRs) takes precedence over that
+   signalled through SDP; however, the media clock rate implied by the
+   SRs MUST be consistent with the rate signalled.
+
+   A rate modifier may be specified.  The modifier is expressed as the
+   ratio of two integers and modifies the rate specified or implied by
+   the media description by this ratio.  If omitted, the rate is assumed
+   to be the exact rate specified or implied by the media format.  For
+   example, without a rate specification, the RTP clock for an 8 kHz
+   G.711 audio stream will advance exactly 8000 units for each second
+   advance in the reference clock from which it is derived.
+
+   The rate modifier is primarily useful for accommodating certain
+   "oddball" audio sample rates associated with NTSC video (see
+   Figure 7).  Modified rates are not advised for video streams that
+   generally use a 90 kHz RTP clock regardless of frame rate or sample
+   rate used for embedded audio.
+
+      a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
+      denominator>]
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 14]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+5.3.  Stream-Referenced Media Clock
+
+   A common synchronisation architecture for audio/visual systems
+   involves distributing a reference media clock from a master device to
+   a number of slave devices, typically by means of a cable.  Examples
+   include audio word clock distribution and video black burst
+   distribution.  In this case, the media clock is locally generated,
+   often by a crystal oscillator, and is not locked to a timestamp
+   reference clock.
+
+   To support this architecture across a network, a master clock
+   identifier is associated with an RTP media stream carrying media
+   clock timing information from a master device.  The master clock
+   identifier represents a media clock source in the master device.
+   Slave devices in turn associate the master media clock identifier
+   with streams they transmit, signalling the synchronisation
+   relationship between the master and the transmitter's media clock.
+
+   Slave devices recover media clock timing from the clock master
+   stream, using it to synchronise the slave's media clock with the
+   master.  If a common reference clock is available, NTP timestamps in
+   the master clock RTP media stream are taken using the shared
+   reference clock.  The NTP timestamps communicate information about
+   media clock timing (rate and phase) from the master to the slave
+   devices.  NTP timestamps are communicated in the usual RTP fashion
+   via RTCP SRs, or via the [RFC6051] header extension.  If no shared
+   reference clock is available or signalled, a slave can synchronise to
+   the master's media clock using RTP timestamps alone as described in
+   Section 5.1 of [RFC3550].
+
+   Note that the slaving of a device media clock to a master device does
+   not affect RTP inter-media synchronisation.  Time-aligned playout of
+   two or more RTP sources still relies upon NTP timestamps supplied via
+   RTCP SRs or by the RFC 6051 timestamp header extension.
+
+   In a given system, master clock identifiers must uniquely identify a
+   single media clock source.  Such identifiers MAY be manually
+   configured; however, identifiers SHOULD be generated according to the
+   "short-term persistent RTCP CNAME" algorithm as described in
+   [RFC7022].  Master clock identifiers not already in base64 format
+   MUST be encoded as base64 strings when used in SDP.  Although the
+   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 an Audio Video Bridging
+   (AVB) stream based on the [IEEE1722] standard.
+
+
+
+
+Williams, et al.             Standards Track                   [Page 15]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   An RTP clock master stream SHOULD be identified at the source level
+   by an SSRC [RFC5576] and master clock identifier.  An RTP stream that
+   provides media clock timing directly from a reference media clock
+   (e.g., internal crystal, audio word clock, or video black burst
+   signal) 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:<ssrc> mediaclk:id=src:<media-clktag> sender
+
+      a=mediaclk:id=src:<media-clktag> sender
+
+   A transmitted RTP stream slaved to the media clock master is
+   signalled by including a master clock identifier:
+
+      a=mediaclk:id=<media-clktag> sender
+
+   An RTP media sender indicates that it is slaved to an IEEE 1722 clock
+   master via a stream identifier (an EUI-64):
+
+      a=mediaclk:IEEE1722=<StreamID>
+
+   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
+
+   Specification of the media clock source may be at any or all levels
+   (session, media, or source) of an SDP description (see level
+   definitions (Section 3) earlier in this document for more
+   information).
+
+   Media clock source signalling included at session level provides
+   default parameters for all RTP sessions and sources in the session
+   description.  More specific signalling included at the media level
+   overrides session-level signalling.  Further, source-level signalling
+   overrides media clock source signalling at the enclosing media level
+   and session level.
+
+   Media clock source signalling may be present or absent on a per-
+   stream basis.  In the absence of media clock source signals,
+   receivers assume an asynchronous media clock generated by the sender.
+
+   Media clock source parameters may be repeated at a given level (i.e.,
+   for a session or source) to provide information about additional
+   clock sources.  If the attribute is repeated at a given level, all
+
+
+
+Williams, et al.             Standards Track                   [Page 16]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   clocks described at that level are comparable clock sources and may
+   be used interchangeably.
+
+   General forms of usage:
+
+   session level:  a=mediaclk:<mediaclock>
+
+   media level:  a=mediaclk:<mediaclock>
+
+   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>
+
+   media-clksrc = "mediaclk:" [media-clkid SP] mediaclock
+
+   media-clkid  = "id=" [ "src:" ] media-clktag
+   media-clktag = base64
+
+   mediaclock   = sender / direct / ieee1722-streamid / mediaclock-ext
+
+   mediaclock-ext         = mediaclock-param-name mediaclock-param-value
+   mediaclock-param-name  = token
+   mediaclock-param-value = [ "=" byte-string ]
+
+   sender = "sender"
+   direct = "direct" [ "=" 1*DIGIT ] [SP rate]
+   rate   = "rate=" integer "/" integer
+
+   ieee1722-streamid = "IEEE1722=" avb-stream-id
+   avb-stream-id     = EUI64
+   EUI64 = 7(2HEXDIG "-") 2HEXDIG
+
+                  Figure 5: Media Clock Source Signalling
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 17]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+5.5.  Examples
+
+   Figure 6 shows an example SDP description -- 8 channels of 24-bit, 48
+   kHz audio transmitted as a multicast stream.  Media clock is derived
+   directly from an IEEE 1588-2008 reference.
+
+   v=0
+   o=- 1311738121 1311738121 IN IP4 192.0.2.1
+   c=IN IP4 233.252.0.1/64
+   s=
+   t=0 0
+   m=audio 5004 RTP/AVP 96
+   a=rtpmap:96 L24/48000/8
+   a=sendonly
+   a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
+   a=mediaclk:direct=963214424
+
+        Figure 6: Media Clock Directly Referenced to IEEE 1588-2008
+
+   Figure 7 shows an example SDP description -- 2 channels of 24-bit,
+   44056 kHz NTSC "pull-down" media clock derived directly from an IEEE
+   1588-2008 reference clock.
+
+   v=0
+   o=- 1311738121 1311738121 IN IP4 192.0.2.1
+   c=IN IP4 233.252.0.1/64
+   s=
+   t=0 0
+   m=audio 5004 RTP/AVP 96
+   a=rtpmap:96 L24/44100/2
+   a=sendonly
+   a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
+   a=mediaclk:direct=963214424 rate=1000/1001
+
+   Figure 7: "Oddball" Sample Rate Directly Referenced to IEEE 1588-2008
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 18]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   Figure 8 shows the same 48 kHz audio transmission from Figure 6 with
+   media clock derived from another RTP stream.
+
+   v=0
+   o=- 1311738121 1311738121 IN IP4 192.0.2.1
+   c=IN IP4 233.252.0.1/64
+   s=
+   t=0 0
+   m=audio 5004 RTP/AVP 96
+   a=rtpmap:96 L24/48000/2
+   a=sendonly
+   a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
+   a=mediaclk:id=MDA6NjA6MmI6MjA6MTI6MWY= sender
+
+         Figure 8: RTP Stream with Media Clock Slaved to a Master
+
+   Figure 9 shows the same 48 kHz audio transmission from Figure 6 with
+   media clock derived from an IEEE 1722 AVB stream.
+
+   v=0
+   o=- 1311738121 1311738121 IN IP4 192.0.2.1
+   c=IN IP4 233.252.0.1/64
+   s=
+   t=0 0
+   m=audio 5004 RTP/AVP 96
+   a=rtpmap:96 L24/48000/2
+   a=sendonly
+   a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
+   a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
+
+            Figure 9: RTP Stream with Media Clock Slaved to an
+                          IEEE 1722 Master Device
+
+6.  Signalling Considerations
+
+   Signalling of timestamp reference clock source (Section 4.8) and
+   media clock source (Section 5.4) is defined to be used either by
+   applications that implement the SDP Offer/Answer model [RFC3264] or
+   by applications that use SDP to describe media and transport
+   configurations.
+
+   A description SHOULD include both reference clock signalling and
+   media clock signalling.  If no reference clock is available, this
+   SHOULD be signalled as a local reference (Section 4.6).
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 19]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   When no media clock signalling is present, an asynchronous media
+   clock (Section 5.1) MUST be assumed.  When no reference clock
+   signalling is present, a local reference clock (Section 4.6) MUST be
+   assumed.
+
+   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
+
+   During offer/answer, clock source signalling via SDP uses a
+   declarative model.  Supported media and/or reference clocks are
+   specified in the offered SDP description.  The answerer may accept or
+   reject the offer in an application-specific way depending on the
+   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 negotiation of reference clock and media clock attributes is
+   not defined in this document, negotiation MAY be accomplished using
+   the capabilities negotiation procedures defined in [RFC5939].
+
+6.1.1.  Indicating Support for Clock Source Signalling
+
+   An offerer or answerer indicates support for media clock signalling
+   by including a reference or media clock specification in the SDP
+   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.
+
+6.1.2.  Timestamp Reference Clock
+
+   If one or more of the reference clocks specified in the offer are
+   usable by the answerer, the answerer SHOULD respond with an answer
+   containing the subset of reference clock specifications in the offer
+   that are usable by the answerer.  If the answerer rejects the offer
+   because the available reference clocks are incompatible, the
+
+
+
+Williams, et al.             Standards Track                   [Page 20]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   rejection MUST contain at least one timestamp reference clock
+   specification usable by the answerer so that appropriate information
+   is available for diagnostics.  If no external reference clock is
+   available to the answerer, a local reference clock (Section 4.6)
+   specification SHOULD be included in the rejection.
+
+   In both offers and answers, multiple reference clock specifications
+   indicate equivalent clocks from different sources that may be used
+   interchangeably.  RTP senders and receivers are assured proper
+   synchronisation 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 so that appropriate information is available for
+   diagnostics.  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
+
+   SDP can be employed outside of the offer/answer context, for
+   instance, for multimedia sessions that are announced through the
+   Session Announcement Protocol (SAP) [RFC2974] or streamed through the
+   Real Time Streaming Protocol (RTSP) [RFC2326].
+
+   Devices using published descriptions to join sessions SHOULD assess
+   their synchronisation compatibility with the described session based
+   on the clock source signalling and SHOULD NOT attempt to join a
+   session with incompatible reference or media clocks.
+
+7.  Security Considerations
+
+   Entities receiving and acting upon an SDP message should note that a
+   session description cannot be trusted unless it has been obtained by
+   an authenticated transport protocol from a known and trusted source.
+   Many different transport protocols may be used to distribute a
+   session description, and the nature of the authentication will differ
+   from transport to transport.  For some transports, security features
+   are often not deployed.  In case a session description has not been
+   obtained in a trusted manner, the endpoint should exercise care
+   because, among other attacks, the media sessions received may not be
+
+
+
+Williams, et al.             Standards Track                   [Page 21]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   the intended ones, the destination where media is sent to may not be
+   the expected one, and any of the parameters of the session may be
+   incorrect.
+
+   Incorrect reference or media clock parameters may cause devices or
+   streams to synchronise to unintended clock sources.  Normally, this
+   simply results in failure to establish a session or failure to
+   synchronise once connected.  Enough devices fraudulently assigned to
+   a specific clock source (e.g., a particular IEEE 1588 grandmaster)
+   may, however, constitute a successful denial-of-service attack on
+   that source.  Devices MAY wish to validate the integrity of the clock
+   description through some means before connecting to unfamiliar clock
+   sources.
+
+   The timestamp reference clocks negotiated by this protocol are used
+   to provide media timing information to RTP.  Negotiated timestamp
+   reference clocks should not be relied upon to provide a secure time
+   reference for security critical operations (e.g., the expiration of
+   public key certificates).
+
+8.  IANA Considerations
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 22]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+8.1.  Reference Clock SDP Parameter
+
+   The SDP attribute "ts-refclk" defined by this document is registered
+   with the IANA registry of SDP Parameters as follows:
+
+   SDP Attributes ( "att-field (both session and media level)" &
+                    "att-field (source level)" ):
+
+     Attribute name:     ts-refclk
+
+     Long form:          Timestamp reference clock source
+
+     Type of name:       att-field
+
+     Type of attribute:  Session, media, and source level
+
+     Subject to charset: No
+
+     Purpose:            See Section 4 of this document
+
+     Reference:          This document
+
+     Values:             See Section 8.3 of this document
+
+        Figure 10: Reference Clock SDP Parameter IANA Registration
+
+   The attribute has an extensible parameter field; therefore, a
+   registry for these parameters is required.  This new registry is
+   defined in Section 8.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 23]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+8.2.  Media Clock SDP Parameter
+
+   The SDP attribute "mediaclk" defined by this document is registered
+   with the IANA registry of SDP Parameters as follows:
+
+   SDP Attributes ( "att-field (both session and media level)" &
+                    "att-field (source level)" ):
+
+     Attribute name:     mediaclk
+
+     Long form:          Media clock source
+
+     Type of name:       att-field
+
+     Type of attribute:  Session, media, and source level
+
+     Subject to charset: No
+
+     Purpose:            See Section 5 of this document
+
+     Reference:          This document
+
+     Values:             See Section 8.4 of this document
+
+          Figure 11: Media Clock SDP Parameter IANA Registration
+
+   The attribute has an extensible parameter field; therefore, a
+   registry for these parameters is required.  The new registry is
+   defined in Section 8.4.
+
+8.3.  Timestamp Reference Clock Source Parameters Registry
+
+   This document creates a new IANA subregistry called the Timestamp
+   Reference Clock Source Parameters registry, subordinate to the IANA
+   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)
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 24]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   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].  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.
+
+   +---------+------------------------------+--------------------------+
+   | Name    | Long Name                    | Reference                |
+   +---------+------------------------------+--------------------------+
+   | ntp     | Network Time Protocol        | This document, Section 4 |
+   |         |                              |                          |
+   | ptp     | Precision Time Protocol      | This document, Section 4 |
+   |         |                              |                          |
+   | gps     | Global Positioning System    | This document, Section 4 |
+   |         |                              |                          |
+   | gal     | Galileo                      | This document, Section 4 |
+   |         |                              |                          |
+   | glonass | Global Navigation Satellite  | This document, Section 4 |
+   |         | System                       |                          |
+   |         |                              |                          |
+   | 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 subregistry called the Media Clock
+   Source Parameters registry, subordinate to the IANA SDP Parameters
+   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
+   given below.
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 25]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   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 mediaclock-param-name.  The Reference must
+   specify a syntax corresponding to mediaclock-param-value.
+
+   +----------+-----------------------------+--------------------------+
+   | Name     | Long Name                   | Reference                |
+   +----------+-----------------------------+--------------------------+
+   | sender   | Asynchronously Generated    | This document, Section 5 |
+   |          | Media Clock                 |                          |
+   |          |                             |                          |
+   | direct   | Direct-Referenced Media     | This document, Section 5 |
+   |          | Clock                       |                          |
+   |          |                             |                          |
+   | IEEE1722 | IEEE1722 Media Stream       | This document, Section 5 |
+   |          | Identifier                  |                          |
+   +----------+-----------------------------+--------------------------+
+
+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 Timestamp 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.
+
+9.  Acknowledgements
+
+   The authors would like to thank Magnus Westerlund and Paul Kyzivat
+   for valuable comments that resulted in important improvements to this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 26]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+10.  References
+
+10.1.  Normative References
+
+   [IEEE1588-2002]
+              IEEE, "1588-2002 - IEEE Standard for a Precision Clock
+              Synchronization Protocol for Networked Measurement and
+              Control Systems", October 2002,
+              <http://standards.ieee.org/findstds/
+              standard/1588-2002.html>.
+
+   [IEEE1588-2008]
+              IEEE, "1588-2008 - IEEE Standard for a Precision Clock
+              Synchronization Protocol for Networked Measurement and
+              Control Systems", July 2008,
+              <http://standards.ieee.org/findstds/
+              standard/1588-2008.html>.
+
+   [IEEE1722] IEEE, "1722-2001 - IEEE Standard for Layer 2 Transport
+              Protocol for Time Sensitive Applications in a Bridged
+              Local Area Network", May 2011,
+              <http://standards.ieee.org/findstds/
+              standard/1722-2011.html>.
+
+   [IEEE802.1AS-2011]
+              IEEE, "802.1AS-2011 - IEEE Standard for Local and
+              Metropolitan Area Networks - Timing and Synchronization
+              for Time-Sensitive Applications in Bridged Local Area
+              Networks", February 2011,
+              <http://standards.ieee.org/findstds/
+              standard/802.1AS-2011.html>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264, June
+              2002.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 27]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
+              Media Attributes in the Session Description Protocol
+              (SDP)", RFC 5576, June 2009.
+
+   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
+              Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, June 2010.
+
+   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
+              Flows", RFC 6051, November 2010.
+
+   [RFC7022]  Begen, A., Perkins, C., Wing, D., and E. Rescorla,
+              "Guidelines for Choosing RTP Control Protocol (RTCP)
+              Canonical Names (CNAMEs)", RFC 7022, September 2013.
+
+10.2.  Informative References
+
+   [AES11-2009]
+              Audio Engineering Society, "AES11-2009: AES recommended
+              practice for digital audio engineering - Synchronization
+              of digital audio equipment in studio operations", February
+              2010, <http://www.aes.org/standards/>.
+
+   [IEEE802.1BA-2011]
+              IEEE, "802.1BA-2011 - IEEE Standard for Local and
+              metropolitan area networks -- Audio Video Bridging (AVB)
+              Systems", September 2011,
+              <http://standards.ieee.org/findstds/
+              standard/802.1BA-2011.html>.
+
+   [IS-GPS-200F]
+              Global Positioning Systems Directorate, "Navstar GPS Space
+              Segment/Navigation User Segment Interfaces", IS-GPS-200F ,
+              September 2011,
+              <http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
+
+   [Olsen]    Olsen, D., "Time Accuracy Requirements in Audio Networks",
+              April 2007,
+              <http://www.ieee802.org/1/files/public/docs2007/
+              as-dolsen-time-accuracy-0407.pdf>.
+
+
+
+
+Williams, et al.             Standards Track                   [Page 28]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+   [RFC0868]  Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
+              RFC 868, May 1983.
+
+   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+              Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
+              Announcement Protocol", RFC 2974, October 2000.
+
+   [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.
+
+   [RFC5939]  Andreasen, F., "Session Description Protocol (SDP)
+              Capability Negotiation", RFC 5939, September 2010.
+
+   [RFC7164]  Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC
+              7164, March 2014.
+
+   [RFC7272]  Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
+              Montagud, M., and K. Gross, "Inter-Destination Media
+              Synchronization (IDMS) Using the RTP Control Protocol
+              (RTCP)", RFC 7272, June 2014.
+
+   [SMPTE-318M-1999]
+              Society of Motion Picture & Television Engineers,
+              "Television and Audio - Synchronization of 59.94- or 50-Hz
+              Related Video and Audio Systems in Analog and Digital
+              Areas - Reference Signals", ST 318:1999,
+              <http://standards.smpte.org/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 29]
+
+RFC 7273               RTP Clock Source Signalling             June 2014
+
+
+Authors' Addresses
+
+   Aidan Williams
+   Audinate
+   Level 1, 458 Wattle St
+   Ultimo, NSW  2007
+   Australia
+
+   Phone: +61 2 8090 1000
+   Fax:   +61 2 8090 1001
+   EMail: aidan.williams@audinate.com
+   URI:   http://www.audinate.com/
+
+
+   Kevin Gross
+   AVA Networks
+   Boulder, CO
+   US
+
+   EMail: kevin.gross@avanw.com
+   URI:   http://www.avanw.com/
+
+   Ray van Brandenburg
+   TNO
+   Brassersplein 2
+   Delft  2612CT
+   The Netherlands
+
+   Phone: +31-88-866-7000
+   EMail: ray.vanbrandenburg@tno.nl
+
+
+   Hans Stokking
+   TNO
+   Brassersplein 2
+   Delft  2612CT
+   The Netherlands
+
+   EMail: hans.stokking@tno.nl
+
+
+
+
+
+
+
+
+
+
+
+
+Williams, et al.             Standards Track                   [Page 30]
+