diff options
Diffstat (limited to 'doc/rfc/rfc7273.txt')
| -rw-r--r-- | doc/rfc/rfc7273.txt | 1683 |
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] + |