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
AbstractNTP 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.
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
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. RFC2119].
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.
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. RFC5905] and PTP [IEEE1588-2008]) and radio clocks (e.g., GPS [IS-GPS-200F]).
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. 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.
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
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. 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.
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. 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>
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"
gal = "gal" glonass = "glonass" local = "local" private = "private" [ ":traceable" ] EUI64 = 7(2HEXDIG "-") 2HEXDIG Figure 1: Timestamp Reference Clock Source Signalling 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 firstname.lastname@example.org (Jane Doe) c=IN IP4 22.214.171.124/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. 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 email@example.com (Jane Doe) c=IN IP4 126.96.36.199/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 firstname.lastname@example.org (Jane Doe) c=IN IP4 188.8.131.52/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
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
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>]
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.
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> 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
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
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 184.108.40.206/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 220.127.116.11/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 18.104.22.168/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 22.214.171.124/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 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).
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. RFC5939]. Section 4.6) specification in the SDP description.
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. Section 5.1) specification SHOULD be included in the rejection. 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.
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).
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.
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.
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 | +---------+------------------------------+--------------------------+
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 | | +----------+-----------------------------+--------------------------+ RFC5576] requires new source-level attributes to be registered with the IANA registry named "att-field (source level)". Figure 10. Figure 11.
[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.
[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. [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>.
[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/>.
http://www.audinate.com/ Kevin Gross AVA Networks Boulder, CO US EMail: email@example.com URI: http://www.avanw.com/ Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 EMail: firstname.lastname@example.org Hans Stokking TNO Brassersplein 2 Delft 2612CT The Netherlands EMail: email@example.com