RTP Clock Source Signalling
Extracted elements (31)
Marking a clock as `traceable` allows senders to omit specific server addresses or PTP master identifiers from SDP, since any traceable clock at the answerer is considered an appropriate reference. This simplifies signalling for globally distributed sessions where GPS, Galileo, or GLONASS is available at both endpoints.
The offer/answer model for clock source signalling is declarative rather than negotiated: the offerer lists all supported clocks and the answerer selects a compatible subset. Full capability negotiation is deferred to the optional RFC 5939 SDP capability negotiation procedures.
The `rate=N/D` modifier in the direct media clock is included specifically to accommodate NTSC 'oddball' audio sample rates (e.g., 44056 Hz derived via 1000/1001 pull-down from 44100 Hz). It is not recommended for video streams, which use a fixed 90 kHz RTP clock regardless of frame rate.
Clock source parameters (e.g., PTP grandmaster identity) may change during a session due to events such as a PTP Best Master Clock Algorithm election. SIP supports re-signalling updated SDP, but other protocols may need additional notification mechanisms.
IEEE 1588-2008 (PTPv2) is not protocol compatible with IEEE 1588-2002 (PTPv1), and each requires distinct version tokens (`IEEE1588-2008` vs. `IEEE1588-2002`) in SDP. IEEE 802.1AS-2011 is a Layer-2-only profile of IEEE 1588-2008 supporting only numeric domain 0.
Slaving a device media clock to a master stream-referenced clock does NOT affect RTP inter-media synchronisation; time-aligned playout of multiple RTP sources still relies on NTP timestamps in RTCP SRs or the RFC 6051 rapid-synchronisation header extension.
An offerer or answerer without specific clocks to signal SHOULD indicate support for clock source signalling by including a `local` reference clock specification in the SDP description.
In offer/answer, if the answerer rejects an offer because reference clocks are incompatible, the rejection MUST contain at least one timestamp reference clock specification usable by the answerer for diagnostic purposes. Similarly, a media-clock rejection MUST contain a media clock specification supported by the answerer.
Master clock identifiers not already in base64 format MUST be encoded as base64 strings when used in SDP. Although generated using the RFC 7022 CNAME algorithm, the identifier does NOT appear in RTCP as a CNAME.
Streams utilizing RTP timestamp offset signalling SHOULD use a TAI-based timestamp reference clock (e.g., IEEE 1588) to avoid complications introduced by leap seconds.
The NTP/RTP timestamp mapping provided by RTCP Sender Reports (SRs) takes precedence over any mapping signalled through SDP; however, the media clock rate implied by RTCP SRs MUST be consistent with the rate signalled in SDP.
Traceable time sources MUST NOT be mixed with non-traceable time sources at any given SDP level. This ensures that all clocks listed at a level are uniformly comparable.
When no media clock signalling is present in an SDP description, receivers MUST assume an asynchronously generated media clock (`sender`). When no reference clock signalling is present, a local reference clock MUST be assumed.
When PTP domains are signalled via SDP, senders and receivers SHOULD check that both the grandmaster ClockIdentity and the PTP domain match when determining clock equivalence.
When the SDP description signals a direct-referenced media clock, reference clock signalling via `ts-refclk` is REQUIRED. Asynchronous and stream-referenced media clocks MAY be specified with or without reference clock signalling.
Global reference clocks (GPS, Galileo, GLONASS) are signalled simply by the name tokens `gps`, `gal`, or `glonass` with no additional identification required. They implicitly provide traceable time.
NTP reference clocks are identified by hostname (or IP) and optional port; if the port is omitted, the standard NTP port 123 is assumed. Multiple NTP servers listed at the same SDP level are treated as equivalent and interchangeable for fault tolerance.
PTP reference clocks are identified by a version tag (`IEEE1588-2002`, `IEEE1588-2008`, or `IEEE802.1AS-2011`), a 64-bit EUI-64 grandmaster ClockIdentity, and an optional PTP domain (textual name for IEEE 1588-2002; numeric 0–127 for IEEE 1588-2008; always 0 for 802.1AS). The token `traceable` replaces the ClockIdentity when traceable time is asserted.
The direct-referenced media clock (`a=mediaclk:direct[=offset] [rate=N/D]`) derives RTP timestamps directly from the timestamp reference clock. An optional 32-bit offset gives the RTP timestamp at the reference epoch; a rate modifier (e.g., `rate=1000/1001`) accommodates NTSC pull-down sample rates.
The `local` clock source token signals that the sender uses an unsynchronised local wallclock (or supplies no timestamps). Clocks from the same device may be assumed equivalent; no cross-device synchronisation is implied.
The `mediaclk` SDP attribute signals the media clock source for RTP streams, usable at session, media, or source level. The ABNF form is `media-clksrc = "mediaclk:" [media-clkid SP] mediaclock`. Three built-in values are defined: `sender`, `direct`, and `IEEE1722`.
The `private` clock source token (optionally `private:traceable`) identifies a reference clock distributed by means outside this specification, such as digital television or cellular services. All senders and receivers using a private clock are assumed to have an out-of-band mechanism for determining clock equivalence.
The stream-referenced media clock uses a master clock identifier (base64-encoded, SHOULD be generated per RFC 7022 short-term persistent CNAME algorithm) to associate slave RTP streams with a master clock stream. An RTP clock master is tagged with `src:<media-clktag>`; slaves reference `id=<media-clktag>`. IEEE 1722 AVB masters are referenced via `IEEE1722=<EUI64>`.
The `ts-refclk` SDP attribute signals the timestamp reference clock source for RTP senders and receivers. It may appear at session, media, or source level; more specific levels override less specific ones. The ABNF form is `timestamp-refclk = "ts-refclk:" clksrc CRLF`.
RFC 7273 creates the 'Media Clock Source Parameters' subregistry under IANA SDP Parameters. Initial entries are: `sender` (asynchronous), `direct` (reference-clock-derived), and `IEEE1722` (AVB stream). Future assignments require Specification Required policy.
RFC 7273 creates the 'Timestamp Reference Clock Source Parameters' subregistry under IANA SDP Parameters. Initial entries are: `ntp`, `ptp`, `gps`, `gal`, `glonass`, `local`, and `private`. Future assignments require Specification Required policy.
RFC 7273 registers two new SDP session/media/source-level attributes with IANA SDP Parameters: `ts-refclk` (timestamp reference clock source) and `mediaclk` (media clock source), both applicable at session, media, and source levels and not subject to charset.
SDP session descriptions cannot be trusted unless obtained via an authenticated transport from a known source. Incorrect reference or media clock parameters may cause devices to synchronise to unintended clock sources, and assigning enough devices to a fraudulent IEEE 1588 grandmaster may constitute a denial-of-service attack on that source. Devices MAY validate the integrity of clock descriptions before connecting to unfamiliar sources.
Timestamp reference clocks negotiated by this protocol SHOULD NOT be relied upon to provide a secure time reference for security-critical operations such as the expiration of public key certificates, since the clocks may be manipulated through spoofed SDP.
Media clock ABNF grammar (Figure 5): `mediaclock` selects among `sender`, `direct[=offset] [rate=N/D]`, `IEEE1722=<EUI64>`, or extension token. An optional `id=[src:]<base64-tag>` prefix precedes the clock type. The `rate` sub-field is expressed as two integers separated by `/`.
Timestamp reference clock source ABNF grammar (Figure 1): `clksrc` selects among `ntp`, `ptp`, `gps`, `gal`, `glonass`, `local`, `private`, or extension tokens. NTP is identified by `hostport` or `/traceable/`; PTP by version string, EUI-64 ClockIdentity (7 hyphen-separated octet pairs plus one), and optional domain name or domain number (0–127).