Skip to main content

RTP Clock Source Signalling
draft-williams-avtcore-clksrc-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Aidan Williams , Ray van Brandenburg
Last updated 2012-02-28
Replaced by draft-ietf-avtcore-clksrc, RFC 7273
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-williams-avtcore-clksrc-00
Audio/Video Transport Core                                   A. Williams
Maintenance                                                     Audinate
Internet-Draft                                        R. van Brandenburg
Intended status: Standards Track                                     TNO
Expires: August 31, 2012                                        K. Gross
                                                            AVA Networks
                                                       February 28, 2012

                      RTP Clock Source Signalling
                    draft-williams-avtcore-clksrc-00

Abstract

   NTP timestamps are used by several RTP protocols for synchronisation
   and statistical measurement.  This memo specificies SDP signalling
   identifying NTP timestamp clock sources and SDP signalling
   identifying the media clock sources in a multimedia session.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 31, 2012.

Copyright Notice

   Copyright (c) 2012 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

Williams, et al.         Expires August 31, 2012                [Page 1]
Internet-Draft         RTP Clock Source Signalling         February 2012

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Applications . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Timestamp Reference Clock Source Signalling  . . . . . . . . .  5
     4.1.  Equivalent Timestamp Clocks  . . . . . . . . . . . . . . .  5
     4.2.  Identifying NTP Reference Clocks . . . . . . . . . . . . .  6
     4.3.  Identifying PTP Reference Clocks . . . . . . . . . . . . .  6
     4.4.  Identifying Global Reference Clocks  . . . . . . . . . . .  8
     4.5.  Other Reference Clocks . . . . . . . . . . . . . . . . . .  8
     4.6.  Traceable Reference Clocks . . . . . . . . . . . . . . . .  8
     4.7.  Synchronisation Confidence . . . . . . . . . . . . . . . .  8
     4.8.  SDP Signalling of Timestamp Clock Source . . . . . . . . .  9
       4.8.1.  Examples . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Timescales, UTC TAI and leap seconds . . . . . . . . . . . . . 12
   6.  Media Clock Source Signalling  . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  An Appendix . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Williams, et al.         Expires August 31, 2012                [Page 2]
Internet-Draft         RTP Clock Source Signalling         February 2012

1.  Introduction

   RTP protocols use NTP format timestamps to facilitate media stream
   synchronisation and for providing estimates of round trip time (RTT)
   and other statistical parameters.

   Information about media clock timing exchanged in NTP format
   timestamps may come from a clock which is synchronised to a global
   time reference, but this cannot be assumed nor is there a
   standardised mechanism available to indicate that timestamps are
   derived from a common reference clock.  Therefore, RTP
   implementations typically assume that NTP timestamps are taken using
   unsynchronised clocks and must compensate for absolute time
   differences and rate differences.  Without a shared reference clock,
   RTP can time align flows from the same source at a given receiver
   using relative timing, however tight synchronisation between two or
   more different receivers (possibly with different network paths) or
   between two or more senders is not possible.

   High performance AV systems often use a reference media clock
   distributed to all devices in the system.  The reference media clock
   is often distinct from the the reference clock used to provide
   timestamps.  A reference media clock may be provided along with a
   audio or video signal interface, or via a dedicated clock signal
   (e.g. genlock [9] or audio word clock [10].  If sending and receiving
   media clocks are known to be synchronised to a common reference
   clock, performance can improved by minimising buffering and avoiding
   rate conversion.

   This specification defines SDP signalling of timestamp clock sources
   and media reference clock sources.

2.  Applications

   Timestamp clock source and reference media clock signalling benefit
   applications requiring synchronised media capture or playout and low
   latency operation.

   Exmaples include, but are not limited to:

   Social TV  RTCP for inter-destination media synchronization [4]
      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 when two or more users are watching the same television
      broadcast at different devices and locations, while communicating
      with each other using text, audio and/or video.  A skew in the

Williams, et al.         Expires August 31, 2012                [Page 3]
Internet-Draft         RTP Clock Source Signalling         February 2012

      media play-out 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
      friend(s).

   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 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 60 hertz (every 16-2/3 milliseconds) or potentially
      faster.  If the refresh is not synchronized, the effect of
      multiple screens acting as one is broken.

   Netwoked Audio  Networked loudspeakers, amplifiers and analogue I/O
      devices transmitting or receiving audio signals via RTP can be
      connected to various parts of a building or campus network.  Such
      situations can for example be found in large conference rooms,
      legislative chambers, classrooms (especially those supporting
      distance learning) and other large-scale environments such as
      stadiums.  Since humans are more susceptible to differences in
      audio delay, this use case needs even more accuracy than the video
      wall use case.  Depending on the exact application, the need for
      accuracy can then be in the range of microseconds [11].

   Sensor Arrays  Sensor arrays contain many synchronised measurement
      elements producing signals which are then combined to form an
      overall measurement.  Accurate capture of the phase relationships
      between the various signals arriving at each element of the array
      is critically important for proper operation.  Examples include
      towed or fixed sonar arrays, seismic arrays and phased arrays.

3.  Definitions

   The definitions of streams, sources and levels of information in SDP
   descriptions follow the definitions found in Source-Specific Media
   Attributes in the Session Description Protocol (SDP) [2].

   multimedia session  A set of multimedia senders and receivers as well
      as the data streams flowing from senders to receivers.  The
      Session Description Protocol (SDP) [3] describes multimedia
      sessions.

Williams, et al.         Expires August 31, 2012                [Page 4]
Internet-Draft         RTP Clock Source Signalling         February 2012

   media stream  An RTP session potentially containing more than one RTP
      source.  SDP media descriptions beginning with an "m"-line define
      the parameters of a media stream.

   media source  A media source is single stream of RTP packets,
      identified by an RTP SSRC.

   session-level  Session-level information applies to an entire
      multimedia session.  In an SDP description, session-level
      information appears before the first "m"-line.

   media-level  Media-level information applies to a single media stream
      (RTP session).  In an SDP description, media-level information
      appears after each "m"-line.

   source-level  Source-level information applies to a single stream of
      RTP packets, identified by an RTP SSRC Source-Specific Media
      Attributes in the Session Description Protocol (SDP) [2] 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 a global time reference.  GPS
      XXX is commonly used to provide a traceable time reference.  Some
      network time synchronisation protocols (e.g.  XXX PTP) can
      explicitly indicate that the master clock is providing a traceable
      time reference over the network.

4.  Timestamp Reference Clock Source Signalling

   The NTP timestamps used by RTP are taking by reading a local 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 [5]) and radio clocks like GPS [XXX].

   The following sections describe and define SDP signalling indicating
   whether and how the local timestamping clock in an RTP sender/
   receiver is synchronised to a reference clock.

4.1.  Equivalent Timestamp Clocks

   Two or more local clocks that are sufficiently synchronised will
   produce timestamps for a given event which are effectively identical
   for the purposes of RTP.  A local clock in one RTP sender/receiver
   can be considered equivalent to a local clock in another RTP sender/

Williams, et al.         Expires August 31, 2012                [Page 5]
Internet-Draft         RTP Clock Source Signalling         February 2012

   receiver providing they are sufficiently synchronised such that
   timestamps produced by one clock are indistinguishable from
   timestamps produced by the other.  The timestamps produced by
   equivalent local clocks in two or more RTP senders/receivers
   receivers can be directly compared.

   One or more local clocks are equivalent if they are synchronised to a
   single master clock via a network time protocol (e.g.  XXX NTP,
   802.1AS, IEEE1588v2).

   One or more local clocks are equivalent if they are synchronised to
   any member of a set of master clocks provided that the set of master
   clocks are synchronised.

   One or more local clocks are equivalent if they are synchronised to a
   clock master providing a global time reference (e.g.  XXX GPS,
   Gallileo).  Some network time protocols (e.g.  XXX PTP) may allow
   master clocks to explicitly indicate that they are "traceable" back
   to a global time reference.

4.2.  Identifying NTP Reference Clocks

   A single NTP server is identified by identified by hostname (or IP
   address) and an optional port number.  If the port number is not
   indicated, it is assumed to be the standard NTP port (123) XXX.

   Two or more NTP servers may be listed to indicate that they are
   interchangeable.  RTP senders/receivers can use any of the listed NTP
   servers to govern a local clock that is equivalent to a local clock
   slaved to a difference server.

   XXX Question: Does NTP carry traceability information?  Or is this
   implicit somehow in the stratum?  Apparently there are some bits in
   the leap seconds functionality which talk about "tracking"..

4.3.  Identifying PTP Reference Clocks

   The IEEE1588 Precision Time Protocol (PTP) family of clock
   synchronisation protocols provide a shared reference clock in an
   network - typically a LAN.  IEEE1588 provides sub-microsecond
   synchronisation between devices on a LAN and typically locks within
   seconds at startup.  With support from Ethernet switches, IEEE1588
   protocols can achieve nanosecond timing accuracy in LANs.  Network
   interface chips and cards supporting hardware time-stamping of timing
   critical protocol messages are also available.

   When using IEEE1588 clock synchronisation, networked AV systems can
   achieve sub 1 microsecond time alignment accuracy when rendering AV

Williams, et al.         Expires August 31, 2012                [Page 6]
Internet-Draft         RTP Clock Source Signalling         February 2012

   signals and can support latencies less than 1ms through a gigabit
   LAN.

   Three flavours of IEEE1588 are in use today:

   o  IEEE 1588-2002 [6]: the original "Standard for a Precision Clock
      Synchronization Protocol for Networked Measurement and Control
      Systems".  This is often called IEEE1588v1 or PTPv1.

   o  IEEE 1588-2008 [7]: 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 often called IEEE1588v2 or PTPv2.

   o  IEEE 802.1AS [8]: "Timing and Synchronization for Time Sensitive
      Applications in Bridged Local Area Networks".  This is a Layer-2
      only profile of IEEE 1588-2008 for use in Audio/Video Bridged
      LANs.

   Each IEEE1588 clock is identified by a globally unique EUI-64 called
   a "ClockIdentity".  A slave clock using one of the IEEE1588 family of
   network time protocols acquires the ClockIdentity/EUI-64 of the
   grandmaster clock that is the ultimate source of timing information.
   A master clock which is itself slaved to another master clock passes
   the grand master clock identity through to its slaves.

   Several instances of the IEEE1588v1/v2 protocol may operate
   independently on a single network, forming distinct PTP network
   protocol domains each of which may have a different master clock.  As
   the IEEE1588 standards have developed, the definition of PTP domains
   has changed.  IEEE1588v1 identifies protocol subdomains by a textual
   name and IEEE1588v2 identifies protocol domains using a numeric
   domain number. 802.1AS is a Layer2 profile of IEEE1588v2 supporting a
   single numeric clock domain (0).  This specification assumes that an
   IEEE1588 clock master for multiple domains will provide the same
   timing information to all domains or that each clock domain has a
   different master.  In other words, this specification assumes that a
   timing domain can be uniquely identified using the ClockIdentity of
   the grandmaster clock alone.

   The PTP family of protocols employ a distributed election protocol
   called the "Best Master Clock Algorithm (BMCA) to determine the
   active clock master.  The clock master choices available to BMCA can
   be restricted or favourably biased by setting stratum values,
   preffered master clock bits, or other parameters to influence the
   election process.  In some systems it may be desirable to limit the
   number of possible PTP clock masters to avoid re-signalling timestamp
   clock sources when the clock master changes.

Williams, et al.         Expires August 31, 2012                [Page 7]
Internet-Draft         RTP Clock Source Signalling         February 2012

4.4.  Identifying Global Reference Clocks

   Global reference clocks provide a source of tracable time, typically
   via a hardware radio receiver interface.  Examples include GPS and
   Gallileo.  Apart from the name of the reference clock system, no
   further identification is required.

4.5.  Other Reference Clocks

   At the time of writing, it is common for RTP senders/receivers not to
   synchronise their local timestamp clock to a master.  An
   unsynchronised clock such as a quartz oscillator is identified as a
   "local" reference clock.

   In some systems, all RTP senders/receivers may use a timetsamp clock
   synchronised to a reference clock that is not provided by one of the
   methods listed above.  Examples may include the reference time
   information provided by digital television or cellular services.
   These sources are identified as "private" reference clocks.  All RTP
   senders/receivers in a session using a private reference clock are
   assumed to have a mechanism outside this specification confirming
   that their local timestamp clocks are equivalent.

4.6.  Traceable Reference Clocks

   A timestamp clock source may be labelled "traceable" if it is known
   to be sourced from a global time reference such as TAI or UTC XXX.
   Providing adjustments are made for differing time bases, timestamps
   taken using a clocks synchronised to a traceable time source can be
   directly compared even if the clocks are synchronised to different
   servers or via different mechanisms.  Any traceable timestamp clock
   source can be considered equivalent to another traceable timestamp
   clock source and the timestamps may be directly compared.

   Since any NTP or PTP server providing traceable time can be
   considered equivalent, it is not necessary to identify traceable time
   servers by protocol address.

4.7.  Synchronisation Confidence

   Network time protocols periodically exchange timestamped messages
   between servers and clients.  Assuming RTP sender/receiver clocks are
   based on commonly available quartz crystal hardware, tight
   synchronisation requires frequent exchange of synchronisation
   messages.

   Unfortunately, in some implementations, it is not possible to control
   the frequency of synchronisation messages nor is it possible to

Williams, et al.         Expires August 31, 2012                [Page 8]
Internet-Draft         RTP Clock Source Signalling         February 2012

   discover when the last sychronisation message occured.  In order to
   provide a measure of confidence that the timestamp clock is
   sufficiently synchronised, an optional timestamp may be included in
   the SDP clock source signalling.  In addition, the frequency of
   synchronisation message may also optionally be provided.

   The optional timestamp and synchronisation frequency parameters
   provide an indication of synchronisation quality to the receiver of
   those parameters.  If the synchronisation confidence timestamp is far
   from the timestamp clock at the receiver of the parameters, it can be
   assumed that synchronisation has not occured recently or the
   timestamp reference clock source is wrongly configured or cannot be
   contacted.  In this case, the receiver can take action to prevent
   unsynchronised playout or may fall back to assuming that the
   timestamp clocks are not synchronised.

   Synchronisation frequency is expressed as an 8-bit excess-127 field
   which is the base 2 logarithm of the frequency in HZ.  The
   synchronisation frequencies represented by this field range from
   2^-127 Hz to 2^+128 Hz.  The field value of 127 corresponds to an
   update frequency of 1 Hz.

4.8.  SDP Signalling of Timestamp Clock Source

   Specification of the timestamp reference clock source may at all
   levels of an SDP description (see level definitions (Section 3)
   earlier in this document for more information).

   Timestamp clock source signalling included at session-level provides
   default parameters for all RTP sessions and sources in the session
   description.  More specific signalling included at the media-level
   overrides default session-level signalling.  Further, source-level
   signalling overrides timestamp clock source signalling at the
   enclosing media-level and session-level.

   If timestamp clock source signalling is included anywhere in an SDP
   description, it must be properly defined for all levels in the
   description.  This may simply be achieved by providing default
   signalling at the session level.

   Timestamp reference clock parameters may be repeated at a given level
   (i.e. for a session or source) to provide information about
   additional servers or clock sources.  If the attribute is repeated at
   a given level, all clocks described at that level are assumed to be
   equivalent.  Traceable clock sources MUST NOT be mixed with clock
   sources having explicit addresses for a given source or session.
   Unless synchronisation confidence information is available for each
   of the reference clocks listed at a given level, it SHOULD only be

Williams, et al.         Expires August 31, 2012                [Page 9]
Internet-Draft         RTP Clock Source Signalling         February 2012

   included with the first reference clock source attribute at that
   level.

   Note that clock source parameters may change from time to time, for
   example, as a result of a PTP clock master election.  The SIP XXX
   protocol supports re-signalling of updated SDP information, however
   other protocols may require additional notification mechanisms.

     timestamp-refclk = "a=ts-refclk:" clksrc SP [sync-confidence] CRLF

     clksrc = ntp / ptp / gps / gal / local / private

     ntp             =  "ntp=" ntp-server-addr
     ntp-server-addr =  host [ ":" port ]
     ntp-server-addr =/ "traceable" )

     ptp             =  "ptp=" ptp-version ":" ptp-gmid
     ptp-version     =  "IEEE1588-2002"
     ptp-version     =/ "IEEE1588-2008"
     ptp-version     =/ "IEEE802.1AS-2011"
     ptp-gmid        =  EUI64
     ptp-gmid        =/ "traceable"

     gps      =  "gps"
     gal      =  "gal"
     local    =  "local"
     private  =  "private" [ ":" "traceable" ]

     sync-confidence = sync-timestamp [SP sync-frequency]

     sync-timestamp  = sync-date SP sync-time SP sync-UTCoffset

     sync-date       = 4DIGIT "-" 2DIGIT "-" 2DIGIT
                       ; yyyy-mm-dd (e.g., 1982-12-02)

     sync-time       = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT
                       ; 00:00:00.000 - 23:59:59.999

     sync-UTCoffset  = ( "+" / "-" ) 2DIGIT ":" 2DIGIT
                       ; +HH:MM or -HH:MM

     sync-frequency  = 2HEXDIG
                       ; If N is the field value, HZ=2^(N-127)

     host          = hostname / IPv4address / IPv6reference

Williams, et al.         Expires August 31, 2012               [Page 10]
Internet-Draft         RTP Clock Source Signalling         February 2012

     hostname      =  *( domainlabel "." ) toplabel [ "." ]
     toplabel      =  ALPHA / ALPHA *( alphanum / "-" ) alphanum
     domainlabel   =  alphanum
                   =/ alphanum *( alphanum / "-" ) alphanum

     IPv4address   =  1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
     IPv6reference =  "[" IPv6address "]"
     IPv6address   =  hexpart [ ":" IPv4address ]
     hexpart       =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
     hexseq        =  hex4 *( ":" hex4)
     hex4          =  1*4HEXDIG

     port = 1*DIGIT

     EUI-64 = 7(HEXDIG "-") 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 10.47.16.5
              s=SDP Seminar
              i=A Seminar on the session description protocol
              u=http://www.example.com/seminars/sdp.pdf
              e=j.doe@example.com (Jane Doe)
              c=IN IP4 224.2.17.12/127
              t=2873397496 2873404696
              a=recvonly
              a=ts-refclk:ntp=traceable
              m=audio 49170 RTP/AVP 0
              m=video 51372 RTP/AVP 99
              a=rtpmap:99 h263-1998/90000

    Figure 2: Timestamp reference clock defintion at the session level

   Figure 3 shows an example SDP description with timestamp reference
   clock definitions at the media-level overriding the session-level
   defaults.  Note that the synchronisation confidence timestamp appears
   on the first attribute at the media-level only.

Williams, et al.         Expires August 31, 2012               [Page 11]
Internet-Draft         RTP Clock Source Signalling         February 2012

         v=0
         o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
         s=SDP Seminar
         i=A Seminar on the session description protocol
         u=http://www.example.com/seminars/sdp.pdf
         e=j.doe@example.com (Jane Doe)
         c=IN IP4 224.2.17.12/127
         t=2873397496 2873404696
         a=recvonly
         a=ts-refclk:local
         m=audio 49170 RTP/AVP 0
         a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00
         a=ts-refclk:ntp=198.51.100.22
         m=video 51372 RTP/AVP 99
         a=rtpmap:99 h263-1998/90000
         a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0

     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 10.47.16.5
    s=SDP Seminar
    i=A Seminar on the session description protocol
    u=http://www.example.com/seminars/sdp.pdf
    e=j.doe@example.com (Jane Doe)
    c=IN IP4 224.2.17.12/127
    t=2873397496 2873404696
    a=recvonly
    a=ts-refclk:local
    m=audio 49170 RTP/AVP 0
    m=video 51372 RTP/AVP 99
    a=rtpmap:99 h263-1998/90000
    a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0

    Figure 4: Timestamp reference clock signalling at the source level

5.  Timescales, UTC TAI and leap seconds

   RTP implementation is simplified by using a clock reference with a
   timescale which does not include leap seconds.  IEEE 1588, GPS and
   other TAI (Inernational Atomic Time) references do not include leap
   seconds.  NTP time, operating system clocks and other UTC
   (Coordinated Universal Time) references include leap seconds (though

Williams, et al.         Expires August 31, 2012               [Page 12]
Internet-Draft         RTP Clock Source Signalling         February 2012

   the ITU is studying a proposal which could eventually eliminate leap
   seconds from UTC).

   Leap seconds are potentially scheduled at the end of the last day of
   December and June each year.  NTP inserts a leap second at the
   beginning of the last second of the day.  This results in the clock
   freezing for one second immediately prior to the last second of the
   affected day.  Most system clocks insert the leap second at the end
   of the last second.  This results in repetition of the last second of
   the day.  Generating or using timestamps during the entire last
   second of a day on which a leap second has been scheduled should
   therefore be avoided.  Note that the period to be avoided has a real-
   time duration of two seconds.

   It is also important that all participants correctly implement leap
   seconds and have a working communications channel to receive
   notification of leap second scheduling.  Without prior knowledge of
   leap second schedule, NTP servers and clients may be offset by
   exactly one second with respect to their UTC reference.  This
   potential discrepancy begins when a leap second occurs and ends when
   all participants receive a time update from a server or peer (which,
   depending on the operating system and/or implementation, could be
   anywhere from a few minutes to a week).  Such a long-lived
   discrepancy can be particularly disruptive to RTP operation.

   Apart from the long-lived discrepancy due to dependence on both
   timing (e.g.  NTP) updates and leap seconds scheduling updates, there
   is also the potential for a short-lived timing discontinuity having
   an effect on RTP playout timing (even though leap seconds are quite
   rare).

   If a timescale with leap seconds is used for RTP:

   o  RTP Senders using a leap-second-bearing reference must not
      generate sender reports (SR) containing an originating NTP
      timestamp in the vicinity of a leap second.  Receivers should
      ignore timestamps in any such reports inadvertently generated.

   o  Receivers working to a leap-second-bearing reference must be
      careful to take leap seconds into account if a leap second occurs
      between the time a RTP packet is originated and when it is to be
      presented.

6.  Media Clock Source Signalling

   A timestamp clock source (ie media clock is locked to a reference
   clock like NTP, GPS, etc) Reference clock source..

Williams, et al.         Expires August 31, 2012               [Page 13]
Internet-Draft         RTP Clock Source Signalling         February 2012

   An RTP session..  This should be an SSRC within an RTP session.
   Include IP address and port.

   An IEEE 1722 stream, identified by a Stream ID.

7.  IANA Considerations

   The SDP attribute "ts-clksrc" defined by this document is registered
   with the IANA registry of SDP Parameters as follows:

   SDP Attribute ("att-field"):

     Attribute name:     ts-refclk

     Long form:          Timestamp reference clock source

     Type of name:       att-field

     Type of attribute:  session, media and source level

     Subject to charset: no

     Purpose:            See sections 1-4 of this document

     Reference:          This document

     Values:             see this document and registrations below

   The attribute has an extensible parameter field and therefore a
   registry for these parameters is required.  This document creates an
   IANA registry called the Timestamp Reference Clock Source Parameters
   Registry.  It contains the six parameters defined in Figure 1: "ntp",
   "ptp", "gps", "gal", "local", "private".

8.  Acknowledgements

9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media

Williams, et al.         Expires August 31, 2012               [Page 14]
Internet-Draft         RTP Clock Source Signalling         February 2012

        Attributes in the Session Description Protocol (SDP)", RFC 5576,
        June 2009.

   [3]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

9.2.  Informative References

   [4]  Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
        Montagud, M., and K. Gross, "RTCP for inter-destination media
        synchronization", draft-ietf-avtcore-idms-02 (work in progress),
        October 2011.

   [5]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time
        Protocol Version 4: Protocol and Algorithms Specification",
        RFC 5905, June 2010.

   [6]  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>.

   [7]  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>.

   [8]  "Timing and Synchronization for Time-Sensitive Applications in
        Bridged Local Area Networks",
        <http://standards.ieee.org/findstds/standard/802.1AS-2011.html>.

URIs

   [9]   <http://en.wikipedia.org/wiki/Genlock>

   [10]  <http://en.wikipedia.org/wiki/Word_clock>

   [11]  <http://www.ieee802.org/1/files/public/docs2007/
         as-dolsen-time-accuracy-0407.pdf>

Appendix A.  An Appendix

Williams, et al.         Expires August 31, 2012               [Page 15]
Internet-Draft         RTP Clock Source Signalling         February 2012

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/

   Ray van Brandenburg
   TNO
   Brassersplein 2
   Delft,
   The Netherlands

   Phone: +31 88 86 63609
   Fax:
   Email: ray.vanbrandenburg@tno.nl
   URI:

   Kevin Gross
   AVA Networks

   Phone:
   Fax:
   Email:
   URI:

Williams, et al.         Expires August 31, 2012               [Page 16]