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

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/