| Audio/Video Transport Core Maintenance | A. Williams |
| Internet-Draft | Audinate |
| Intended status: Standards Track | K. Gross |
| Expires: August 23, 2013 | AVA Networks |
| R. van Brandenburg | |
| H. Stokking | |
| TNO | |
| February 19, 2013 |
RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-02
NTP timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying NTP timestamp clock sources and SDP signalling identifying the media clock sources in a multimedia session.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
RTP protocols use NTP format timestamps to facilitate multimedia session synchronisation and for providing estimates of round trip time (RTT) and other statistical parameters.
Information about media clock timing exchanged in NTP format timestamps may come from a clock which is synchronised to a global time reference, but this cannot be assumed nor is there a standardised mechanism available to indicate that timestamps are derived from a common reference clock. Therefore, RTP implementations typically assume that NTP timestamps are taken using unsynchronised clocks and must compensate for absolute time differences and rate differences. Without a shared reference clock, RTP can time align flows from the same source at a given receiver using relative timing, however tight synchronisation between two or more different receivers (possibly with different network paths) or between two or more senders is not possible.
High performance AV systems often use a reference media clock distributed to all devices in the system. The reference media clock is often distinct from the reference clock used to provide timestamps. A reference media clock may be provided along with an audio or video signal interface, or via a dedicated clock signal (e.g. genlock or audio word clock). If sending and receiving media clocks are known to be synchronised to a common reference clock, performance can improved by minimising buffering and avoiding rate conversion.
This specification defines SDP signalling of timestamp clock sources and media reference clock sources.
Timestamp clock source and reference media clock signalling benefit applications requiring synchronised media capture or playout and low latency operation.
Examples include, but are not limited to:
The following definitions are used in this draft:
The NTP 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 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/receiver is synchronised to a reference clock.
Two or more local clocks that are sufficiently synchronised will produce timestamps for a given RTP event can be used as if they came from the same clock. Providing they are sufficiently synchronised, timestamps produced in one RTP sender or receiver can be directly compared to a local clock in another RTP sender or receiver.
The accuracy of synchronisation required is application dependent. See Applications [applications] section for a discussion of applications and their corresponding requirements. To serve as a reference clock, clocks must minimally be syntonised (exactly frequency matched) to one another.
Sufficient synchronisation can typically be achieving by using a network time protocol (e.g. NTP, 802.1AS, IEEE 1588-2008) to synchronize all devices to a single master clock.
Another approach is to use clocks providing a global time reference (e.g. GPS, Galileo). This concept may be used in conjunction with network time protocols as some protocols (e.g. PTP, NTP) allow master clocks to indicate explicitly that they are providing traceable time.
A single NTP server is identified by hostname (or IP address) and an optional port number. If the port number is not indicated, it is assumed to be the standard NTP port (123).
Two or more NTP servers may be listed at the same level in the session description to indicate that they are interchangeable. RTP senders or receivers can use any of the listed NTP servers to govern a local clock that is equivalent to a local clock slaved to a different server.
The IEEE 1588 Precision Time Protocol (PTP) family of clock synchronisation protocols provides a shared reference clock in an network - typically a LAN. IEEE 1588 provides sub-microsecond synchronisation between devices on a LAN and typically locks within seconds at startup. With support from Ethernet switches, IEEE 1588 protocols can achieve nanosecond timing accuracy in LANs. Network interface chips and cards supporting hardware time-stamping of timing critical protocol messages are also available.
Three flavours of IEEE 1588 are in use today:
Each IEEE 1588 clock is identified by a globally unique EUI-64 called a "ClockIdentity". A slave clock using one of the IEEE 1588 family of network time protocols acquires the ClockIdentity/EUI-64 of the grandmaster clock that is the ultimate source of timing information for the network. A boundary clock which is itself slaved to another boundary clock or the grandmaster passes the grandmaster ClockIdentity through to its slaves.
Several instances of the IEEE 1588 protocol may operate independently on a single network, forming distinct PTP domains, each of which may have a different grandmaster clock. As the IEEE 1588 standards have developed, the definition of PTP domains has changed. IEEE 1588-2002 identifies protocol subdomains by a textual name, but IEEE 1588-2008 identifies protocol domains using a numeric domain number. 802.1AS is a Layer-2 profile of IEEE 1588-2008 supporting a single numeric clock domain (0).
When PTP domains are signalled via SDP, senders and receivers SHOULD check that both grandmaster ClockIdentity and PTP domain match when determining clock equivalence.
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 clock sources when the clock master changes.
Global reference clocks provide a source of traceable time, typically via a hardware radio receiver interface. Examples include GPS and Galileo. Apart from the name of the reference clock system, no further identification is required.
RFC 3550 allows senders and receivers to either use a local wallclock reference for their NTP timestamps or, by setting the timestamp field to 0, to supply no timestamps at all. Both are common practice in embedded RTP implementations. These clocks are identified as "local" and can only be assumed to be equivalent to clocks originating from the same device.
In other systems, all RTP senders and receivers may use a timestamp clock synchronised to a reference clock that is not provided by one of the methods listed above. Examples may include the reference time information provided by digital television or cellular services. These sources are identified as "private" reference clocks. All RTP senders and receivers in a session using a private reference clock are assumed to have a mechanism outside this specification for determining whether their timestamp clocks are equivalent.
A timestamp clock source may be labelled "traceable" if it is known to be to delivering traceable time. Providing adjustments are made for differing epochs, timezones and leap seconds, timestamps taken using clocks synchronised to a traceable time source can be directly compared even if the clocks are synchronised to different sources or via different mechanisms.
Since all NTP and PTP servers providing traceable time can be directly compared, it is not necessary to identify traceable time servers by protocol address or other identifiers.
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 [definitions] earlier in this document for more information).
Timestamp clock source signalling included at session-level provides default parameters for all RTP sessions and sources in the session description. More specific signalling included at the media level overrides default session level signalling. More specific signalling included at the source level overrides default media level signalling.
If timestamp clock source signalling is included anywhere in an SDP description, it must be properly defined for all levels in the description. This may simply be achieved by providing default signalling at the session level.
Timestamp reference clock parameters may be repeated at a given level (i.e. for a session or source) to provide information about additional servers or clock sources. If the attribute is repeated at a given level, all clocks described at that level are assumed to be equivalent. Traceable time sources MUST NOT be mixed with non-traceable time sources at any given level.
Note that clock source parameters may change from time to time, for example, as a result of a PTP clock master election. The SIP [RFC3261] protocol supports re-signalling of updated SDP information, however other protocols may require additional notification mechanisms.
Figure 1 shows the ABNF [RFC5234] grammar for the SDP reference clock source information.
timestamp-refclk = "a=ts-refclk:" clksrc CRLF
clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext
ntp = "ntp=" ntp-server-addr
ntp-server-addr = host [ ":" port ]
ntp-server-addr =/ "traceable"
ptp = "ptp=" ptp-version ":" ptp-server
ptp-version = "IEEE1588-2002"
ptp-version =/ "IEEE1588-2008"
ptp-version =/ "IEEE802.1AS-2011"
ptp-version =/ ptp-version-ext
ptp-version-ext = token
ptp-server = ptp-gmid [":" ptp-domain] / "traceable"
ptp-gmid = EUI64
ptp-domain = ptp-domain-name / ptp-domain-nmbr
ptp-domain-name = "domain-name=" 16ptp-domain-char
ptp-domain-char = %x21-7E / %x00
; allowed characters: 0x21-0x7E (IEEE 1588-2002)
ptp-domain-nmbr = "domain-nmbr=" %x00-7f
; allowed number range: 0-127 (IEEE 1588-2008)
gps = "gps"
gal = "gal"
local = "local"
private = "private" [ ":" "traceable" ]
clksrc-ext = token
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
EUI64 = 7(2HEXDIG "-") 2HEXDIG
Figure 1: Timestamp Reference Clock Source Signalling
Figure 2 shows an example SDP description with a timestamp reference clock source defined at the session level.
v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/64 t=2873397496 2873404696 a=recvonly a=ts-refclk:ntp=traceable m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000
Figure 2: Timestamp reference clock definition at the session level
Figure 3 shows an example SDP description with timestamp reference clock definitions at the media level overriding the session level defaults. Note that the synchronisation confidence timestamp appears on the first attribute at the media level only.
v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/64 t=2873397496 2873404696 a=recvonly a=ts-refclk:local m=audio 49170 RTP/AVP 0 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 a=ts-refclk:ntp=198.51.100.22 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 3: Timestamp reference clock definition at the media level
Figure 4 shows an example SDP description with a timestamp reference clock definition at the source level overriding the session level default.
v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/64 t=2873397496 2873404696 a=recvonly a=ts-refclk:local m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=ssrc:12345 ts-refclk:ptp=IEEE802.1AS-2011:39-A7-94-FF-FE-07-CB-D0
Figure 4: Timestamp reference clock signalling at the source level
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).
In the simplest sender implementation, the sender generates media by sampling audio or video according to a free-running local clock. The RTP timestamps in media packets are advanced according to this media clock and packet transmission is typically timed to regular intervals on this timeline. The sender may or may not include an NTP timestamp in sender reports to allow mapping of this asynchronous media clock to a reference clock.
The asynchronously generated media clock is the assumed mode of operation when there is no signalling of media clock source. Alternatively, asynchronous media clock may be explicitly signalled.
A media clock may be directly derived from a reference clock. For this case it is required that a reference clock be specified with an a=ts-refclk attribute (Section 4.7).
The signalling optionally indicates a media clock offset value. The offset indicates the RTP timestamp value at the epoch (time of origin) of the reference clock. If no offset is signalled, the offset can be inferred at the receiver by examining RTCP sender reports which contain NTP and RTP timestamps which combined define a mapping.
A rate modifier may be specified. The modifier is expressed as the ratio of two integers and modifies the rate specified or implied by the media description by this ratio. If omitted, the rate is assumed to be the exact rate specified or implied by the media format. For example, without a rate specification, the media clock for an 8 kHz G.711 audio stream will advance exactly 8000 units for each second advance in the reference clock from which it is derived.
The rate modifier is primarily useful for accommodating certain "oddball" audio sample rates associated with NTSC video (see Figure 7). Modified rates are not advised for video streams which generally use a 90 kHz RTP clock regardless of frame rate or sample rate used for embedded audio.
A common synchronisation architecture for audio/visual systems involves distributing a reference media clock from a master device to a number of slave devices, typically by means of a cable. Examples include audio word clock distribution and video black burst distribution. In this case, the media clock is locally generated, often by a crystal oscillator and is not locked to a timestamp reference clock.
To support this architecture across a network, a master clock identifier is associated with an RTP media stream carrying media clock timing information from a master device. The master clock identifier represents a media clock source in the master device. Slave devices in turn associate the master media clock identifier with streams they transmit, signalling the synchronisation relationship between the master and slave devices.
Slave devices recover media clock timing from the clock master stream, using it to synchronise the slave media clock with the master. Timestamps in the master clock RTP media stream are taken using the timestamp reference clock shared by the master and slave devices. The timestamps communicate information about media clock timing (rate, phase) from the master to the slave devices. Timestamps are communicated in the usual RTP fashion via RTCP SRs, or via the RFC6051 [RFC6051] header extension. The stream media format may indicate other clock information, such as the nominal rate.
Note that slaving of a device media clock to a master device does not affect the usual RTP lip sync / time alignment algorithms. Time aligned playout of two or more RTP sources still relies upon NTP timestamps supplied via RTCP SRs or by the RFC6051 timestamp header extension.
In a given system, master clock identifiers must be unique. Such identifiers MAY be manually configured, however 17 octet string identifiers SHOULD be generated according to the "short-term persistent RTCP CNAME" algorithm as described in RFC6222 [RFC6222].
A reference stream can be an RTP stream or AVB stream based on the IEEE 1722 [IEEE1722] standard.
An RTP clock master stream SHOULD be identified at the source level by an SSRC and master clock identifier. If master clock identifiers are declared at the media or session level, all RTP sources at or below the level of declaration MUST provide equivalent timing to a slave receiver.
An RTP media sender indicates that it is slaved to a clock master via a clock master identifier:
An RTP media sender indicates that it is slaved to an IEEE 1722 clock master via a stream identifier (an EUI-64):
Specification of the media clock source may be at any or all levels (session, media or source) of an SDP description (see level definitions (Section 3) earlier in this document for more information).
Media clock source signalling included at session level provides default parameters for all RTP sessions and sources in the session description. More specific signalling included at the media level overrides default session level signalling. Further, source-level signalling overrides media clock source signalling at the enclosing media level and session level.
Media clock source signalling may be present or absent on a per-stream basis. In the absence of media clock source signals, receivers assume an asynchronous media clock generated by the sender.
Media clock source parameters may be repeated at a given level (i.e. for a session or source) to provide information about additional clock sources. If the attribute is repeated at a given level, all clocks described at that level are comparable clock sources and may be used interchangeably.
Figure 5 shows the ABNF [RFC5234] grammar for the SDP media clock source information.
mediaclk-master = "a=ssrc:" integer SP clk-master-id
clk-master-id = "mediaclk:master-id=" master-id
timestamp-mediaclk = "a=mediaclk:" mediaclock
mediaclock = sender / refclk / streamid / mediaclock-ext
sender = "sender" sender-ext
sender-ext = token
refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext]
rate = [ SP "rate=" integer "/" integer ]
direct-ext = token
streamid = "master-id=" master-id
streamid =/ "IEEE1722=" avb-stream-id
streamid =/ streamid-ext
master-id = EUI48
avb-stream-id = EUI64
EUI48 = 5(2HEXDIG ":") 2HEXDIG
EUI64 = 7(2HEXDIG ":") 2HEXDIG
streamid-ext = token
mediaclock-ext = token
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 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
Figure 8 shows the same 48 kHz audio transmission from Figure 6 with media clock derived from another RTP stream.
v=0 o=- 1311738121 1311738121 IN IP4 192.0.2.1 c=IN IP4 233.252.0.1/64 s= t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 L24/48000/2 a=sendonly a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=mediaclk:master-id=00:60:2b:20:12:1f
Figure 8: RTP stream with media clock slaved to a master device
Figure 9 shows the same 48 kHz audio transmission from Figure 6 with media clock derived from an IEEE 1722 AVB stream.
v=0 o=- 1311738121 1311738121 IN IP4 192.0.2.1 c=IN IP4 233.252.0.1/64 s= t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 L24/48000/2 a=sendonly a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0 a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
Figure 9: RTP stream with media clock slaved to an IEEE1722 master device
Signaling for timestamp clock source [rcgrammar] and media clock source [mcgrammar] is defined to be used either by applications that implement the SDP Offer/Answer model [4] or by applications that use SDP to describe media and transport configurations.
A description or offer may include reference clock signalling, media clock signalling or both. If no reference clock is specified, the direct-referenced media clock (Section 5.2) is not allowed. If no media clock is specified, an asynchronous media clock (Section 5.1) is assumed. stream-referenced media clock (Section 5.3) may be used with or without a reference clock specification. If a reference clock is not signalled, the stream may be established as rate synchronized however time synchronisation is not guaranteed.
An answer to an offer with direct-referenced media clock and reference clock specification must include the same media clock and reference clock signalling in which case a connection is established using the specified synchronisation. Alternatively the answer may omit both the signals or return only the reference clock specification. In this case, a connection is established assuming an asynchronous media clock.
An answer to an offer with media-referenced media clock specification must include the same media clock specification. The answer MUST include the same reference clock signalling or may drop the reference clock signalling. If reference clock signalling is not present in the answer, either due to not being present in the offer or due to being dropped by the answerer, the stream may be established as rate synchronized but not time synchronized.
An asynchronous media clock is the default media clock mode. This mode may be explicitly signalled or presumed due to lack of signalling. Asynchronous media clocking does not require reference clock signalling. An offer with asynchronous media clocking MAY include reference clock signalling. Because the asynchronous media clock is the default mode, the answerer is not required to explicitly signal this even if it is explicitly signalled in the offer.
SDP can be employed outside of the Offer/Answer context, for instance for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [10], or streamed through the Real Time Streaming Protocol (RTSP) [9]. The signaling model is simpler, as the sender does not negotiate parameters, but the functionality expected from specifying medial clock and reference clock attributes is the same as in Offer/Answer.
Entities receiving and acting upon an SDP message SHOULD be aware that a session description cannot be trusted unless it has been obtained by an authenticated transport protocol from a known and trusted source. Many different transport protocols may be used to distribute session description, and the nature of the authentication will differ from transport to transport. For some transports, security features are often not deployed. In case a session description has not been obtained in a trusted manner, the endpoint SHOULD exercise care because, among other attacks, the media sessions received may not be the intended ones, the destination where media is sent to may not be the expected one, any of the parameters of the session may be incorrect.
Incorrect reference or media clock parameters may cause devices or streams to synchronize to unintended clock sources. Normally this simply results in failure to make a media connection or failure to synchronize once connected. Enough devices fraudulently assigned to a specific clock source (e.g. a particular IEEE 1588 grandmaster) may, however, constitute a successful a denial of service attack on that source. Devices MAY wish to validate the integrity of the clock description through some means before connecting to unfamiliar clock sources.
The SDP attribute "ts-refclk" defined by this document is registered with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"):
Attribute name: ts-refclk
Long form: Timestamp reference clock source
Type of name: att-field
Type of attribute: session, media and source level
Subject to charset: no
Purpose: See section 4 of this document
Reference: This document
Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the Timestamp Reference Clock Source Parameters Registry. It contains the six parameters defined in Figure 1: "ntp", "ptp", "gps", "gal", "local", "private".
The SDP attribute "mediaclk" defined by this document is registered with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"):
Attribute name: mediaclk
Long form: Media clock source
Type of name: att-field
Type of attribute: session and media level
Subject to charset: no
Purpose: See section 5 of this document
Reference: This document
Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the Media Clock Source Parameters Registry. It contains the three parameters defined in Figure 5: "sender", "direct", "master", "slave" and "IEEE1722".