draft-ietf-avtext-splicing-notification-00.txt   draft-ietf-avtext-splicing-notification-01.txt 
AVTEXT Working Group J. Xia AVTEXT Working Group J. Xia
INTERNET-DRAFT R. Even INTERNET-DRAFT R. Even
Intended Status: Standards Track R. Huang Intended Status: Standards Track R. Huang
Expires: January 30, 2015 Huawei Expires: June 13, 2015 Huawei
L. Deng L. Deng
China Mobile China Mobile
July 29, 2014 December 10, 2014
RTP/RTCP Extension for RTP Splicing Notification RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-00 draft-ietf-avtext-splicing-notification-01
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 delivers the
substitutive multimedia content to the receivers for a period of substitutive multimedia content to the receivers for a period of
time. The RTP mixer is designed to handle RTP splicing in [RFC6828], time. The splicer is designed to handle RTP splicing and needs to
but how the RTP mixer knows when to start and end the splicing is know when to start and end the splicing.
still unspecified.
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 RTP mixer: 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 RTCP packet that conveys the
information out-of-band. information out-of-band.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 of RTP Splicing Notification . . . . . . . . . . . . . 4 2 Overview of RTP Splicing Notification . . . . . . . . . . . . . 4
3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5
3.1 RTP Header Extention . . . . . . . . . . . . . . . . . . . . 5 3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5
3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6
4 Reduing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7
5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 7 5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9
8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 9 6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10
8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 10 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12
9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
10.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 14
10.2 Informative References . . . . . . . . . . . . . . . . . . 11 8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3 SDP Grouping Semantic Extension . . . . . . . . . . . . . . 14
9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1 Normative References . . . . . . . . . . . . . . . . . . . 15
10.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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
MUST be inside of the specific, pre-designated time slot. Certain MUST 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 mixer to start the splicing. This document first acquired by the splicer in order to start the splicing. This
refers to this information as Splicing Interval. document refers to this information as 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. But in RTP splicing inside the MPEG2-TS layer in cable TV systems. But in the RTP
scenario described in [RFC6828], the mixer has to decode the RTP splicing scenario described in [RFC6828], the RTP mixer designed as
packets, search and solve the Splicing Interval inside the payloads. the splicer has to decode the RTP packets and search for the Splicing
The need for such processing enhances the workload of the mixer and Interval inside the payloads. The need for such processing increases
limits the size of RTP sessions the mixer can support. the workload of the mixer and limits the number of RTP sessions the
mixer can support.
The document defines an RTP header extension [RFC5285] through which The document defines an RTP header extension [RFC5285] used by the
the main RTP sender can provide the Splicing Interval by including it main RTP sender to provide the Splicing Interval by including it in
in the RTP packets. the RTP packets.
Nevertheless, the Splicing Interval conveyed in the RTP header Nevertheless, the Splicing Interval conveyed in the RTP header
extension might not reach the mixer successfully, any splicing un- extension might not reach the mixer successfully, any splicing un-
aware middlebox on the path between the RTP sender and the mixer aware middlebox on the path between the RTP sender and the mixer
might strip the RTP header extension. might strip this RTP header extension.
To increase robustness against above case, the document also defines To increase robustness against such case, the document also defines a
a new RTCP packet type in a complementary fashion to carry the new RTCP packet type in a complementary fashion to carry the same
Splicing Interval to the mixer even though RTCP is inherently Splicing Interval to the mixer.
unreliable too.
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Most terminology defined in "Content Splicing for RTP Sessions" The terminology defined in "Content Splicing for RTP Sessions"
[RFC6828] applies to this document except the following one. [RFC6828] applies to this document and in addition, we define:
Splicing Interval: Splicing Interval:
A set of certain metadata that allows the mixer to know when to The NTP timestamps for the Splicing-In point and Splicing-Out
start and end the RTP splicing. The information consists of a point per [RFC6828] allowing the mixer to know when to start and
couple of NTP-format timestamps on the splicing in point and on end the RTP splicing.
the splicing out point.
2 Overview of RTP Splicing Notification 2 Overview of RTP Splicing Notification
According to RTP Splicing draft [RFC6828], a mixer is designed to do According to RTP Splicing draft [RFC6828], a mixer is designed to
splicing on the RTP layer, but it cannot insert the substitutive handle splicing on the RTP layer at the reserved time slots set by
content randomly but only do that at the reserved time slots set by the main RTP sender. This implies that the mixer must first know the
the main RTP sender. This implies the mixer must first know the Splicing Interval from the main RTP sender before it can start
Splicing Interval from the main RTP sender before splicing starts. splicing.
When a new splicing is forthcoming, the main RTP sender MUST send the When a new splicing is forthcoming, the main RTP sender MUST send the
Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD
be sent more than once to against the possible packet loss. To enable be sent more than once to mitigate the possible packet loss. To
the mixer to get the substitutive content before the splicing starts, enable the mixer to get the substitutive content before the splicing
the main RTP sender MUST send the Splicing Interval far enough in starts, the main RTP sender MUST send the Splicing Interval far
advance. Alternatively, the main RTP sender can estimate when to send ahead. For example, the main RTP sender can estimate when to send the
the Splicing Interval based on the round-trip time (RTT) following Splicing Interval based on the round-trip time (RTT) following the
the mechanisms in section 6.4.1 of [RFC3550] when the mixer sends mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR
RTCP RR to the main sender. 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 thus estimates when to
transfer the substitutive content to the mixer. The Splicing Interval transfer the substitutive content to the mixer. The Splicing Interval
could be transmitted from the main RTP sender to the substitutive could be transmitted from the main RTP sender to the substitutive
content using some out-of-band mechanisms, the details how to achieve content using some out-of-band mechanisms, the details how to achieve
that are beyond the scope of this memo. To ensure the Splicing that are beyond the scope of this memo. To ensure the Splicing
Interval is valid to the main RTP sender and the substitutive RTP Interval is valid for both the main RTP sender and the substitutive
sender, the two senders MUST share a common reference clock, so the RTP sender, the two senders MUST share a common reference clock, so
mixer can achieve accurate splicing. the mixer can achieve accurate splicing.
In this document, the main RTP sender uses a couple of NTP-format In this document, the main RTP sender uses a couple of NTP-format
timestamps, derived from the common reference clock, to indicate when timestamps, derived from the common reference clock, to indicate when
to start and end the splicing to the mixer: the timestamp of the to start and end the splicing to the mixer: the timestamp of the
first substitutive RTP packet on the splicing in point, and the first substitutive RTP packet at the splicing in point, and the
timestamp of the first main RTP packet on the splicing out point. timestamp of the first main RTP packet at the 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 RTP timestamp of the first prepare the substitutive stream. The mixer MUST ensure that the RTP
substitutive RTP packet that would be presented on the receivers MUST timestamp of the first substitutive RTP packet that would be
correspond to the same time instant as the former NTP timestamp in presented to the receivers corresponds to the same time instant as
the Splicing Interval. To enable mixer to know the first substitutive the former NTP timestamp in the Splicing Interval. To enable the
RTP packet it begins to output, the substitutive RTP sender MUST mixer to know the first substitutive RTP packet it needs to send, the
enable the mixer to know above RTP timestamp in advance, e.g., from substitutive RTP sender MUST send the substitutive RTP packet ahead
prior receipt of RTCP SR message. of the Splicing In point, sllowing the mixer to find out the
timestamp of this first RTP packet in the substitutive RTP stream,
e.g., using a prior RTCP SR message.
When the splicing will end, the RTP timestamp of the first main RTP When the splicing will end, the mixer MUST ensure that the RTP
packet that would be presented on the receivers MUST correspond to timestamp of the first main RTP packet that would be presented on the
the same time instant as the latter NTP timestamp in the Splicing receivers corresponds to the same time instant as the latter NTP
Interval. 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 backwards compatible RTP extensions to convey
the Splicing Interval to the mixer: an RTP header extension and an the Splicing Interval to the mixer: an RTP header extension and an
RTCP splicing notification message. RTCP splicing notification message.
3.1 RTP Header Extention 3.1 RTP Header Extension
The RTP header extension mechanism defined in [RFC5285] can be The RTP header extension mechanism defined in [RFC5285] can be
adapted to carry the Splicing Interval consisting of a couple of NTP- adapted to carry the Splicing Interval consisting of a couple of NTP-
format timestamps. format timestamps.
One variant is defined for this header extension. It carries the 7 One variant is defined for this header extension. It carries the 7
octets splicing-out NTP timestamp (lower 24-bit part of the Seconds octets splicing-out NTP timestamp (lower 24-bit part of the Seconds
of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- of a NTP-format timestamp and the 32 bits of the Fraction of a NTP-
format timestamp as defined in [RFC5905]), followed by the 8 octets format timestamp as defined in [RFC5905]), followed by the 8 octets
splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in
[RFC5905]). The top 8 bits of the splicing-out NTP timestamp are [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are
referred from the top 8 bits of the splicing-in NTP timestamp, under referred from the top 8 bits of the splicing-in NTP timestamp. This
the consumption that the splicing-out time is after the splicing-in is unambiguous, under the assumption that the splicing-out time is
time, and the splicing interval is less than 2^25 seconds, this order after the splicing-in time, and the splicing interval is less than
allows full resolution for splicing-in NTP timestamp while keeping 4 2^25 seconds.
octets alignment.
The format is shown in Figures 1. The format is shown in Figures 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=4 | | 0xBE | 0xDE | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x | ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
skipping to change at page 5, line 51 skipping to change at page 6, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN NTP timestamp format - Fraction (bit 0-31) |o | IN NTP timestamp format - Fraction (bit 0-31) |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
Figure 1: Sample hybrid NTP Encoding Using Figure 1: Sample hybrid NTP Encoding Using
the One-Byte Header Format the One-Byte Header Format
Note that the inclusion of an RTP header extension will reduce the Note that 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 begins to insert the RTP header extensions into a number of sender begins to insert the RTP header extensions into a number of
RTP packets in advance of the splicing starting, while leaving the RTP packets prior to the splicing in, while leaving the remaining RTP
remain RTP packets unmarked. packets unmarked.
After the mixer intercepts the RTP header extension and derives the After the mixer intercepts the RTP header extension and derives the
Splicing Interval, it will generate its own stream and could not Splicing Interval, it will generate its own stream and SHOULD NOT
include the RTP header extension in outgoing packets to reduce header include the RTP header extension in outgoing packets to reduce header
overhead. overhead.
Furthermore, whether the in-band NTP-format timestamps are included Furthermore, whether the in-band NTP-format timestamps are included
or not, RTCP splicing notification message in next section MUST be or not, RTCP splicing notification message, specified in the next
sent to provide robustness in the case of any splicing-unaware section, MUST be sent to provide robustness in case of any splicing-
middlebox that might strip RTP header extensions. unaware middlebox that might strip RTP header extensions.
3.2 RTCP Splicing Notification Message 3.2 RTCP Splicing Notification Message
Besides the RTP header extension, the main RTP sender includes the In addition to the RTP header extension, the main RTP sender includes
Splicing Interval in an RTCP splicing notification message. the Splicing Interval in an RTCP splicing notification message.
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 fix header followed by a couple of NTP-format timestamps: has a fix header followed by a couple of NTP-format 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=TBA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
skipping to change at page 7, line 27 skipping to change at page 7, line 30
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 mixer, the RTCP splicing notification between the sender and the mixer, the RTCP splicing notification
message may be sent as non-compound RTCP packets. message may be sent as non-compound RTCP packets.
When the mixer intercepts the RTCP splicing notification message, it When the mixer intercepts the RTCP splicing notification message, it
MAY NOT forward the message to the receivers in order to reduce RTCP MAY NOT forward the message to the receivers in order to reduce RTCP
bandwidth consumption or to avoid downstream receivers from detecting bandwidth consumption or to avoid downstream receivers from detecting
splicing defined in Section 4.5 in [RFC6828]. splicing defined in Section 4.5 in [RFC6828].
4 Reduing Splicing Latency 4 Reducing Splicing Latency
When splicing starts or ends, the mixer outputs the multimedia When splicing starts or ends, the mixer 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 align with its sender SHOULD provide the Reference Information align 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 means by which the Reference Information Reference Information. The methods by which the Reference Information
is distributed to the receivers is out of scope of this memo. is distributed to the receivers is out of scope of this memo.
Another latency element is synchronization caused delay. The Another latency element is synchronization caused delay. 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 mechanisms defined in [RFC6051] are synchronized fashion. The mechanisms defined in [RFC6051] are
RECOMMENDED to be adopted to reduce the possible synchronization RECOMMENDED to be adopted to reduce the possible synchronization
skipping to change at page 8, line 4 skipping to change at page 8, line 6
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 mechanisms defined in [RFC6051] are synchronized fashion. The mechanisms defined in [RFC6051] are
RECOMMENDED to be adopted to reduce the possible synchronization RECOMMENDED to be adopted to reduce the possible synchronization
delay. delay.
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 other failure case, e.g., the RTP header notification message and other failure case, e.g., the RTP header
extension is stripped on the path. extension is stripped on the path.
Given there may be splicing un-aware middlebox on the path between Given that there may be splicing un-aware middlebox on the path
the main RTP sender and the mixer, one heuristics will be used to between the main RTP sender and the mixer, one heuristics will be
verify whether or not the Splicing Interval reaches the mixers. used to verify whether or not the Splicing Interval reaches the
mixers.
If the mixer does not get the Splicing Interval when the splicing If the mixer does not get the Splicing Interval when the splicing
starts, it will still output the main content to the downstream starts, it will still output the main content to the downstream
receivers and forward the RTCP RR packets sent from downstream receivers and forward the RTCP RR packets sent from downstream
receivers to the main RTP sender. In such case, the main RTP sender receivers to the main RTP sender (see section 4.2 of [RFC6828]). In
can learn the splicing failed. such case, the main RTP sender can learn that splicing failed.
In a similar manner, the substitutive sender can learn the splicing In a similar manner, the substitutive sender can learn that splicing
failed if it does not receive any RTCP RR packets from downstream failed if it does not receive any RTCP RR packets from downstream
receivers when the splicing starts. receivers when the splicing starts.
Upon the detection of a failure, the main RTP sender or the Upon the detection of a failure, the main RTP sender or the
substitutive sender SHOULD check the path to the failed mixer, or substitutive sender SHOULD check the path to the failed mixer, or
fallback to the payload specific mechanisms, e.g., MPEG-TS splicing fallback to the payload specific mechanisms, e.g., MPEG-TS splicing
solution defined in [SCTE35]. solution defined in [SCTE35].
6 SDP Signaling 6 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 "urn:ietf:params:rtp-hdrext:splicing-
interval". interval".
This document also reuses the Flow Identification (FID) semantics This document extended the standard semantics defined in SDP Grouping
defined in SDP Grouping Framework [RFC5888] to represent the Framework [RFC5888] with a new semantic: SPLICE to represent the
relationship between the main RTP stream and the substitutive RTP relationship between the main RTP stream and the substitutive RTP
stream. stream. The main RTP sender provides the information about both main
and substitutive sources.
The next example shows how the "group" attribute used with FID The extended SDP attribute specified in this document is applicable
semantics can indicate RTP splicing support on RTP sender. for offer/answer content [RFC3264] and do not affect any rules when
negotiating offer and answer. When used with multiple media,
substitutive RTP MUST be applied only to the RTP packets whose SDP m-
line is in the same group with the substitutive stream using FID and
has the extended splicing extmap attribute. This semantics is to have
splicing 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 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:FID 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 30001 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=mid: 2 a=rtpmap:100 MP2T/90000
a=mid:2
Figure 3: Example SDP for a single-channel splicing scenario Figure 3: Example SDP for a single-channel splicing scenario
The mixer receiving the SDP message above receives one MPEG2-TS The mixer 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 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
multicast destination address of 233.252.0.2) on port 30001. But at multicast destination address of 233.252.0.2) on port 30002. But at
a particular point in time, the mixer only selects one stream and a particular point in time, the mixer only selects one stream and
output 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
SDP Offer - from 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=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
SDP Answer - from 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=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
Only codecs that are supported both by the main RTP stream and the
substitutive RTP stream could be negotiated with SDP O/A. And the
mixer MUST choose the same codec for both of these two streams.
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 leave the substitutive media untouched.
SDP Offer - from 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
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
m=audio 20000 RTP/AVP 0 8 97
i=Substitutive audio RTP Stream
c=IN IP4 substitive.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 substitive.example.com
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=mid:2
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
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
m=audio 30002 RTP/AVP 0
i=Substitutive audio RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:0 PCMU/8000
a=sendonly
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
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 leave the substitutive media untouched.
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
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
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
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
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
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
7 Security Considerations 7 Security Considerations
The security considerations of the RTP specification [RFC3550], the The security considerations of the RTP specification [RFC3550], the
general mechanism for RTP header extensions [RFC5285] and the general mechanism for RTP header extensions [RFC5285] and the
security considerations of the RTP splicing specification [RFC6828] security considerations of the RTP splicing specification [RFC6828]
apply. apply.
The RTP header extension defined in Section 4.1 include two NTP- The RTP header extension defined in Section 4.1 include two NTP-
format timestamps. In the Secure Real-time Transport Protocol format timestamps. In the Secure Real-time Transport Protocol
(SRTP)[RFC3711], RTP header extensions are authenticated but not (SRTP)[RFC3711], RTP header extensions are authenticated but not
encrypted. A malicious endpoint could choose to set the values in encrypted. A malicious endpoint possessing the SRTP key could choose
this header extension falsely, so as to falsely claim the splicing to set the values in this header extension falsely, so as to falsely
time. claim the splicing time. Also, such a malicious endpoint could cause
any arbitrary content it wishes spliced into the main RTP stream.
In scenarios where this is a concern, additional mechanisms MUST be In scenarios where this is a concern, additional mechanisms MUST be
used to protect the confidentiality of the header extension. This used to protect the confidentiality of the header extension. This
mechanism could be header extension encryption [SRTP-ENCR-HDR], or a mechanism could be header extension encryption [SRTP-ENCR-HDR], or a
lower-level security and authentication mechanism such as IPsec lower-level security and authentication mechanism such as IPsec
[RFC4301]. [RFC4301].
8 IANA Considerations 8 IANA Considerations
8.1 RTCP Control Packet Types 8.1 RTCP Control Packet Types
skipping to change at page 10, line 26 skipping to change at page 14, line 42
[RFC5285], according to the following: [RFC5285], according to the following:
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Description: Splicing Interval Description: Splicing Interval
Contact: Jinwei Xia <xiajinwei@huawei.com> Contact: Jinwei Xia <xiajinwei@huawei.com>
Reference: This document Reference: This document
8.3 SDP Grouping Semantic Extension
This document request IANA to register the new SDP grouping semantic
extension called "SPLICE".
Semantics: Splice
Token:SPLICE
Reference: This document
Contact: Jinwei Xia <xiajinwei@huawei.com>
9 Acknowledges 9 Acknowledges
TBD TBD
10 References 10 References
10.1 Normative References 10.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, March 1997.
 End of changes. 44 change blocks. 
105 lines changed or deleted 329 lines changed or added

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