Audio/Video Transport Core                                   A. Williams Maintenance                                                     Audinate                     A.M. Williams
Internet-Draft                                                  K. Gross                                                  Audinate
Intended status: Standards Track                            AVA Networks                                K. Gross
Expires: September 19, November 10, 2013                                  AVA Networks
                                                      R. van Brandenburg
                                                             H.
                                                           H.M. Stokking
                                                                     TNO
                                                          March 18,
                                                            May 09, 2013

                      RTP Clock Source Signalling
                      draft-ietf-avtcore-clksrc-03
                      draft-ietf-avtcore-clksrc-04

Abstract

   NTP format timestamps are used by several RTP protocols for
   synchronisation and statistical measurements.  This memo specifies
   SDP signalling identifying timestamp reference 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]. [RFC2119].

Status of this 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 September 19, November 10, 2013.

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3   2
   2.  Applications  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Timestamp Reference Clock Source Signalling . . . . . . . . .   5
     4.1.  Clock synchronization . . . . . . . . . . . . . . . . . .   5
     4.2.  Identifying NTP Reference Clocks  . . . . . . . . . . . . .   6
     4.3.  Identifying PTP Reference Clocks  . . . . . . . . . . . . .   6
     4.4.  Identifying Global Reference Clocks . . . . . . . . . . .  7   8
     4.5.  Other Reference Clocks  . . . . . . . . . . . . . . . . . .   8
     4.6.  Traceable Reference Clocks  . . . . . . . . . . . . . . . .   8
     4.7.  SDP Signalling of Timestamp Reference Clock Source  . . . . . . . . .   8
       4.7.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . 11  10
   5.  Media Clock Source Signalling . . . . . . . . . . . . . . . . 12  11
     5.1.  Asynchronously Generated Media Clock  . . . . . . . . . . .  12
     5.2.  Direct-Referenced Media Clock . . . . . . . . . . . . . .  12
     5.3.  Stream-Referenced Media Clock . . . . . . . . . . . . . .  13
     5.4.  SDP Signalling of Media Clock Source  . . . . . . . . . . .  14
     5.5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 16  15
   6.  Signalling considerations . . . . . . . . . . . . . . . . . .  17
     6.1.  Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18  17
     6.2.  Usage Outside of Offer/Answer . . . . . . . . . . . . . .  18
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Reference clock registry  . . . . . . . . . . . . . . . .  19
     8.2.  Media clock registry  . . . . . . . . . . . . . . . . . .  19
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . .  20
     9.2.  Informative References  . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 22  23

1.  Introduction

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

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

   High performance AV systems often use a reference media clock
   distributed to all devices in the system.  The reference media clock
   is often distinct from the reference clock used to provide
   timestamps.  A reference media clock may be provided along with an
   audio or video signal interface, or via a dedicated clock signal
   (e.g.  genlock [9] [SMPTE-318-1999] or audio word clock [10]). [AES11-2009]).
   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 reference
   clock sources and media reference clock sources.

2.  Applications

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

   Examples include, but are not limited to:

   Social TV  : RTCP for inter-destination media synchronization [11]
      [I-D.ietf-avtcore-idms] defines social TV as the combination of
      media content consumption by two or more users at different
      devices and locations and real-
      time 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 synchronized, the effect of multiple screens
      acting as one is broken.

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

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

3.  Definitions

   The following definitions are used in this draft:

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

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

   RTP media stream  : A single stream of RTP packets identified by an
      RTP SSRC.

   RTP media sender  : The device generating an associated RTP media
      stream

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

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

   source level  : Source level information applies to a RTP media
      stream Source-Specific Media Attributes in the Session Description
      Protocol (SDP) [3] [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
      synchronized to TAI.  UTC is therefore also considered traceable
      time once leap seconds have been taken unto account.  GPS [12]
      [IS-GPS-200F] is commonly used to provide a TAI traceable time
      reference.  Some network time synchronisation protocols (e.g.  PTP [13],
      [IEEE1588-2008], 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 [14], [RFC5905], PTP [13]) [IEEE1588-2008]) and radio clocks
   (e.g.  GPS
   [12]). [IS-GPS-200F]).

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

4.1.  Clock synchronization

   Two or more local clocks that are sufficiently synchronised will
   produce timestamps for a given RTP event can be used as if they came
   from the same clock.  Providing they are sufficiently synchronised,
   timestamps produced in one RTP sender or receiver can be directly
   compared to a local clock in another RTP sender or receiver.

   The accuracy of synchronisation required is application dependent.
   See Applications (Section 2) section for a discussion of applications
   and their corresponding requirements.  To serve as a reference clock,
   clocks must minimally be syntonised (exactly frequency matched) to
   one another.

   Sufficient synchronisation can typically be achieving by using a
   network time protocol (e.g.  NTP, 802.1AS, IEEE 1588-2008) to
   synchronize all devices to a single master clock.

   Another approach is to use clocks providing a global time reference
   (e.g.  GPS, Galileo).  This concept may be used in conjunction with
   network time protocols as some protocols (e.g.  PTP, NTP) allow
   master clocks to indicate explicitly that they are providing
   traceable time.

4.2.  Identifying NTP Reference Clocks

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

   Two or more NTP servers may MAY be listed at the same level in the
   session description to indicate that they are interchangeable. all of the listed servers
   deliver the same reference time and may be used interchangeably.  RTP
   senders or and receivers can use any are assured proper synchronization regardless
   of the listed NTP which server they choose and, in support of fault tolerance, may
   switch servers to govern
   a local clock that is equivalent to a local clock slaved to a
   different server. while streaming.

4.3.  Identifying PTP Reference Clocks

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

   Three flavours of IEEE 1588 are in use today:

   o  IEEE 1588-2002 [15]: [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 [13]: [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 [16]: [IEEE802.1AS-2011]: "Timing and Synchronization for
      Time Sensitive Applications in Bridged Local Area Networks".  This
      is a Layer-2 only profile of IEEE 1588-2008 for use in Audio/Video
      Bridged LANs as described in IEEE 802.1BA-2011 [17]. [IEEE802.1BA-2011].

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

   Several instances of the IEEE 1588 protocol may operate independently
   on a single network, forming distinct PTP domains, each of which may
   have a different grandmaster clock.  As the IEEE 1588 standards have
   developed, the definition of PTP domains has changed.  IEEE 1588-2002
   identifies protocol subdomains by a textual name, but IEEE 1588-2008
   identifies protocol domains using a numeric domain number.  802.1AS
   is a Layer-2 profile of IEEE 1588-2008 supporting a single numeric
   clock domain (0).

   When PTP domains are signalled via SDP, senders and receivers SHOULD
   check that both grandmaster ClockIdentity and PTP domain match when
   determining clock equivalence.

   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
   receivers are assured proper synchronization regardless of which
   synchronization source they choose and, in support of fault
   tolerance, may switch refence 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 and
   Galileo.  Apart from the name of the reference clock system, no
   further identification is required.

4.5.  Other Reference Clocks

   RFC 3550 allows senders and receivers to either use a local wallclock
   reference for their NTP timestamps or, by setting the timestamp field
   to 0, to supply no timestamps at all.  Both are common practice in
   embedded RTP implementations.  These clocks are identified as "local"
   and can only be assumed to be equivalent to clocks originating from
   the same device.

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

4.6.  Traceable Reference Clocks

   A timestamp reference clock source may be labelled "traceable" if it
   is known to be to delivering traceable time.  Providing adjustments
   are made for differing epochs, timezones and leap seconds, timestamps
   taken using clocks synchronised to a traceable time source can be
   directly compared even if the clocks are synchronised to different
   sources or via different mechanisms.

   Since all NTP and PTP servers providing traceable time can be
   directly compared, it is not necessary to identify traceable time
   servers by protocol address or other identifiers.

4.7.  SDP Signalling of Timestamp 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 (Section 3) earlier in this document for more
   information).

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

   If timestamp 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 clock master election.  The SIP [4]
   [RFC3261] protocol supports re-signalling of updated SDP information,
   however other protocols may require additional notification
   mechanisms.

   Figure 1 shows the ABNF [5] [RFC5234] grammar for the SDP reference clock
   source information.

    timestamp-refclk = "a=ts-refclk:" clksrc CRLF
    clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext

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

    ptp             =  "ptp=" ptp-version ":" ptp-server
    ptp-version     =  "IEEE1588-2002"
    ptp-version     =/ "IEEE1588-2008"
    ptp-version     =/ "IEEE802.1AS-2011"
    ptp-version     =/  ptp-version-ext
    ptp-version-ext =   token

    ptp-server      =  ptp-gmid [":" ptp-domain] / "traceable"
    ptp-gmid        =  EUI64
    ptp-domain      =  ptp-domain-name / ptp-domain-nmbr
    ptp-domain-name =  "domain-name=" 16ptp-domain-char
    ptp-domain-char =  %x21-7E / %x00
                       ; allowed characters: 0x21-0x7E (IEEE 1588-2002)
    ptp-domain-nmbr =  "domain-nmbr=" %x00-7f
                       ; allowed number range: 0-127 (IEEE 1588-2008)

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

    clksrc-ext  = token

    host          = hostname / IPv4address / IPv6reference
    hostname      =  *( domainlabel "." ) toplabel [ "." ]
    toplabel      =  ALPHA / ALPHA *( alphanum / "-" ) alphanum
    domainlabel   =  alphanum
                     / alphanum *( alphanum / "-" ) alphanum
    IPv4address   =  1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
    IPv6reference =  "[" IPv6address "]"
    IPv6address   =  hexpart [ ":" IPv4address ]
    hexpart       =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
    hexseq        =  hex4 *( ":" hex4)
    hex4          =  1*4HEXDIG

    port = 1*DIGIT

    EUI64 = 7(2HEXDIG "-") 2HEXDIG

           Figure 1: Timestamp Reference Clock Source Signalling

4.7.1.  Examples

   Figure 2 shows an example SDP description with a timestamp reference
   clock source defined at the session level.

              v=0
              o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
              s=SDP Seminar
              i=A Seminar on the session description protocol
              u=http://www.example.com/seminars/sdp.pdf
              e=j.doe@example.com (Jane Doe)
              c=IN IP4 233.252.0.1/64
              t=2873397496 2873404696
              a=recvonly
              a=ts-refclk:ntp=traceable
              m=audio 49170 RTP/AVP 0
              m=video 51372 RTP/AVP 99
              a=rtpmap:99 h263-1998/90000

    Figure 2: Timestamp reference clock definition at the session level

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

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

     Figure 3: Timestamp reference clock definition at the media level

   Figure 4 shows an example SDP description with a timestamp reference
   clock definition at the source level overriding the session level
   default.

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
    s=SDP Seminar
    i=A Seminar on the session description protocol
    u=http://www.example.com/seminars/sdp.pdf
    e=j.doe@example.com (Jane Doe)
    c=IN IP4 233.252.0.1/64
    t=2873397496 2873404696
    a=recvonly
    a=ts-refclk:local
    m=audio 49170 RTP/AVP 0
    m=video 51372 RTP/AVP 99
    a=rtpmap:99 h263-1998/90000
    a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0

    Figure 4: Timestamp reference clock signalling at the source level

5.  Media Clock Source Signalling

   The media clock source for a stream determines the timebase used to
   advance the RTP timestamps included in RTP packets.  The media clock
   may be asynchronously generated by the sender, it may be generated in
   fixed relationship to the reference clock or it may be generated with
   respect to another stream on the network (which is presumably being
   received by the sender).

5.1.  Asynchronously Generated Media Clock

   In the simplest sender implementation, the sender generates media by
   sampling audio or video according to a free-running local clock.  The
   RTP timestamps in media packets are advanced according to this media
   clock and packet transmission is typically timed to regular intervals
   on this timeline.  The sender may or may not include an NTP timestamp
   in sender reports to allow mapping of this asynchronous media clock
   to a reference clock.

   The asynchronously generated media clock is the assumed mode of
   operation when there is no signalling of media clock source.
   Alternatively, asynchronous media clock may be explicitly signalled.

      a=mediaclk:sender

5.2.  Direct-Referenced Media Clock

   A media clock may be directly derived from a reference clock.  For
   this case it is required that a reference clock be specified with an
   a=ts-refclk attribute (Section 4.7).

   The signalling optionally indicates a media clock offset value.  The
   offset indicates the RTP timestamp value at the epoch (time of
   origin) of the reference clock.  If no offset is signalled, the
   offset can be inferred at the receiver by examining RTCP sender
   reports which contain NTP and RTP timestamps which combined define a
   mapping.

   A rate modifier may be specified.  The modifier is expressed as the
   ratio of two integers and modifies the rate specified or implied by
   the media description by this ratio.  If omitted, the rate is assumed
   to be the exact rate specified or implied by the media format.  For
   example, without a rate specification, the media clock for an 8 kHz
   G.711 audio stream will advance exactly 8000 units for each second
   advance in the reference clock from which it is derived.

   The rate modifier is primarily useful for accommodating certain
   "oddball" audio sample rates associated with NTSC video (see Figure
   7).  Modified rates are not advised for video streams which generally
   use a 90 kHz RTP clock regardless of frame rate or sample rate used
   for embedded audio.

      a=mediaclk:direct[=<offset>] [rate=<rate numerator>/<rate
      denominator>]

5.3.  Stream-Referenced Media Clock

   A common synchronisation architecture for audio/visual systems
   involves distributing a reference media clock from a master device to
   a number of slave devices, typically by means of a cable.  Examples
   include audio word clock distribution and video black burst
   distribution.  In this case, the media clock is locally generated,
   often by a crystal oscillator and is not locked to a timestamp
   reference clock.

   To support this architecture across a network, a master clock
   identifier is associated with an RTP media stream carrying media
   clock timing information from a master device.  The master clock
   identifier represents a media clock source in the master device.
   Slave devices in turn associate the master media clock identifier
   with streams they transmit, signalling the synchronisation
   relationship between the master and slave devices.

   Slave devices recover media clock timing from the clock master
   stream, using it to synchronise the slave media clock with the
   master.  Timestamps in the master clock RTP media stream are taken
   using the timestamp reference clock shared by the master and slave
   devices.  The timestamps communicate information about media clock
   timing (rate, phase) from the master to the slave devices.
   Timestamps are communicated in the usual RTP fashion via RTCP SRs, or
   via the RFC6051 [6] [RFC6051] header extension.  The stream media format
   may indicate other clock information, such as the nominal rate.

   Note that slaving of a device media clock to a master device does not
   affect the usual RTP lip sync / time alignment algorithms.  Time
   aligned playout of two or more RTP sources still relies upon NTP
   timestamps supplied via RTCP SRs or by the RFC6051 timestamp header
   extension.

   In a given system, master clock identifiers must be unique.  Such
   identifiers MAY be manually configured, however 17 octet string
   identifiers SHOULD be generated according to the "short-term
   persistent RTCP CNAME" algorithm as described in RFC6222 [7]. [RFC6222].

   A reference stream can be an RTP stream or AVB stream based on the
   IEEE 1722 [18] [IEEE1722] standard.

   An RTP clock master stream SHOULD be identified at the source level
   by an SSRC and master clock identifier.  If master clock identifiers
   are declared at the media or session level, all RTP sources at or
   below the level of declaration MUST provide equivalent timing to a
   slave receiver.

      a=ssrc:<media-clock-master-ssrc-id> mediaclk:master-id=<media-
      clock-master-id>

   An RTP media sender indicates that it is slaved to a clock master via
   a clock master identifier:

      a=mediaclk:master-id=<media-clock-master-id>

   An RTP media sender indicates that it is slaved to an IEEE 1722 clock
   master via a stream identifier (an EUI-64):

      a=mediaclk:IEEE1722=<StreamID>

5.4.  SDP Signalling of Media Clock Source

   Specification of the media clock source may be at any or all levels
   (session, media or source) of an SDP description (see level
   definitions (Section 3) earlier in this document for more
   information).

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

   Media clock source signalling may be present or absent on a per-
   stream basis.  In the absence of media clock source signals,
   receivers assume an asynchronous media clock generated by the sender.

   Media clock source parameters may be repeated at a given level (i.e.
   for a session or source) to provide information about additional
   clock sources.  If the attribute is repeated at a given level, all
   clocks described at that level are comparable clock sources and may
   be used interchangeably.

   Figure 5 shows the ABNF [5] [RFC5234] grammar for the SDP media clock
   source information.

         mediaclk-master = "a=ssrc:" integer SP clk-master-id

         clk-master-id = "mediaclk:master-id=" master-id

         timestamp-mediaclk = "a=mediaclk:" mediaclock
         mediaclock = sender / refclk / streamid / mediaclock-ext

         sender = "sender" sender-ext

         sender-ext = token

         refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext]

         rate = [ SP "rate=" integer "/" integer ]

         direct-ext = token

         streamid = "master-id=" master-id
         streamid =/ "IEEE1722=" avb-stream-id
         streamid =/ streamid-ext

         master-id = EUI48
         avb-stream-id = EUI64

         EUI48 = 5(2HEXDIG ":") 2HEXDIG
         EUI64 = 7(2HEXDIG ":") 2HEXDIG

         streamid-ext = token

         mediaclock-ext = token [SP byte-string]

                  Figure 5: Media Clock Source Signalling

5.5.  Examples

   Figure 6 shows an example SDP description 8 channels of 24-bit, 48
   kHz audio transmitted as a multicast stream.  Media clock is derived
   directly from an IEEE 1588-2008 reference.

          v=0
          o=- 1311738121 1311738121 IN IP4 192.0.2.1
          c=IN IP4 233.252.0.1/64
          s=
          t=0 0
          m=audio 5004 RTP/AVP 96
          a=rtpmap:96 L24/48000/8
          a=sendonly
          a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
          a=mediaclk:direct=963214424

        Figure 6: Media clock directly referenced to IEEE 1588-2008

   Figure 7 shows an example SDP description 2 channels of 24-bit, 44056
   kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-
   2008
   1588-2008 reference clock

          v=0
          o=- 1311738121 1311738121 IN IP4 192.0.2.1
          c=IN IP4 233.252.0.1/64
          s=
          t=0 0
          m=audio 5004 RTP/AVP 96
          a=rtpmap:96 L24/44100/2
          a=sendonly
          a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
          a=mediaclk:direct=963214424 rate=1000/1001

   Figure 7: "Oddball" sample rate directly referenced to IEEE 1588-2008

   Figure 8 shows the same 48 kHz audio transmission from Figure 6 with
   media clock derived from another RTP stream.

          v=0
          o=- 1311738121 1311738121 IN IP4 192.0.2.1
          c=IN IP4 233.252.0.1/64
          s=
          t=0 0
          m=audio 5004 RTP/AVP 96
          a=rtpmap:96 L24/48000/2
          a=sendonly
          a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
          a=mediaclk:master-id=00:60:2b:20:12:1f

      Figure 8: RTP stream with media clock slaved to a master device

   Figure 9 shows the same 48 kHz audio transmission from Figure 6 with
   media clock derived from an IEEE 1722 AVB stream.

          v=0
          o=- 1311738121 1311738121 IN IP4 192.0.2.1
          c=IN IP4 233.252.0.1/64
          s=
          t=0 0
          m=audio 5004 RTP/AVP 96
          a=rtpmap:96 L24/48000/2
          a=sendonly
          a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
          a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F

    Figure 9: RTP stream with media clock slaved to an IEEE1722 master
                                  device

6.  Signalling considerations

   Signaling for timestamp reference clock source (Section 4.7) and
   media clock source (Section 5.4) is defined to be used either by
   applications that implement the SDP Offer/Answer model [8] [RFC3264] or
   by applications that use SDP to describe media and transport
   configurations.

   A description or offer may include reference clock signalling, media
   clock signalling neither or both.  If no reference clock is specified, the  When a direct-referenced media
   clock (Section 5.2) is not allowed. specified, reference clock signalling is
   REQUIRED.  If no media clock is specified, signalled, an asynchronous media
   clock (Section 5.1) is assumed.  Asynchronous and stream-referenced
   media clock clocks (Section 5.3) may be used with or without a reference
   clock specification. signalling.  If a reference clock is not signalled, the stream
   corresponding media clock may be established as rate synchronized however
   with no assurance of time synchronisation is not guaranteed. synchronisation.

6.1.  Usage in Offer/Answer

   Usage of reference clock and media clock signalling in offer/answer
   allows the offerer to declare the reference clock and media clock in
   use and allows the answerer to acknowledge that a connection
   according to these declarations will be successful or, in limited
   cases described below, specify a simplified synchronization mode.

   While full negotiation of reference clock and media clock attributes
   is not directly supported in the clock source signalling defined in
   this document, negotiation MAY be accomplished using capabilities
   negotiation procedures defined in [RFC5939].

   An answer to an offer with direct-referenced media clock and
   reference clock specification must SHOULD
   include the same media clock and reference clock signalling in which
   case a connection is established using the specified synchronisation.

   Alternatively the answer may MAY omit both the signals or return include only the
   reference clock
   specification. specified in the offer.  In this case, a connection is established assuming an
   with asynchronous media clock. clock is established.

   An answer to an offer with media-referenced stream-referenced media clock specification
   must signalling
   SHOULD include the same media clock specification.  The  If the offer
   contains reference clock signalling, the answer MUST SHOULD include the
   same reference clock signalling or may drop the specification.  The answer MAY omit reference
   clock signalling.  If reference clock signalling is not present in
   the answer, either due to not being present in the offer or due to
   being dropped by in the answerer, answer, the stream may be established as rate
   synchronized
   synchronised but not time synchronized. synchronised.

   An asynchronous media clock is the default media clock mode.  This
   mode may be explicitly signalled (a=mediaclk:sender) or presumed due
   to lack of signalling.  Asynchronous  If explicit signalling of asynchronous media clocking does not require reference
   clock signalling. is included in the offer, it SHOULD also be included in the
   answer.  An offer with asynchronous media clocking MAY include
   reference clock signalling.  Because the  An answer to an asynchronous media clock is
   offer with reference clock signalling SHOULD include the default mode, same
   reference clock specification.  Alternatively, the answerer is not required to explicitly
   signal this even if it is explicitly signalled answer MAY drop
   reference clock signalling in which case the offer. connection may be
   established as rate synchronised but not time synchronised.

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) [19], [RFC2974], or streamed through the Real
   Time Streaming Protocol (RTSP) [20]. [RFC2326].  The signaling model is
   simpler, as the sender does not negotiate parameters, but the
   functionality expected from specifying medial media clock and reference
   clock attributes is the same as in Offer/Answer.

7.  Security Considerations

   Entities receiving and acting upon an SDP message SHOULD be aware
   that a session description cannot be trusted unless it has been
   obtained by an authenticated transport protocol from a known and
   trusted source.  Many different transport protocols may be used to
   distribute session description, and the nature of the authentication
   will differ from transport to transport.  For some transports,
   security features are often not deployed.  In case a session
   description has not been obtained in a trusted manner, the endpoint
   SHOULD exercise care because, among other attacks, the media sessions
   received may not be the intended ones, the destination where media is
   sent to may not be the expected one, any of the parameters of the
   session may be incorrect.

   Incorrect reference or media clock parameters may cause devices or
   streams to synchronize to unintended clock sources.  Normally this
   simply results in failure to make a media connection or failure to
   synchronize once connected.  Enough devices fraudulently assigned to
   a specific clock source (e.g.  a particular IEEE 1588 grandmaster)
   may, however, constitute a successful a denial of service attack on
   that source.  Devices MAY wish to validate the integrity of the clock
   description through some means before connecting to unfamiliar clock
   sources.

8.  IANA Considerations

8.1.  Reference clock registry

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

   SDP Attribute ("att-field"):

     Attribute name:     ts-refclk

     Long form:          Timestamp reference clock source

     Type of name:       att-field

     Type of attribute:  session,  Session, media and source level

     Subject to charset: no No

     Purpose:            See section 4 of this document

     Reference:          This document

     Values:             see             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".  New entries MAY be added to
   this registry according to well-known Specification Required policy
   [RFC5226].

8.2.  Media clock registry
   The SDP attribute "mediaclk" defined by this document is registered
   with the IANA registry of SDP Parameters as follows:

   SDP Attribute ("att-field"):

     Attribute name:     mediaclk

     Long form:          Media clock source

     Type of name:       att-field

     Type of attribute:  session and media level

     Subject to charset: no No

     Purpose:            See section 5 of this document

     Reference:          This document

     Values:             see             See this document and registrations below

   The attribute has an extensible parameter field and therefore a
   registry for these parameters is required.  This document creates an
   IANA registry called the Media Clock Source Parameters Registry.  It
   contains the three parameters defined in Figure 5: "sender",
   "direct", "master", "slave" and "IEEE1722".  New entries MAY be added
   to this registry according to well-known Specification Required
   policy [RFC5226].

9.  References

9.1.  Normative References

   [1]

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

   [2]

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., Jacobson, V., and C. Perkins, "SDP: E.
              Schooler, "SIP: Session
         Description Initiation Protocol", RFC 4566, July 2006.

   [3]   Lennox, J., Ott, J., 3261,
              June 2002.

   [RFC3264]  Rosenberg, J. and T. Schierl, "Source-Specific Media
         Attributes in the H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 5576, 3264, June 2009.

   [4]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R.,
              2002.

   [RFC4566]  Handley, M., Jacobson, V., and E. Schooler, "SIP: C. Perkins, "SDP: Session Initiation
              Description Protocol", RFC 3261, June 2002.

   [5] 4566, July 2006.

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

   [6]

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

   [RFC5939]  Andreasen, F., "Session Description Protocol (SDP)
              Capability Negotiation", RFC 5939, September 2010.

   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
              Flows", RFC 6051, November 2010.

   [7]

   [RFC6222]  Begen, A., Perkins, C., and D. Wing, "Guidelines for
              Choosing RTP Control Protocol (RTCP) Canonical Names
              (CNAMEs)", RFC 6222, April 2011.

   [8]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

9.2.  Informative References

   [9]   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", <http://standards.smpte.org/>.

   [10]

   [AES11-2009]
              Audio Engineering Society, "AES11-2009: AES recommended
              practice for digital audio engineering - Synchronization
              of digital audio equipment in studio operations", operations ", ,
              <http://www.aes.org/standards/>.

   [11]

   [I-D.ietf-avtcore-idms]
              Brandenburg, R., Stokking, H., Deventer, O., Boronat, F.,
              Montagud, M., and K. Gross, "Inter-destination Media
              Synchronization using the RTP Control Protocol (RTCP)",
         draft-ietf-avtcore-idms-07
              draft-ietf-avtcore-idms-09 (work in progress), October 2012.

   [12]  Global Positioning Systems Directorate, "Navstar GPS Space
         Segment/Navigation User Segment Interfaces", September 2011.

   [13] March 2013.

   [IEEE1588-2002]
              Institute of Electrical and Electronics Engineers, "1588-2008
              "1588-2002 - 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>.

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

   [15] 1588-2002, 2002, <http://
              standards.ieee.org/findstds/standard/1588-2002.html>.

   [IEEE1588-2008]
              Institute of Electrical and Electronics Engineers, "1588-2002
              "1588-2008 - 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>.

   [16] 1588-2008, 2008, <http://
              standards.ieee.org/findstds/standard/1588-2008.html>.

   [IEEE1722]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Layer 2 Transport Protocol for Time Sensitive
              Applications in a Bridged Local Area Network", , <http://
              standards.ieee.org/findstds/standard/1722-2011.html>.

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

   [17] , <http://standards.ieee.org
              /findstds/standard/802.1AS-2011.html>.

   [IEEE802.1BA-2011]
              Institute of Electrical and Electronics Engineers, "Audio
              Video Bridging (AVB) Systems",
         <http://standards.ieee.org/findstds/standard/
         802.1BA-2011.html>.

   [18]  Institute of Electrical , <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", September
              2011.

   [RFC2326]  Schulzrinne, H., Rao, A., and Electronics Engineers, "IEEE
         Standard for Layer 2 Transport Protocol for R. Lanphier, "Real Time Sensitive
         Applications in a Bridged Local Area Network",
         <http://standards.ieee.org/findstds/standard/1722-2011.html>.

   [19]
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

   [20]  Schulzrinne, H., Rao, A.,

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and R. Lanphier, "Real W. Kasch, "Network
              Time Streaming Protocol (RTSP)", Version 4: Protocol and Algorithms
              Specification", RFC 2326, April 1998.

URIs

   [21]  <http://www.ieee802.org/1/files/public/docs2007/
         as-dolsen-time-accuracy-0407.pdf> 5905, June 2010.

   [SMPTE-318-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", ,
              <http://standards.smpte.org/>.

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