Rapid Synchronisation of RTP Flows
updates
- rfc-3550 — RTP: A Transport Protocol for Real-Time Applications
Extracted elements (25)
In-band NTP timestamps aligned to RTP data packets eliminate the need to estimate clock skew between flows before synchronisation. Because header extensions are inserted at exactly the same sampling instant across all component flows, they carry identical NTP-format timestamps, allowing precise RTP timestamp alignment without skew estimation.
SSM senders are permitted a zero initial RTCP delay because at most one sender exists per SSM channel, so there is no flash-crowd implosion risk. ASM sessions retain existing timing rules because simultaneous RTCP from many senders could cause implosion. SSM receivers using unicast feedback are excluded from this relaxation.
Synchronisation delay for late joiners is inherently longer than for initial participants for three reasons: early-join RTCP optimisations do not apply; RTCP report times are randomised ±50% requiring clock skew estimation from multiple reports; and codec access points (e.g., I-frames) may arrive less frequently than RTCP SR packets.
Variant B/56-bit header extension omits the upper 8 bits of NTP Seconds (which change only every ~256 seconds) to save 1 byte per packet compared to Variant A/64-bit, at the cost of requiring RTCP SR reception to reconstruct the full timestamp. This is a bandwidth/completeness trade-off for high-rate flows.
If non-compound RTCP (RFC 5506) was previously negotiated, both the RTCP-SR-REQ feedback request and the RTCP SR response MAY be sent as non-compound RTCP packets, reducing overhead in environments where this was agreed.
In SSM sessions with unicast feedback where the feedback target and media source are not co-located, a feedback target receiving an RTCP-SR-REQ should forward the request to the media source; however, the forwarding mechanism is not defined by this specification.
Middleboxes (RTP translators) that do not understand the RTP header extensions defined in this memo may remove them or fail to update their content correctly. This is the primary reason regular RTCP SR packets must still be sent even when in-band NTP timestamps are present.
A common reference clock MUST be used to generate NTP-format timestamps in RTCP SR packets for all RTP flows that are to be synchronised. It is further RECOMMENDED that senders and receivers use a synchronised common NTP-format reference clock with common properties, especially timebase, where possible.
An NTP-format timestamp included in an RTP packet via header extension MUST correspond to the same time instant as the RTP timestamp in the packet header, and MUST be derived from the same clock used to generate the NTP-format timestamps in RTCP SR packets.
An RTP sender MUST send periodic compound RTCP packets following Section 6 of RFC 3550. A compound RTCP packet containing an RTCP SR and RTCP SDES with a CNAME item MUST be sent to each RTP session in the multimedia session by each sender to enable receiver synchronisation.
Each component RTP flow in a layered, multi-description, or multi-view session MUST contain packets corresponding to all sampling instants of the flows on which it depends. If such packets are not naturally present, the sender MUST generate additional packets (e.g., Empty NAL unit packets for H.264 SVC).
For layered/multi-description/multi-view codecs on separate RTP flows, the sender SHOULD periodically and synchronously insert NTP header extensions into all component flows at exactly the same sampling instant. It is RECOMMENDED that insertion occur at least once per random access point.
For unicast multimedia or layered sessions, senders SHOULD transmit an initial compound RTCP packet (SR + SDES/CNAME) immediately on joining each RTP session, in parallel with the first data packet, enabling immediate synchronisation absent packet loss.
If a decoding hierarchy exists among component RTP flows in a layered, multi-description, or multi-view session, it MUST be signalled out of band, for example using RFC 5583 when SDP signalling is used.
If the RTP/AVPF profile is in use, a receiver MAY send RTCP-SR-REQ to request rapid resynchronisation. A media source that understands RTCP-SR-REQ SHOULD generate an RTCP SR as soon as possible while complying with RTCP early feedback rules. The request MAY be repeated once per RTCP reporting interval if no SR is forthcoming.
In SSM sessions where initial synchronisation delay is important, the RTP sender MAY set the delay before sending the initial compound RTCP packet to zero. However, RTP receivers in an SSM session sending unicast RTCP feedback MUST NOT send RTCP packets with zero initial delay; the RFC 5760 timing rules apply unchanged to receivers.
Regular RTCP SR packets MUST be sent even when in-band NTP-format header extensions are included, to provide backwards compatibility with RFC 3550 receivers and robustness against middleboxes that strip header extensions. If Variant B/56-bit is used, RTCP SR MUST be used to derive the upper 8 bits of the NTP Seconds field.
The RTP timestamp-to-NTP mapping in RTCP SR packets MUST be consistent with the mapping used in the RTP header extensions. Receivers are RECOMMENDED to sanity-check both sources and discard outliers, since broken RTP translators can corrupt either.
When SDP is used, the use of the RTP header extensions defined in this document MUST be indicated per RFC 5285 using the URI 'urn:ietf:params:rtp-hdrext:ntp-64' for Variant A and 'urn:ietf:params:rtp-hdrext:ntp-56' for Variant B.
The RTCP-SR-REQ feedback message is an RTP/AVPF transport layer feedback message with FMT=5 and PT=RTPFB (205). Its FCI part MUST be empty and the length field MUST equal 2. The SSRC of packet sender identifies the member unable to synchronise; the SSRC of media source identifies the sender whose SR is needed.
IANA registered RTCP-SR-REQ (RTCP Rapid Resynchronisation Request) with FMT value 5 in the table of FMT Values for RTPFB Payload Types (RFC 4585). This allows receivers to request rapid generation of an RTCP SR when unable to synchronise media streams.
IANA registered two new RTP Compact Header Extensions (RFC 5285): 'urn:ietf:params:rtp-hdrext:ntp-64' for 64-bit NTP synchronisation metadata (Variant A) and 'urn:ietf:params:rtp-hdrext:ntp-56' for 56-bit NTP synchronisation metadata (Variant B).
The NTP-format timestamps in the RTP header extensions defined in Section 3.3 are not part of the encrypted portion of RTP packets when SRTP (RFC 3711) is used, whereas the NTP-format timestamps in RTCP SR packets are encrypted under SRTP. This constitutes a minor information leak, considered non-significant.
Variant A (64-bit NTP RTP header extension, ID-A, L=7) carries the full 64-bit NTP-format timestamp — 32-bit Seconds (bits 0–31) immediately followed by 32-bit Fraction (bits 0–31) — as a one-byte-form RTP header extension, padded to a 32-bit boundary with 3 zero bytes.
Variant B (56-bit NTP RTP header extension, ID-B, L=6) carries NTP Seconds bits 8–31 (24 bits) and the full 32-bit NTP Fraction, omitting the upper 8 bits of Seconds. The missing upper byte must be derived from RTCP SR packets. No padding is required.