AVTEXT Working Group J. Xia
INTERNET-DRAFT R. Even
Intended Status: Standards Track R. Huang
Expires: July 29, 2016 Huawei
L. Deng
China Mobile
January 26, 2016
RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-04
Abstract
Content splicing is a process that replaces the content of a main
multimedia stream with other multimedia content, and delivers the
substitutive multimedia content to the receivers for a period of
time. The splicer is designed to handle RTP splicing and needs to
know when to start and end the splicing.
This memo defines two RTP/RTCP extensions to indicate the splicing
related information to the splicer: an RTP header extension that
conveys the information in-band and an RTCP 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
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
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
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Xia Expires July 29, 2016 [Page 1]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Overview of RTP Splicing Notification . . . . . . . . . . . . . 4
3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5
3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5
3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6
4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7
5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9
6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9
6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10
6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 14
8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 14
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
Xia Expires July 29, 2016 [Page 2]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
1 Introduction
Splicing is a process that replaces some multimedia content with
other multimedia content and delivers the substitutive multimedia
content to the receivers for a period of time. In some predictable
splicing cases, e.g., advertisement insertion, the splicing duration
needs to be inside of the specific, pre-designated time slot.
Certain timing information about when to start and end the splicing
must be first acquired by the splicer in order to start the splicing.
This document refers to this information as the Splicing Interval.
[SCTE35] provides a method that encapsulates the Splicing Interval
inside the MPEG2-TS layer in cable TV systems. When transported in
RTP, an middle box designed as the splicer to decode the RTP packets
and search for the Splicing Interval inside the payloads is required.
The middle box is either a translator or a mixer as described in
[RFC6828]. The need for such processing increases the workload of the
middle box and limits the number of RTP sessions the middle box can
support.
The document defines an RTP header extension [RFC5285] used by the
main RTP sender to provide the Splicing Interval by including it in
the RTP packets.
Nevertheless, the Splicing Interval conveyed in the RTP header
extension might not reach the splicer successfully. Any splicing un-
aware middlebox on the path between the RTP sender might strip this
RTP header extension.
To increase robustness against such case, the document also defines a
complementary RTCP packet type to carry the same Splicing Interval to
the splicer.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, we define following terminologies:
Main RTP sender:
The sender of RTP packets carrying the main RTP stream.
Splicer:
An intermediary node that inserts substitutive content into a main
Xia Expires July 29, 2016 [Page 3]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
RTP stream. The splicer sends substitutive content to the RTP
receiver instead of the main content during splicing. It is also
responsible for processing RTCP traffic between the RTP sender and
the RTP receiver.
Splicing-In Point
A virtual point in the RTP stream, suitable for substitutive
content entry, typically in the boundary between two independently
decodable frames.
Splicing-Out Point
A virtual point in the RTP stream, suitable for substitutive
content exit, typically in the boundary between two independently
decodable frames.
Splicing Interval:
The NTP timestamps for the Splicing-In point and Splicing-Out
point per [RFC6828] allowing the splicer to know when to start and
end the RTP splicing.
Substitutive RTP Sender:
The sender of RTP packets carrying the RTP stream that will
replace the content in the main RTP stream.
2 Overview of RTP Splicing Notification
A splicer is designed to handle splicing on the RTP layer at the
reserved time slots set by the main RTP sender. This implies that the
splicer must first know the Splicing Interval from the main RTP
sender before it can start splicing. The splicer can be a mixer as
described in [RFC6828].
When a new splicing is forthcoming, the main RTP sender needs to send
the Splicing Interval to the splicer. The Splicing Interval SHOULD be
sent more than once to mitigate the possible packet loss. To enable
the splicer to get the substitutive content before the splicing
starts, the main RTP sender MUST send the Splicing Interval far
ahead. For example, the main RTP sender can estimate when to send the
Splicing Interval based on the round-trip time (RTT) following the
mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP
RR to the main sender.
The substitutive sender also needs to learn the Splicing Interval
Xia Expires July 29, 2016 [Page 4]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
from the main RTP sender in advance, and thus estimates when to
transfer the substitutive content to the splicer. The Splicing
Interval could be transmitted from the main RTP sender to the
substitutive content using some out-of-band mechanisms, for example,
a proprietary mechanism to exchange the Splicing Interval, or the
substitutive sender is implemented together with the main RTP sender
inside a single device. To ensure the Splicing Interval is valid for
both the main RTP sender and the substitutive RTP sender, the two
senders MUST share a common reference clock so that the splicer can
achieve accurate splicing. The requirements for the common reference
clock (e.g. resolution, skew) depend on the codec used by the media
content.
In this document, the main RTP sender uses a pair of NTP-format
timestamps, to indicate when to start and end the splicing to the
splicer: the timestamp of the first substitutive RTP packet at the
splicing in point, and the timestamp of the first main RTP packet at
the splicing out point.
When the substitutive RTP sender gets the Splicing Interval, it must
prepare the substitutive stream. The main and the substitutive
content providers MUST ensure that the RTP timestamp of the first
substitutive RTP packet that would be presented to the receivers
corresponds to the same time instant as the former NTP timestamp in
the Splicing Interval. To enable the splicer to know the first
substitutive RTP packet it needs to send, the substitutive RTP sender
MUST send the substitutive RTP packet ahead of the Splicing In point,
allowing the splicer to find out the timestamp of this first RTP
packet in the substitutive RTP stream, e.g., using a prior RTCP SR
message.
When the splicing will end, the main content provider and the
substitutive content provider MUST ensure the RTP timestamp of the
first main RTP packet that would be presented on the receivers
corresponds to the same time instant as the latter NTP timestamp in
the Splicing Interval.
3 Conveying Splicing Interval in RTP/RTCP extensions
This memo defines two backwards compatible RTP extensions to convey
the Splicing Interval to the splicer: an RTP header extension and an
RTCP splicing notification message.
3.1 RTP Header Extension
The RTP header extension mechanism defined in [RFC5285] can be
Xia Expires July 29, 2016 [Page 5]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
adapted to carry the Splicing Interval consisting of a pair of NTP-
format timestamps.
One variant is defined for this header extension. It carries the 7
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-
format timestamp as defined in [RFC5905]), followed by the 8 octets
splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in
[RFC5905]). The top 8 bits of the splicing-out NTP timestamp are
inferred from the top 8 bits of the splicing-in NTP timestamp. This
is unambiguous, under the assumption that the splicing-out time is
after the splicing-in time, and the splicing interval is less than
2^25 seconds. If the 7 octets splicing-out NTP timestamp is smaller
than the lower 7 octets splicing-in NTP timestamp, it implies a wrap
of the 64-bit splicing-out NTP timestamp which will then be
calculated by the 7 octets splicing-out NTP timestamp plus
0x100000000. Otherwise, the top 8 octets of splicing-out NTP
timestamp is equal to the top 8 octets of splicing-in NTP timestamp.
The format is shown in Figures 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| OUT NTP timestamp format - Fraction (bit 0-31) |e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| IN NTP timestamp format - Seconds (bit 0-31) |s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN NTP timestamp format - Fraction (bit 0-31) |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
Figure 1: Sample hybrid NTP Encoding Using
the One-Byte Header Format
Since the inclusion of an RTP header extension will reduce the
efficiency of RTP header compression, it is RECOMMENDED that the main
sender inserts the RTP header extensions into only a number of RTP
packets, instead of all the RTP packets, prior to the splicing in.
After the splicer intercepts the RTP header extension and derives the
Splicing Interval, it will generate its own stream and SHOULD NOT
include the RTP header extension in outgoing packets to reduce header
overhead.
Xia Expires July 29, 2016 [Page 6]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
3.2 RTCP Splicing Notification Message
In addition to the RTP header extension, the main RTP sender includes
the Splicing Interval in an RTCP splicing notification message.
Whether or not the timestamps are included in the RTP header
extension, the main RTP sender MUST send the RTCP splicing
notification message. This provide robustness in the case where a
middlebox strips RTP header extensions.
The RTCP splicing notification message is a new RTCP packet type. It
has a fixed header followed by a pair of NTP-format timestamps:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=TBA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN NTP Timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN NTP Timestamp (least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUT NTP Timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUT NTP Timestamp (least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RTCP Splicing Notification Message
The RSI packet includes the following fields:
Length: 16 bits
As defined in [RFC3550], the length of the RTCP packet in 32-bit
words minus one, including the header and any padding.
SSRC: 32 bits
The SSRC of the Main RTP Sender.
Timestamp: 64 bits
Indicates the wallclock time when this splicing starts and ends.
The full-resolution NTP timestamp is used, which is a 64-bit,
unsigned, fixed-point number with the integer part in the first 32
Xia Expires July 29, 2016 [Page 7]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
bits and the fractional part in the last 32 bits. This format is
similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550]).
The RTCP splicing notification message can be appended to RTCP SR the
main RTP sender generates in compound RTCP packets, and hence follows
the compound RTCP rules defined in Section 6.1 in [RFC3550].
If the use of non-compound RTCP [RFC5506] was previously negotiated
between the sender and the splicer, the RTCP splicing notification
message may be sent as non-compound RTCP packets.
When the splicer intercepts the RTCP splicing notification message,
it SHOULD NOT forward the message to the down-stream receivers in
order to reduce RTCP bandwidth consumption. And if the splicer wishes
to prevent the downstream receivers from detecting splicing, it MUST
NOT forward the message.
4 Reducing Splicing Latency
When splicing starts or ends, the splicer outputs the multimedia
content from another sender to the receivers. Given that the
receivers must first acquire certain information ([RFC6285] refers to
this information as Reference Information) to start processing the
multimedia data, either the main RTP sender or the substitutive
sender SHOULD provide the Reference Information together with its
multimedia content to reduce the delay caused by acquiring the
Reference Information. The methods by which the Reference Information
is distributed to the receivers is out of scope of this memo.
Another latency element is synchronization caused delay. The
receivers must receive enough synchronization metadata prior to
synchronizing the separate components of the multimedia streams when
splicing starts or ends. Either the main RTP sender or the
substitutive sender SHOULD send the synchronization metadata early
enough so that the receivers can play out the multimedia in a
synchronized fashion. The main RTP sender and the substitutive sender
can be coordinated by some proprietary out-of-band mechanisms to
decide when and whom to send the metadata. If both send the
information, the splicer SHOULD pick one based on the current
situation, e.g., choosing media sender when synchronizing the main
media content while choosing the information from the substitutive
sender when synchronizing the spliced content. The mechanisms defined
in [RFC6051] are RECOMMENDED to be adopted to reduce the possible
synchronization delay.
Xia Expires July 29, 2016 [Page 8]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
5 Failure Cases
This section examines the implications of losing RTCP splicing
notification message and the other failure case, e.g., the RTP header
extension is stripped on the path.
Given that there may be a splicing un-aware middlebox on the path
between the main RTP sender and the splicer, the main and the
substitutive RTP senders can use one heuristic to verify whether or
not the Splicing Interval reaches the splicer.
The splicer can be implemented to have its own SSRC, and send RTCP
reception reports to the senders of the main and substitutive RTP
streams. This allows the senders to detect problems on the path to
the splicer. Alternatively, it is possible to implement the splicer
such that it has no SSRC, and does not send RTCP reports; this
prevents the senders from being able to monitor the quality to the
path to the splicer.
If the splicer has an SSRC and sends its own RTCP reports, it can
choose not to pass RTCP reports it receives from the receivers to the
senders. This will stop the senders from being able to monitor the
quality of the paths from the splicer to the receivers.
A splicer that has an SSRC can choose to pass RTCP reception reports
from the receivers back to the senders, after modifications to
account for the splicing. This will allow the senders the monitor the
quality of the paths from the splicer to the receivers. A splicer
that does not have its own SSRC has to forward and translation RTCP
reports from the receiver, otherwise the senders will not see any
receivers in the RTP session.
If the splicer is implemented following [RFC6828], it will have its
own SSRC and will send its own RTCP reports, and will forward
translated RTCP reports from the receivers.
Upon the detection of a failure, the splicer can communicate with the
main sender and the substitutive sender in some out of band signaling
ways to fall back to the payload specific mechanisms it supports,
e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon
the splicing.
6 Session Description Protocol (SDP) Signaling
This document defines the URI for declaring this header extension in
an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing-
interval".
Xia Expires July 29, 2016 [Page 9]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
This document extends the standard semantics defined in SDP Grouping
Framework [RFC5888] with a new semantic: SPLICE to represent the
relationship between the main RTP stream and the substitutive RTP
stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP
stream is the one with the extended extmap attribute, and the other
one is substitutive stream. A single m-line MUST NOT be included in
different SPLICE groups at the same time. The main RTP sender
provides the information about both main and substitutive sources.
The extended SDP attribute specified in this document is applicable
for offer/answer content [RFC3264] and do not affect any rules when
negotiating offer and answer. When used with multiple m-lines,
substitutive RTP MUST be applied only to the RTP packets whose SDP m-
line is in the same group with the substitutive stream using SPLICE
and has the extended splicing extmap attribute. This semantic is also
applicable for BUNDLE cases.
The following examples show how SDP signaling could be used for
splicing in different cases.
6.1 Declarative SDP
v=0
o=xia 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example
t=0 0
a=group:SPLICE 1 2
m=video 30000 RTP/AVP 100
i=Main RTP Stream
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=mid:1
m=video 30002 RTP/AVP 100
i=Substitutive RTP Stream
c=IN IP4 233.252.0.2/127
a=sendonly
a=rtpmap:100 MP2T/90000
a=mid:2
Figure 3: Example SDP for a single-channel splicing scenario
The splicer receiving the SDP message above receives one MPEG2-TS
stream (payload 100) from the main RTP sender (with multicast
destination address of 233.252.0.1) on port 30000, and/or receives
another MPEG2-TS stream from the substitutive RTP sender (with
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
Xia Expires July 29, 2016 [Page 10]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
outputs the content from the chosen stream to the downstream
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=sendonly
a=mid:1
m=video 40000 RTP/AVP 31 100
i=Substitutive RTP Stream
c=IN IP4 substitutive.example.com
a=rtpmap:31 H261/90000
a=rtpmap:100 MP2T/90000
a=sendonly
a=mid:2
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=recvonly
a=mid:1
m=video 40000 RTP/AVP 100
i=Substitutive RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:100 MP2T/90000
a=recvonly
a=mid:2
Xia Expires July 29, 2016 [Page 11]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
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
splicer 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
a=sendonly
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=audio 20000 RTP/AVP 0 8 97
i=Substitutive audio RTP Stream
c=IN IP4 substitive.example.com
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
Xia Expires July 29, 2016 [Page 12]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
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
a=sendonly
SDP Answer - from the splicer
v=0
o=bob 2808844564 2808844564 IN IP4 splicer.example.com
s=RTP Splicing Example
c=IN IP4 splicer.example.com
t=0 0
a=group:SPLICE foo 1
a=group:SPLICE bar 2
a=group:BUNDLE foo bar
m=audio 30000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=video 30000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=audio 30002 RTP/AVP 0
i=Substitutive audio RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:0 PCMU/8000
a=recvonly
a=mid:1
m=video 30004 RTP/AVP 32
i=Substitutive video RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:32 MPV/90000
a=mid:2
a=recvonly
6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced
In this example, the substitutive media only applies for video when
Xia Expires July 29, 2016 [Page 13]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
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
a=sendonly
m=video 10002 RTP/AVP 31 32
a=mid:bar
b=AS:1000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=video 20000 RTP/AVP 31 32
i=Substitutive video RTP Stream
c=IN IP4 substitutive.example.com
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=mid:2
a=sendonly
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
Xia Expires July 29, 2016 [Page 14]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
a=group:BUNDLE foo bar
m=audio 30000 RTP/AVP 0
a=mid:foo
b=AS:200
a=rtpmap:0 PCMU/8000
a=recvonly
m=video 30000 RTP/AVP 32
a=mid:bar
b=AS:1000
a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=video 30004 RTP/AVP 32
i=Substitutive video RTP Stream
c=IN IP4 splicer.example.com
a=rtpmap:32 MPV/90000
a=mid:2
a=recvonly
7 Security Considerations
The security considerations of the RTP specification [RFC3550] and
the general mechanism for RTP header extensions [RFC5285] apply. The
splicer MUST either be a mixer or a translator, and has all the
security considerations on these two standard RTP intermediaries.
However, the splicer replaces some content with other content in RTP
packet, thus breaking any RTP-level end-to-end security, such as
source authentication and integrity protection.
End to end source authentication is not possible with any known
existing splicing solution. A new solution can theoretically be
developed that enables identifying the participating entities and
what each provides, i.e., the different media sources, man and
substituting, and the splicer providing the RTP-level integration of
the media payloads in a common timeline and synchronization context.
Since the mechanism introduced in this document is not dependent on
any RTP payload-level hints for finding the splicing in and out
points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used
to provide confidentiality of the RTP payload while leaving the RTP
header in the clear so that the splicer can still carry out splicing
without keying materials. However, for a malicious endpoint without
the key, it can observe the splicing time in the RTP header, and it
can intercept the substitutive content and even replace it with a
different one if the substitutive stream does not use any security
like SRTP and the splicer does not authenticate the main and
substitutive content sources.
Xia Expires July 29, 2016 [Page 15]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
If there is a concern about the confidentiality of the splicing time
information, header extension encryption [RFC6904] SHOULD be used.
However, the malicious endpoint may get the splicing time information
by other means, e.g., inferring from the communication between the
main and substitutive content sources. To avoid the insertion of
invalid substitutive content, the splicer MUST have some mechanisms
to authenticate the substitutive stream source.
For cases that the splicing time information is changed by a
malicious endpoint, the splicing may fail since it will not be
available at the right time for the substitutive media to arrive,
which may also break an undetectable splicing. To mitigate this
effect, the splicer SHOULD NOT forward the splicing time information
RTP header extension defined in Section 4.1 to the receivers. And it
MUST NOT forward this header extension when considering an
undetectable splicing.
8 IANA Considerations
8.1 RTCP Control Packet Types
Based on the guidelines suggested in [RFC5226], a new RTCP packet
format has been registered with the RTCP Control Packet Type (PT)
Registry:
Name: SNM
Long name: Splicing Notification Message
Value: TBA
Reference: This document
8.2 RTP Compact Header Extensions
The IANA has also registered a new RTP Compact Header Extension
[RFC5285], according to the following:
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Description: Splicing Interval
Contact: Jinwei Xia <xiajinwei@huawei.com>
Reference: This document
8.3 SDP Grouping Semantic Extension
Xia Expires July 29, 2016 [Page 16]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
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 Acknowledgement
The authors would like to thank the following individuals who help to
review this document and provide very valuable comments: Colin
Perkins, Bo Burman, Stephen Botzko, Ben Campbell.
10 References
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model
with the Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.
10.2 Informative References
Xia Expires July 29, 2016 [Page 17]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[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
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
"Unicast-Based Rapid Acquisition of Multicast RTP
Sessions", RFC 6285, June 2011.
[RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)", April 2013.
[SCTE35] Society of Cable Telecommunications Engineers (SCTE),
"Digital Program Insertion Cueing Message for Cable",
2011.
[RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828,
January 2013.
Authors' Addresses
Jinwei Xia
Huawei
Email: xiajinwei@huawei.com
Roni Even
Huawei
Email: ron.even.tlv@gmail.com
Rachel Huang
Huawei
Email: rachel.huang@huawei.com
Lingli Deng
Xia Expires July 29, 2016 [Page 18]
INTERNET DRAFT RTP Splicing Notification January 26, 2016
China Mobile
Email: denglingli@chinamobile.com
Xia Expires July 29, 2016 [Page 19]