RTP/RTCP Extension for RTP Splicing Notification
Extracted elements (31)
After obtaining the RTP header extension, the splicer generates its own stream and MUST NOT include the header extension in outgoing packets. This reduces header overhead for downstream receivers who have no use for splicing interval information.
Both an RTP header extension (in-band) and an RTCP packet (out-of-band) are defined to carry the same Splicing Interval. This dual approach provides robustness: splicing-unaware middleboxes may strip RTP header extensions, so RTCP serves as a fallback. RTCP is considered a complement rather than a primary mechanism because it is also unreliable and less immediate.
The splicer is not allowed to forward the RTCP splicing notification message to downstream receivers, since the message is intentionally targeted at the splicer and forwarding it would cause useless processing and additional RTCP bandwidth consumption in downstream receivers.
The splicing-out NTP timestamp is encoded in only 7 octets (56 bits) rather than the full 64 bits to reduce header size. The top 8 bits are inferred from the splicing-in timestamp, valid because the splicing interval is assumed to be less than 2^25 seconds (~1 year). A wrap condition is detected by comparing the 56-bit splicing-out value against the lower 56 bits of the splicing-in timestamp.
If clock drift occurs before a splicing event, causing the RTP-to-NTP timestamp mapping to change, an updated RTCP SR or updated Splicing Interval information may need to be sent in a timely manner to maintain accurate splicing at the splicer.
If non-compound RTCP (RFC 5506) was previously negotiated between sender and splicer, the RTCP splicing notification messages may be sent as non-compound RTCP packets. Otherwise, the SNM follows compound RTCP rules (RFC 3550 Section 6.1) and may be included alongside the RTCP SR.
The SPLICE SDP grouping semantic is applicable in BUNDLE scenarios; substitutive RTP applies only to RTP packets whose 'm=' line is in the same SPLICE group with the substitutive stream and carries the splicing 'extmap' attribute, ensuring correct behavior when audio and video use separate SPLICE groups within a BUNDLE.
A single SDP 'm=' line MUST NOT be included in different SPLICE groups at the same time; substitutive RTP MUST be applied only to RTP packets whose 'm=' line is in the same SPLICE group and has the splicing 'extmap' attribute.
Authentication of the RTP header extension for splicing time information SHOULD be considered to prevent attackers from modifying splicing timestamps or inserting spurious splicing intervals.
If confidentiality of splicing time information is required, the header extension MUST be protected (e.g., using header extension encryption per RFC 6904). Additionally, the splicer MUST have mechanisms to authenticate the substitutive stream source to prevent insertion of invalid content.
It is RECOMMENDED that the main sender insert the RTP header extension into a number of RTP packets (not all) prior to the splicing-in point, to reduce the overhead on RTP header compression.
The main and substitutive RTP senders MUST share a common reference clock so the splicer can achieve accurate splicing. The resolution and skew requirements depend on the codec used.
The main content provider and substitutive content provider MUST ensure that the RTP timestamp of the first substitutive RTP packet corresponds to the same time instant as the splicing-in NTP timestamp in the Splicing Interval.
The main RTP sender MUST ensure that the splicing information in the RTCP splicing notification message is consistent with the information in the RTP header extensions.
The main RTP sender MUST send the RTCP splicing notification message regardless of whether timestamps are included in the RTP header extension, providing robustness against middleboxes that strip RTP header extensions.
The main RTP sender MUST send the Splicing Interval well in advance of the splicing-in point, to enable the splicer to obtain the substitutive content before splicing starts. The advance time can be estimated using the RTT derived from RTCP Receiver Reports.
The Splicing Interval SHOULD be sent by the RTP header extension or RTCP extension message more than once to mitigate possible packet loss.
The substitutive RTP sender MUST send the substitutive RTP packet ahead of the splicing-in point, allowing the splicer to find the timestamp of the first substitutive packet (e.g., via a prior RTCP SR).
When a mixer-based splicer omits the CSRC list (breaking RTP loop detection per RFC 3550 Section 8.2), non-RTP means MUST be used to detect and resolve forwarding loops, as these could form a serious denial-of-service threat.
The RTCP Splicing Notification Message (SNM) is a new RTCP packet type (PT=213) consisting of a fixed header with SSRC, followed by a 64-bit IN NTP timestamp and a 64-bit OUT NTP timestamp indicating the start and end of the splicing interval.
The SDP 'SPLICE' grouping semantic (extending RFC 5888) relates a main RTP stream 'm=' line to a substitutive RTP stream 'm=' line. Only two 'm=' lines are allowed per SPLICE group, and the main stream is identified by having the 'extmap' splicing-interval attribute.
The Splicing Interval is a pair of NTP timestamps (wallclock time) representing the splicing-in point and splicing-out point, as defined per RFC 6828. It tells the splicer when to start and end substitution of the main RTP stream.
IANA registered a new entry in the 'RTCP Control Packet types (PT)' registry: Name 'SNM' (Splicing Notification Message), Value 213, Reference RFC 8286.
IANA registered a new RTP Compact Header Extension with URI 'urn:ietf:params:rtp-hdrext:splicing-interval', Description 'Splicing Interval', per RFC 8285.
IANA registered a new SDP grouping semantic 'SPLICE' (Token: SPLICE) in the 'Semantics for the group SDP Attribute' subregistry of the 'Session Description Protocol (SDP) Parameters' registry, extending RFC 5888.
An attacker who modifies splicing timestamps could cause splicing to fail (substitutive content unavailable at the right time) or could prevent receivers from receiving main content by inserting spurious splicing intervals. Header extension authentication should be used to prevent these attacks.
The splicer inherently breaks RTP-level end-to-end security (source authentication and integrity protection) because it replaces content. End-to-end source authentication is not possible with any existing splicing solution. When using SRTP, the splicer must be provisioned with the same security association as the main RTP sender.
When a mixer splicer omits the CSRC list from output packets (to simplify receivers), the standard RTP loop detection mechanism is disabled. This creates a risk of forwarding loops that could form a serious denial-of-service threat; non-RTP loop detection signaling is required as a compensating control.
The RTCP SNM packet format: 2-bit V=2, 1-bit P, 5-bit reserved, 8-bit PT=213, 16-bit length; followed by 32-bit SSRC, then IN NTP timestamp (two 32-bit words, most/least significant), then OUT NTP timestamp (two 32-bit words). Total fixed size is 6 32-bit words (24 octets) plus header word.
The RTP header extension (one-byte header format, L=14) encodes the splicing-out NTP timestamp in 7 octets (bits 8–31 of Seconds plus 32-bit Fraction) followed by the splicing-in NTP timestamp in 8 octets (full 64-bit NTP timestamp). The top 8 bits of the splicing-out timestamp are inferred from the splicing-in timestamp, assuming the interval is less than 2^25 seconds.
The RTP header extension two-byte header format (L=15) encodes the same splicing-out (7 octets) and splicing-in (8 octets) NTP timestamps as the one-byte format, with a padding byte appended to align to a 32-bit boundary.