RTP and Leap Seconds
updates
- rfc-3550 — RTP: A Transport Protocol for Real-Time Applications
Extracted elements (21)
POSIX clocks using time warping are explicitly discouraged for RTP timestamping because warping alters the length of a second, making the relationship between RTP timestamps and wall-clock time non-uniform and therefore non-interoperable across implementations.
RTP senders and receivers near a leap second should rely on internal clocks rather than RTCP sender reports to maintain synchronization, because the NTP timestamps in those reports become ambiguous or inaccurate during the two-second window surrounding a positive leap second.
The recommendation to assume a positive leap second at the end of every month's last day (rather than tracking the actual schedule) is a conservative simplification that avoids the need for out-of-band leap-second schedule distribution in all deployments.
IEEE 1588, GPS, and other TAI-based clocks do not include leap seconds and require no special accommodation for RTP. NTP and OS clocks using UTC are leap-second-bearing and require the accommodations described in this document.
Negative leap seconds do not introduce timestamp ambiguity or complications, so no special treatment is needed to avoid RTP timestamp ambiguity in their presence; however, receivers SHOULD still account for them when computing playout times.
NTP inserts a leap second by freezing or slowing the clock for one second immediately prior to the last second of the affected day, making the last second have a real-time duration of two seconds and compromising timestamp accuracy during that period.
POSIX systems are required to omit leap seconds from reported time, with implementations varying between repeating the last second, mirroring NTP behavior, or warping time. Timestamps within the last second of a leap-second day are therefore ambiguous.
Some TAI-based systems (e.g., IEEE 1588, GPS) can deliver TAI-to-UTC mapping information, allowing receivers to synthesize a leap-second-bearing UTC clock. It is the timescale used, not the delivery mechanism, that determines whether a reference clock is leap-second-bearing.
Without prior knowledge of the leap-second schedule, NTP servers and clients may become offset by exactly one second with respect to their UTC reference, with the discrepancy lasting anywhere from a few seconds to a few days and disrupting NTP-referenced RTP streams.
All participants generating or consuming timestamps associated with a leap-second-bearing reference MUST recognize leap seconds and SHOULD have a working communications channel to receive notifications of leap-second scheduling.
For the purpose of suspending or ignoring sender reports near a leap second, senders and receivers MAY assume that a positive leap second occurs at the end of the last day of every month.
Generating or using NTP timestamps during the entire last second of a day on which a positive leap second has been scheduled SHOULD be avoided. The period to be avoided has a real-time duration of two seconds.
POSIX clocks that use a warping technique to accommodate leap seconds are not a good choice for an interoperable timestamp reference and SHOULD NOT be used to timestamp RTP streams.
Receivers consuming leap-second-bearing timestamps SHOULD ignore timestamps in any sender reports generated in the vicinity of a positive leap second.
Receivers consuming leap-second-bearing timestamps SHOULD take both positive and negative leap seconds in the reference into account to determine playout time based on RTP timestamps.
RTP senders using a leap-second-bearing reference SHOULD NOT generate sender reports containing an originating NTP timestamp in the vicinity of a positive leap second.
To maintain a consistent RTCP schedule and avoid unintentional timeouts, senders suppressing sender reports near a leap second MAY send receiver reports in place of sender reports.
RTCP Sender Reports contain an NTP timestamp field used to create a mapping between RTP timestamps and the wall clock, enabling wall-clock-referenced playout. This mapping is the primary mechanism affected by leap seconds.
The NTP Leap Indicator in the NTP header is identified as a protocol means for notifying clocks of an impending leap second, forming part of the required communications channel for leap-second-aware RTP participants.
A stream can be disrupted by blocking or delaying leap-second notification to one participant, or by tricking a participant into believing a leap second has been scheduled when it has not. These vulnerabilities are inherited from RFC 3550 and are not introduced or worsened by this document.
RTP streams using a wall-clock reference present an additional attack vector compared to self-clocking streams: manipulation of the wall clock at either the sender or receiver can potentially disrupt streaming.