summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8286.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8286.txt')
-rw-r--r--doc/rfc/rfc8286.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc8286.txt b/doc/rfc/rfc8286.txt
new file mode 100644
index 0000000..a0dadc3
--- /dev/null
+++ b/doc/rfc/rfc8286.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Xia
+Request for Comments: 8286 R. Even
+Category: Standards Track R. Huang
+ISSN: 2070-1721 Huawei
+ L. Deng
+ China Mobile
+ October 2017
+
+
+ RTP/RTCP Extension for RTP Splicing Notification
+
+Abstract
+
+ Content splicing is a process that replaces the content of a main
+ multimedia stream with other multimedia content and that delivers the
+ substitutive multimedia content to the receivers for a period of
+ time. The splicer is designed to handle RTP splicing and needs to
+ know when to start and end the splicing.
+
+ This memo defines two RTP/RTCP extensions to indicate the splicing-
+ related information to the splicer: an RTP header extension that
+ conveys the information "in band" and an RTP Control Protocol (RTCP)
+ packet that conveys the information out of band.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8286.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 1]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 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
+ (https://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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................3
+ 2. Overview ........................................................4
+ 2.1. Overview of RTP Splicing ...................................4
+ 2.2. Overview of Splicing Interval ..............................5
+ 3. Conveying Splicing Interval in RTP/RTCP Extensions ..............7
+ 3.1. RTP Header Extension .......................................7
+ 3.2. RTCP Splicing Notification Message .........................8
+ 4. Reducing Splicing Latency ......................................10
+ 5. Failure Cases ..................................................11
+ 6. Session Description Protocol (SDP) Signaling ...................12
+ 6.1. Declarative SDP ...........................................12
+ 6.2. Offer/Answer without BUNDLE ...............................13
+ 6.3. Offer/Answer with BUNDLE: All Media Are Spliced ...........14
+ 6.4. Offer/Answer with BUNDLE: A Subset of Media Are Spliced ...16
+ 7. Security Considerations ........................................18
+ 8. IANA Considerations ............................................19
+ 8.1. RTCP Control Packet Types .................................19
+ 8.2. RTP Compact Header Extensions .............................20
+ 8.3. SDP Grouping Semantic Extension ...........................20
+ 9. References .....................................................20
+ 9.1. Normative References ......................................20
+ 9.2. Informative References ....................................21
+ Acknowledgements ..................................................22
+ Authors' Addresses ................................................22
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 2]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+1. Introduction
+
+ Splicing is a process that replaces some multimedia content with
+ other multimedia content and delivers the substitutive multimedia
+ content to the receivers for a period of time. In some predictable
+ splicing cases, e.g., advertisement insertion, the splicing duration
+ needs to be inside of the specific pre-designated time slot. Certain
+ timing information about when to start and end the splicing must be
+ first acquired by the splicer in order to start the splicing. This
+ document refers to this information as the "Splicing Interval".
+
+ [SCTE35] provides a method that encapsulates the Splicing Interval
+ inside the MPEG2-TS (MPEG2 transport stream) layer in cable TV
+ systems. When transported in RTP, a middlebox designed as the
+ splicer to decode the RTP packets and search for the Splicing
+ Interval inside the payloads is required. The need for such
+ processing increases the workload of the middlebox and limits the
+ number of RTP sessions the middlebox can support.
+
+ This document defines an RTP header extension [RFC8285] used by the
+ main RTP sender to provide the Splicing Interval by including it in
+ the RTP packets.
+
+ However, the Splicing Interval conveyed in the RTP header extension
+ might not reach the splicer successfully. Any splicing-unaware
+ middlebox on the path between the RTP sender and the splicer might
+ strip this RTP header extension.
+
+ To increase robustness against such a case, this document also
+ defines a new RTP Control Protocol (RTCP) packet type to carry the
+ same Splicing Interval to the splicer. Since RTCP is also unreliable
+ and may not be as "immediate" as the in-band technique, it's only
+ considered to be a complement to the RTP header extension.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 3]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ In addition, we define the following terms:
+
+ Main RTP Sender:
+
+ The sender of RTP packets carrying the main RTP stream.
+
+ Splicer:
+
+ An intermediary node that inserts substitutive content into a main
+ RTP stream. The splicer sends substitutive content to the RTP
+ receiver instead of the main content during splicing. It is also
+ responsible for processing RTCP traffic between the RTP sender and
+ the RTP receiver.
+
+ Splicing-In Point:
+
+ A virtual point in the RTP stream, suitable for substitutive
+ content entry, typically in the boundary between two independently
+ decodable frames.
+
+ Splicing-Out Point:
+
+ A virtual point in the RTP stream, suitable for substitutive
+ content exit, typically in the boundary between two independently
+ decodable frames.
+
+ Splicing Interval:
+
+ The NTP timestamps, representing the main RTP sender wallclock
+ time, for the splicing-in point and splicing-out point per
+ [RFC6828], allowing the splicer to know when to start and end the
+ RTP splicing.
+
+ Substitutive RTP Sender:
+
+ The sender of RTP packets carrying the RTP stream that will
+ replace the content in the main RTP stream.
+
+2. Overview
+
+2.1. Overview of RTP Splicing
+
+ RTP splicing is intended to replace some multimedia content with
+ certain substitutive multimedia content and then forward it to the
+ receivers for a period of time. This process is authorized by the
+ main RTP sender that offers a specific time window for inserting the
+ substitutive multimedia content in the main content. A typical usage
+
+
+
+
+Xia, et al. Standards Track [Page 4]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ scenario is where an IPTV service provider uses its own regional
+ advertising content to replace national advertising content, the time
+ window of which is explicitly indicated by the IPTV service provider.
+
+ The splicer is a middlebox handling RTP splicing. It receives the
+ main content and substitutive content simultaneously but only chooses
+ to send one of them to the receiver at any point in time. When RTP
+ splicing begins, the splicer sends the substitutive content to the
+ receivers instead of the main content. When RTP splicing ends, the
+ splicer switches back to sending the main content to the receivers.
+ This implies that the receiver is explicitly configured to receive
+ the traffic via the splicer and will return any RTCP feedback to it
+ in the presence of the splicer.
+
+ The middlebox working as the splicer can be implemented as either an
+ RTP mixer or an RTP translator. If implemented as an RTP mixer, the
+ splicer will use its own synchronization source (SSRC), sequence
+ number space, and timing model when generating the output stream to
+ receivers, using the contributing source (CSRC) list to indicate
+ whether the original content or substitutive content is being
+ delivered. The splicer, on behalf of the content provider, can omit
+ the CSRC list from the RTP packets it generates. This simplifies the
+ design of the receivers, since they don't need to parse the CSRC
+ list, but makes it harder to determine when the splicing is taking
+ place (it requires inspection of the RTP payload data, rather than
+ just the RTP headers). A splicer working as an RTP mixer splits the
+ flow between the sender and receiver into two, and it requires
+ separate control loops for RTCP and congestion control. [RFC6828]
+ provides an example of an RTP mixer approach.
+
+ A splicer implemented as an RTP translator [RFC3550] will forward the
+ RTP packets from the original and substitutive senders with their
+ SSRCs intact but will need to rewrite RTCP Sender Report (SR) packets
+ to account for the splicing. In this case, the congestion control
+ loops run between the original sender and receiver and between the
+ substitutive sender and receiver. The splicer needs to ensure that
+ the RTCP feedback messages from the receiver are passed to the right
+ sender to let the congestion control work.
+
+2.2. Overview of Splicing Interval
+
+ To handle splicing on the RTP layer at the reserved time slots set by
+ the main RTP sender, the splicer must first know the Splicing
+ Interval from the main RTP sender before it can start splicing.
+
+ When a new splicing is forthcoming, the main RTP sender needs to send
+ the Splicing Interval to the splicer. The Splicing Interval SHOULD
+ be sent by the RTP header extension or RTCP extension message more
+
+
+
+Xia, et al. Standards Track [Page 5]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ than once to mitigate possible packet loss. To enable the splicer to
+ get the substitutive content before the splicing starts, the main RTP
+ sender MUST send the Splicing Interval well in advance. For example,
+ the main RTP sender can estimate when to send the Splicing Interval
+ based on the round-trip time (RTT), following the mechanisms
+ described in Section 6.4.1 of [RFC3550] when the splicer sends an
+ RTCP Receiver Report (RR) to the main sender.
+
+ The substitutive sender also needs to learn the Splicing Interval
+ from the main RTP sender in advance and estimate when to transfer the
+ substitutive content to the splicer. The Splicing Interval could be
+ transmitted from the main RTP sender to the substitutive content
+ using some out-of-band mechanisms -- for example, a proprietary
+ mechanism to exchange the Splicing Interval -- or the substitutive
+ sender is implemented together with the main RTP sender inside a
+ single device. To ensure that the Splicing Interval is valid for
+ both the main RTP sender and the substitutive RTP sender, the two
+ senders MUST share a common reference clock so that the splicer can
+ achieve accurate splicing. The requirements for the common reference
+ clock (e.g., resolution, skew) depend on the codec used by the media
+ content.
+
+ In this document, the main RTP sender uses a pair of NTP timestamps
+ to indicate when to start and end the splicing to the splicer: the
+ timestamp of the first substitutive RTP packet at the splicing-in
+ point and the timestamp of the first main RTP packet at the
+ splicing-out point.
+
+ When the substitutive RTP sender gets the Splicing Interval, it must
+ prepare the substitutive stream. The main content provider and the
+ substitutive content provider MUST ensure that the RTP timestamp of
+ the first substitutive RTP packet that would be presented to the
+ receivers corresponds to the same time instant as the former
+ NTP timestamp in the Splicing Interval. To enable the splicer to
+ know the first substitutive RTP packet it needs to send, the
+ substitutive RTP sender MUST send the substitutive RTP packet ahead
+ of the splicing-in point, allowing the splicer to find out the
+ timestamp of this first RTP packet in the substitutive RTP stream,
+ e.g., using a prior RTCP SR message.
+
+ When it is time for the splicing to end, the main content provider
+ and the substitutive content provider MUST ensure that the RTP
+ timestamp of the first main RTP packet that would be presented on the
+ receivers corresponds to the same time instant as the latter
+ NTP timestamp in the Splicing Interval.
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 6]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+3. Conveying Splicing Interval in RTP/RTCP Extensions
+
+ This memo defines two backward-compatible RTP extensions to convey
+ the Splicing Interval to the splicer: an RTP header extension and an
+ RTCP splicing notification message.
+
+3.1. RTP Header Extension
+
+ The RTP header extension mechanism defined in [RFC8285] can be
+ adapted to carry the Splicing Interval, which consists of a pair of
+ NTP timestamps.
+
+ This RTP header extension carries the 7 octets of the splicing-out
+ NTP timestamp (lower 24-bit part of the "Seconds" of an NTP timestamp
+ and the 32 bits of the "Fraction" of an NTP timestamp as defined in
+ [RFC5905]), followed by the 8 octets of the splicing-in NTP timestamp
+ (64-bit NTP timestamp as defined in [RFC5905]). The top 8 bits of
+ the splicing-out NTP timestamp are inferred from the top 8 bits of
+ the splicing-in NTP timestamp, assuming that (1) the splicing-out
+ time is after the splicing-in time and (2) the Splicing Interval is
+ less than 2^25 seconds. Therefore, if the value of the 7 octets of
+ the splicing-out NTP timestamp is smaller than the value of the
+ 7 lower octets of the splicing-in NTP timestamp, it implies a wrap of
+ the 56-bit splicing-out NTP timestamp, which means that the top 8-bit
+ value of the 64-bit splicing-out NTP timestamp is equal to the top
+ 8-bit value of the splicing-in NTP timestamp plus 0x01. Otherwise,
+ the top 8 bits of the splicing-out NTP timestamp are equal to the top
+ 8 bits of the splicing-in NTP timestamp.
+
+ This RTP header extension can be encoded using either the one-byte or
+ two-byte header defined in [RFC8285]. Figures 1 and 2 show the
+ Splicing Interval header extension with each of the two header
+ formats.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 7]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
+ | ID | L=14 | OUT NTP timestamp - Seconds (bit 8-31) |x
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
+ | OUT NTP timestamp - Fraction (bit 0-31) |e
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
+ | IN NTP timestamp - Seconds (bit 0-31) |s
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
+ | IN NTP timestamp - Fraction (bit 0-31) |o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
+
+ Figure 1: Splicing Interval Using the One-Byte Header Format
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
+ | ID | L=15 | OUT NTP timestamp - Seconds |x
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
+ |OUT Secds(cont)| OUT NTP timestamp - Fraction |e
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
+ |OUT Fract(cont)| IN NTP timestamp - Seconds |s
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
+ | IN Secds(cont)| IN NTP timestamp - Fraction |o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
+ | IN Fract(cont)| 0 (pad) | ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: Splicing Interval Using the Two-Byte Header Format
+
+ Since the inclusion of an RTP header extension will reduce the
+ efficiency of RTP header compression, it is RECOMMENDED that the main
+ sender insert the RTP header extensions into a number of RTP packets,
+ instead of all of the RTP packets, prior to the splicing-in.
+
+ After the splicer obtains the RTP header extension and derives the
+ Splicing Interval, it generates its own stream and is not allowed to
+ include the RTP header extension in outgoing packets; this reduces
+ header overhead.
+
+3.2. RTCP Splicing Notification Message
+
+ In addition to including the RTP header extension, the main RTP
+ sender includes the Splicing Interval in an RTCP splicing
+ notification message. Whether or not the timestamps are included in
+ the RTP header extension, the main RTP sender MUST send the RTCP
+ splicing notification message. This provides robustness in the case
+ where a middlebox strips RTP header extensions. The main RTP sender
+
+
+
+Xia, et al. Standards Track [Page 8]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ MUST make sure that the splicing information contained in the RTCP
+ splicing notification message is consistent with the information
+ included in the RTP header extensions.
+
+ The RTCP splicing notification message is a new RTCP packet type. It
+ has a fixed header followed by a pair of NTP timestamps:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|reserved | PT=213 | length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSRC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IN NTP timestamp (most significant word) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | IN NTP timestamp (least significant word) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OUT NTP timestamp (most significant word) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OUT NTP timestamp (least significant word) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: RTCP Splicing Notification Message
+
+ The RTCP splicing notification message includes the following fields:
+
+ Length: 16 bits
+
+ As defined in [RFC3550], the length of the RTCP packet in 32-bit
+ words minus one, including the header and any padding.
+
+ SSRC: 32 bits
+
+ The SSRC of the main RTP sender.
+
+ Timestamp: 64 bits
+
+ Indicates the wallclock time when this splicing starts and ends.
+ The full-resolution NTP timestamp is used, which is a 64-bit
+ unsigned fixed-point number with the integer part in the first
+ 32 bits and the fractional part in the last 32 bits. This format
+ is the same as the NTP timestamp field in the RTCP SR
+ (Section 6.4.1 of [RFC3550]).
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 9]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ The RTCP splicing notification message can be included in the RTCP
+ compound packet together with the RTCP SR generated at the main RTP
+ sender; hence, it follows the compound RTCP rules defined in
+ Section 6.1 in [RFC3550].
+
+ If the use of non-compound RTCP [RFC5506] was previously negotiated
+ between the sender and the splicer, the RTCP splicing notification
+ messages may be sent as non-compound RTCP packets. In some cases
+ where the mapping from the RTP timestamp to the NTP timestamp
+ changes, e.g., clock drift happens before the splicing event, sending
+ an RTCP SR or even updated Splicing Interval information in a timely
+ manner might be required in order to update the timestamp mapping for
+ accurate splicing.
+
+ Since the RTCP splicing notification message is intentionally sent by
+ the main RTP sender to the splicer, the splicer is not allowed to
+ forward this message to the receivers, so as to avoid useless
+ processing and additional RTCP bandwidth consumption in the
+ downstream receivers.
+
+4. Reducing Splicing Latency
+
+ When splicing starts or ends, the splicer outputs the multimedia
+ content from another sender to the receivers. Given that the
+ receivers must first acquire certain information ([RFC6285] refers to
+ this information as "Reference Information") to start processing the
+ multimedia data, either the main RTP sender or the substitutive
+ sender SHOULD provide the Reference Information together with its
+ multimedia content to reduce the delay caused by acquiring the
+ Reference Information. The methods by which the Reference
+ Information is distributed to the receivers are out of scope for
+ this memo.
+
+ Another latency element is delay caused by synchronization. The
+ receivers must receive enough synchronization metadata prior to
+ synchronizing the separate components of the multimedia streams when
+ splicing starts or ends. Either the main RTP sender or the
+ substitutive sender SHOULD send the synchronization metadata early
+ enough so that the receivers can play out the multimedia in a
+ synchronized fashion. The main RTP sender or the substitutive sender
+ can estimate when to send the synchronization metadata based on, for
+ example, the RTT, following the mechanisms described in Section 6.4.1
+ of [RFC3550] when the splicer sends an RTCP RR to the main sender or
+ the substitutive sender. The main RTP sender and the substitutive
+ sender can also be coordinated by some proprietary out-of-band
+ mechanisms to decide when, and to whom, the metadata is to be sent.
+ If both send the information, the splicer SHOULD pick one based on
+ the current situation, e.g., choosing either (1) the main RTP sender
+
+
+
+Xia, et al. Standards Track [Page 10]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ when synchronizing the main media content or (2) the information from
+ the substitutive sender when synchronizing the spliced content. To
+ reduce possible synchronization delay, it is RECOMMENDED that the
+ mechanisms defined in [RFC6051] be adopted.
+
+5. Failure Cases
+
+ This section examines the implications of losing RTCP splicing
+ notification messages, e.g., the RTP header extension is stripped on
+ the path.
+
+ Given that there may be a splicing-unaware middlebox on the path
+ between the main RTP sender and the splicer, the main and
+ substitutive RTP senders can use one heuristic to verify whether or
+ not the Splicing Interval reaches the splicer.
+
+ The splicer can be implemented to have its own SSRC and send RTCP
+ reception reports to the senders of the main and substitutive RTP
+ streams. This allows the senders to detect problems on the path to
+ the splicer. Alternatively, it is possible to implement the splicer
+ such that it has no SSRC and does not send RTCP reports; this
+ prevents the senders from being able to monitor the quality of the
+ path to the splicer.
+
+ If the splicer has an SSRC and sends its own RTCP reports, it can
+ choose not to pass RTCP reports it receives from the receivers to the
+ senders. This will prevent the senders from being able to monitor
+ the quality of the paths from the splicer to the receivers.
+
+ A splicer that has an SSRC can choose to pass RTCP reception reports
+ from the receivers back to the senders, after modifications to
+ account for the splicing. This will allow the senders to monitor the
+ quality of the paths from the splicer to the receivers. A splicer
+ that does not have its own SSRC has to forward and translate RTCP
+ reports from the receiver; otherwise, the senders will not see any
+ receivers in the RTP session.
+
+ If the splicer is implemented as a mixer, it will have its own SSRC,
+ send its own RTCP reports, and forward translated RTCP reports from
+ the receivers.
+
+ Upon the detection of a failure, the splicer can communicate with the
+ main sender and the substitutive sender via some out-of-band
+ signaling technique and fall back to the payload-specific mechanisms
+ it supports, e.g., the MPEG2-TS splicing solution defined in
+ [SCTE35], or just abandon the splicing.
+
+
+
+
+
+Xia, et al. Standards Track [Page 11]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+6. Session Description Protocol (SDP) Signaling
+
+ This document defines the URI for declaring this header extension in
+ an "extmap" attribute to be
+ "urn:ietf:params:rtp-hdrext:splicing-interval".
+
+ This document extends the standard semantics defined in "The Session
+ Description Protocol (SDP) Grouping Framework" [RFC5888] with a new
+ semantic, called "SPLICE", to represent the relationship between the
+ main RTP stream and the substitutive RTP stream. Only two "m=" lines
+ are allowed in the SPLICE group. The main RTP stream is the one with
+ the extended "extmap" attribute, and the other one is the
+ substitutive stream. A single "m=" line MUST NOT be included in
+ different SPLICE groups at the same time. The main RTP sender
+ provides the information about both main and substitutive sources.
+
+ The extended SDP attribute specified in this document is applicable
+ for offer/answer content [RFC3264] and does not affect any rules when
+ negotiating offers and answers. When used with multiple "m=" lines,
+ substitutive RTP MUST be applied only to the RTP packets whose SDP
+ "m=" line is in the same group with the substitutive stream using
+ SPLICE and has the extended splicing "extmap" attribute. This
+ semantic is also applicable for BUNDLE cases.
+
+ The following examples show how SDP signaling could be used for
+ splicing in different cases.
+
+6.1. Declarative SDP
+
+ v=0
+ o=xia 1122334455 1122334466 IN IP4 splicing.example.com
+ s=RTP Splicing Example
+ t=0 0
+ a=group:SPLICE 1 2
+ m=video 30000 RTP/AVP 100
+ i=Main RTP Stream
+ c=IN IP4 233.252.0.1/127
+ a=rtpmap:100 MP2T/90000
+ a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=mid:1
+ m=video 30002 RTP/AVP 100
+ i=Substitutive RTP Stream
+ c=IN IP4 233.252.0.2/127
+ a=sendonly
+ a=rtpmap:100 MP2T/90000
+ a=mid:2
+
+ Figure 4: Example SDP for a Single-Channel Splicing Scenario
+
+
+
+Xia, et al. Standards Track [Page 12]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ The splicer receiving the SDP message above receives one MPEG2-TS
+ stream (payload 100) from the main RTP sender (with a multicast
+ destination address of 233.252.0.1) on port 30000 and/or receives
+ another MPEG2-TS stream from the substitutive RTP sender (with a
+ multicast destination address of 233.252.0.2) on port 30002. But at
+ a particular point in time, the splicer only selects one stream and
+ outputs the content from the chosen stream to the downstream
+ receivers.
+
+6.2. Offer/Answer without BUNDLE
+
+ SDP Offer - from the main RTP sender:
+
+ v=0
+ o=xia 1122334455 1122334466 IN IP4 splicing.example.com
+ s=RTP Splicing Example
+ t=0 0
+ a=group:SPLICE 1 2
+ m=video 30000 RTP/AVP 31 100
+ i=Main RTP Stream
+ c=IN IP4 splicing.example.com
+ a=rtpmap:31 H261/90000
+ a=rtpmap:100 MP2T/90000
+ a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=sendonly
+ a=mid:1
+ m=video 40000 RTP/AVP 31 100
+ i=Substitutive RTP Stream
+ c=IN IP4 substitutive.example.com
+ a=rtpmap:31 H261/90000
+ a=rtpmap:100 MP2T/90000
+ a=sendonly
+ a=mid:2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 13]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ SDP Answer - from the splicer:
+
+ v=0
+ o=xia 1122334455 1122334466 IN IP4 splicer.example.com
+ s=RTP Splicing Example
+ t=0 0
+ a=group:SPLICE 1 2
+ m=video 30000 RTP/AVP 100
+ i=Main RTP Stream
+ c=IN IP4 splicer.example.com
+ a=rtpmap:100 MP2T/90000
+ a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=recvonly
+ a=mid:1
+ m=video 40000 RTP/AVP 100
+ i=Substitutive RTP Stream
+ c=IN IP4 splicer.example.com
+ a=rtpmap:100 MP2T/90000
+ a=recvonly
+ a=mid:2
+
+6.3. Offer/Answer with BUNDLE: All Media Are Spliced
+
+ In this example, the bundled audio and video media have their own
+ substitutive media for splicing:
+
+ 1. An offer, in which the offerer assigns a unique address and a
+ substitutive media to each bundled "m=" line for splicing within
+ the BUNDLE group.
+
+ 2. An answer, in which the answerer selects its own BUNDLE address
+ and leaves the substitutive media untouched.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 14]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ SDP Offer - from the main RTP sender:
+
+ v=0
+ o=alice 1122334455 1122334466 IN IP4 splicing.example.com
+ s=RTP Splicing Example
+ c=IN IP4 splicing.example.com
+ t=0 0
+ a=group:SPLICE foo 1
+ a=group:SPLICE bar 2
+ a=group:BUNDLE foo bar
+ m=audio 10000 RTP/AVP 0 8 97
+ a=mid:foo
+ b=AS:200
+ a=rtpmap:0 PCMU/8000
+ a=rtpmap:8 PCMA/8000
+ a=rtpmap:97 iLBC/8000
+ a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=sendonly
+ m=video 10002 RTP/AVP 31 32
+ a=mid:bar
+ b=AS:1000
+ a=rtpmap:31 H261/90000
+ a=rtpmap:32 MPV/90000
+ a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=sendonly
+ m=audio 20000 RTP/AVP 0 8 97
+ i=Substitutive audio RTP Stream
+ c=IN IP4 substitutive.example.com
+ a=rtpmap:0 PCMU/8000
+ a=rtpmap:8 PCMA/8000
+ a=rtpmap:97 iLBC/8000
+ a=sendonly
+ a=mid:1
+ m=video 20002 RTP/AVP 31 32
+ i=Substitutive video RTP Stream
+ c=IN IP4 substitutive.example.com
+ a=rtpmap:31 H261/90000
+ a=rtpmap:32 MPV/90000
+ a=mid:2
+ a=sendonly
+
+
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 15]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ SDP Answer - from the splicer:
+
+ v=0
+ o=bob 2808844564 2808844564 IN IP4 splicer.example.com
+ s=RTP Splicing Example
+ c=IN IP4 splicer.example.com
+ t=0 0
+ a=group:SPLICE foo 1
+ a=group:SPLICE bar 2
+ a=group:BUNDLE foo bar
+ m=audio 30000 RTP/AVP 0
+ a=mid:foo
+ b=AS:200
+ a=rtpmap:0 PCMU/8000
+ a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=recvonly
+ m=video 30000 RTP/AVP 32
+ a=mid:bar
+ b=AS:1000
+ a=rtpmap:32 MPV/90000
+ a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=recvonly
+ m=audio 30002 RTP/AVP 0
+ i=Substitutive audio RTP Stream
+ c=IN IP4 splicer.example.com
+ a=rtpmap:0 PCMU/8000
+ a=recvonly
+ a=mid:1
+ m=video 30004 RTP/AVP 32
+ i=Substitutive video RTP Stream
+ c=IN IP4 splicer.example.com
+ a=rtpmap:32 MPV/90000
+ a=mid:2
+ a=recvonly
+
+6.4. Offer/Answer with BUNDLE: A Subset of Media Are Spliced
+
+ In this example, the substitutive media only applies for video when
+ splicing:
+
+ 1. An offer, in which the offerer assigns a unique address to each
+ bundled "m=" line within the BUNDLE group and assigns a
+ substitutive media to the bundled video "m=" line for splicing.
+
+ 2. An answer, in which the answerer selects its own BUNDLE address
+ and leaves the substitutive media untouched.
+
+
+
+
+
+Xia, et al. Standards Track [Page 16]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ SDP Offer - from the main RTP sender:
+
+ v=0
+ o=alice 1122334455 1122334466 IN IP4 splicing.example.com
+ s=RTP Splicing Example
+ c=IN IP4 splicing.example.com
+ t=0 0
+ a=group:SPLICE bar 2
+ a=group:BUNDLE foo bar
+ m=audio 10000 RTP/AVP 0 8 97
+ a=mid:foo
+ b=AS:200
+ a=rtpmap:0 PCMU/8000
+ a=rtpmap:8 PCMA/8000
+ a=rtpmap:97 iLBC/8000
+ a=sendonly
+ m=video 10002 RTP/AVP 31 32
+ a=mid:bar
+ b=AS:1000
+ a=rtpmap:31 H261/90000
+ a=rtpmap:32 MPV/90000
+ a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=sendonly
+ m=video 20000 RTP/AVP 31 32
+ i=Substitutive video RTP Stream
+ c=IN IP4 substitutive.example.com
+ a=rtpmap:31 H261/90000
+ a=rtpmap:32 MPV/90000
+ a=mid:2
+ a=sendonly
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 17]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ SDP Answer - from the splicer:
+
+ v=0
+ o=bob 2808844564 2808844564 IN IP4 splicer.example.com
+ s=RTP Splicing Example
+ c=IN IP4 splicer.example.com
+ t=0 0
+ a=group:SPLICE bar 2
+ a=group:BUNDLE foo bar
+ m=audio 30000 RTP/AVP 0
+ a=mid:foo
+ b=AS:200
+ a=rtpmap:0 PCMU/8000
+ a=recvonly
+ m=video 30000 RTP/AVP 32
+ a=mid:bar
+ b=AS:1000
+ a=rtpmap:32 MPV/90000
+ a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
+ a=recvonly
+ m=video 30004 RTP/AVP 32
+ i=Substitutive video RTP Stream
+ c=IN IP4 splicer.example.com
+ a=rtpmap:32 MPV/90000
+ a=mid:2
+ a=recvonly
+
+7. Security Considerations
+
+ The security considerations of the RTP specification [RFC3550] and
+ the general mechanism for RTP header extensions [RFC8285] apply. The
+ splicer can be either a mixer or a translator, and all the security
+ considerations of topologies [RFC7667] [RFC7201] for these two types
+ of RTP intermediaries are applicable for the splicer.
+
+ The splicer replaces some content with other content in RTP packets,
+ thus breaking any RTP-level end-to-end security, such as source
+ authentication and integrity protection. End-to-end source
+ authentication is not possible with any known existing splicing
+ solution. A new solution can theoretically be developed that enables
+ identification of the participating entities and what each provides,
+ i.e., the different media sources -- main and substitutive -- and the
+ splicer, which provides the RTP-level integration of the media
+ payloads in a common timeline and synchronization context.
+
+ Since the splicer breaks RTP-level end-to-end security, it needs to
+ be part of the signaling context and the necessary security
+ associations (e.g., Secure Real-time Transport Protocol (SRTP)
+
+
+
+Xia, et al. Standards Track [Page 18]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ [RFC3711] crypto contexts) established for the RTP session
+ participants. When using SRTP, the splicer would have to be
+ provisioned with the same security association as the main RTP
+ sender.
+
+ If there are concerns about the confidentiality of the splicing time
+ information, the header extension defined in this document MUST also
+ be protected; for example, header extension encryption [RFC6904] can
+ be used in this case. However, the malicious endpoint may get the
+ splicing time information by other means, e.g., inferring it from the
+ communication between the main and substitutive content sources. To
+ avoid the insertion of invalid substitutive content, the splicer MUST
+ have some mechanisms to authenticate the substitutive stream source.
+
+ For cases where the splicing time information is changed by a
+ malicious endpoint, the splicing, for example, may fail, since it
+ will not be available at the right time for the substitutive media to
+ arrive. Another case is one where an attacker may prevent the
+ receivers from receiving the content from the main sender by
+ inserting extra splicing time information. To avoid the above
+ scenarios, the authentication of the RTP header extension for
+ splicing time information SHOULD be considered.
+
+ When a splicer implemented as a mixer sends the stream to the
+ receivers, the CSRC list, which can be used to detect RTP-level
+ forwarding loops as defined in Section 8.2 of [RFC3550], may be
+ removed for simplifying the receivers that cannot handle multiple
+ sources in the RTP stream. Hence, loops may occur, causing packets
+ to loop back to a point upstream of the splicer and possibly forming
+ a serious denial-of-service threat. In such a case, non-RTP means,
+ e.g., signaling among all the participants, MUST be used to detect
+ and resolve loops.
+
+8. IANA Considerations
+
+8.1. RTCP Control Packet Types
+
+ Based on the guidelines suggested in [RFC8126], a new RTCP packet
+ format has been registered in the "RTCP Control Packet types (PT)"
+ registry:
+
+ Name: SNM
+
+ Long name: Splicing Notification Message
+
+ Value: 213
+
+ Reference: This document
+
+
+
+Xia, et al. Standards Track [Page 19]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+8.2. RTP Compact Header Extensions
+
+ IANA has registered a new RTP Compact Header Extension [RFC8285],
+ according to the following:
+
+ Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
+
+ Description: Splicing Interval
+
+ Contact: Jinwei Xia <xiajinwei@huawei.com>
+
+ Reference: This document
+
+8.3. SDP Grouping Semantic Extension
+
+ IANA has registered the new SDP grouping semantic extension called
+ "SPLICE" in the "Semantics for the 'group' SDP Attribute" subregistry
+ of the "Session Description Protocol (SDP) Parameters" registry:
+
+ Semantics: Splice
+
+ Token: SPLICE
+
+ Reference: This document
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+ with Session Description Protocol (SDP)", RFC 3264,
+ DOI 10.17487/RFC3264, June 2002,
+ <https://www.rfc-editor.org/info/rfc3264>.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+ July 2003, <https://www.rfc-editor.org/info/rfc3550>.
+
+ [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
+ Protocol (SDP) Grouping Framework", RFC 5888,
+ DOI 10.17487/RFC5888, June 2010,
+ <https://www.rfc-editor.org/info/rfc5888>.
+
+
+
+Xia, et al. Standards Track [Page 20]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+ "Network Time Protocol Version 4: Protocol and Algorithms
+ Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
+ <https://www.rfc-editor.org/info/rfc5905>.
+
+ [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
+ Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
+ <https://www.rfc-editor.org/info/rfc6051>.
+
+ [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
+ Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
+ <https://www.rfc-editor.org/info/rfc7201>.
+
+ [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
+ DOI 10.17487/RFC7667, November 2015,
+ <https://www.rfc-editor.org/info/rfc7667>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
+ Mechanism for RTP Header Extensions", RFC 8285,
+ DOI 10.17487/RFC8285, October 2017,
+ <https://www.rfc-editor.org/info/rfc8285>.
+
+9.2. Informative References
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, DOI 10.17487/RFC3711, March 2004,
+ <https://www.rfc-editor.org/info/rfc3711>.
+
+ [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
+ Real-Time Transport Control Protocol (RTCP): Opportunities
+ and Consequences", RFC 5506, DOI 10.17487/RFC5506,
+ April 2009, <https://www.rfc-editor.org/info/rfc5506>.
+
+ [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
+ "Unicast-Based Rapid Acquisition of Multicast RTP
+ Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011,
+ <https://www.rfc-editor.org/info/rfc6285>.
+
+ [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828,
+ DOI 10.17487/RFC6828, January 2013,
+ <https://www.rfc-editor.org/info/rfc6828>.
+
+
+
+
+Xia, et al. Standards Track [Page 21]
+
+RFC 8286 RTP Splicing Notification October 2017
+
+
+ [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
+ Real-time Transport Protocol (SRTP)", RFC 6904,
+ DOI 10.17487/RFC6904, April 2013,
+ <https://www.rfc-editor.org/info/rfc6904>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+ [SCTE35] Society of Cable Telecommunications Engineers (SCTE),
+ "Digital Program Insertion Cueing Message for Cable",
+ 2016, <http://www.scte.org/SCTEDocs/Standards/
+ SCTE%2035%202016.pdf>.
+
+Acknowledgements
+
+ The authors would like to thank the following individuals who helped
+ to review this document and provided very valuable comments: Colin
+ Perkins, Bo Burman, Stephen Botzko, and Ben Campbell.
+
+Authors' Addresses
+
+ Jinwei Xia
+ Huawei
+
+ Email: xiajinwei@huawei.com
+
+
+ Roni Even
+ Huawei
+
+ Email: roni.even@huawei.com
+
+
+ Rachel Huang
+ Huawei
+
+ Email: rachel.huang@huawei.com
+
+
+ Lingli Deng
+ China Mobile
+
+ Email: denglingli@chinamobile.com
+
+
+
+
+
+
+Xia, et al. Standards Track [Page 22]
+