draft-ietf-avtext-splicing-notification-03.txt   draft-ietf-avtext-splicing-notification-04.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: May 30, 2016 Huawei Expires: July 29, 2016 Huawei
L. Deng L. Deng
China Mobile China Mobile
November 27, 2015 January 26, 2016
RTP/RTCP extension for RTP Splicing Notification RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-03 draft-ietf-avtext-splicing-notification-04
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 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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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. needs to be inside of the specific, pre-designated time slot.
Certain timing information about when to start and end the splicing Certain timing information about when to start and end the splicing
must be first acquired by the splicer in order to start 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. This 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. But in the RTP inside the MPEG2-TS layer in cable TV systems. When transported in
splicing scenario described in [RFC6828], the mixer designed as the RTP, an middle box designed as the splicer to decode the RTP packets
splicer has to decode the RTP packets and search for the Splicing and search for the Splicing Interval inside the payloads is required.
Interval inside the payloads. The need for such processing increases The middle box is either a translator or a mixer as described in
the workload of the mixer and limits the number of RTP sessions the [RFC6828]. The need for such processing increases the workload of the
mixer can support. 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 The document defines an RTP header extension [RFC5285] 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.
Nevertheless, the Splicing Interval conveyed in the RTP header Nevertheless, the Splicing Interval conveyed in the RTP header
extension might not reach the splicer successfully. Any splicing un- extension might not reach the splicer successfully. Any splicing un-
aware middlebox on the path between the RTP sender might strip this aware middlebox on the path between the RTP sender might strip this
RTP header extension. RTP header extension.
To increase robustness against such case, the document also defines a To increase robustness against such case, the document also defines a
complementary RTCP packet type to carry the same Splicing Interval to complementary RTCP packet type to carry the same Splicing Interval to
the splicer. the splicer.
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].
The terminology defined in "Content Splicing for RTP Sessions" In addition, we define following terminologies:
[RFC6828] applies to this document and in addition, we define:
Main RTP sender:
The sender of RTP packets carrying the main RTP stream.
Splicer:
An intermediary node that inserts substitutive content into a main
RTP stream. The splicer sends substitutive content to the RTP
receiver instead of the main content during splicing. It is also
responsible for processing RTCP traffic between the RTP sender and
the RTP receiver.
Splicing-In Point
A virtual point in the RTP stream, suitable for substitutive
content entry, typically in the boundary between two independently
decodable frames.
Splicing-Out Point
A virtual point in the RTP stream, suitable for substitutive
content exit, typically in the boundary between two independently
decodable frames.
Splicing Interval: Splicing Interval:
The NTP timestamps for the Splicing-In point and Splicing-Out The NTP timestamps for the Splicing-In point and Splicing-Out
point per [RFC6828] allowing the splicer to know when to start and point per [RFC6828] allowing the splicer to know when to start and
end the RTP splicing. 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 2 Overview of RTP Splicing Notification
A splicer is designed to handle splicing on the RTP layer at the 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 reserved time slots set by the main RTP sender. This implies that the
splicer must first know the Splicing Interval from the main RTP splicer must first know the Splicing Interval from the main RTP
sender before it can start splicing. The splicer can be a mixer as sender before it can start splicing. The splicer can be a mixer as
described in [RFC6828]. described in [RFC6828].
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 be
skipping to change at page 4, line 33 skipping to change at page 5, line 13
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 splicer. The Splicing transfer the substitutive content to the splicer. The Splicing
Interval could be transmitted from the main RTP sender to the Interval could be transmitted from the main RTP sender to the
substitutive content using some out-of-band mechanisms, for example, substitutive content using some out-of-band mechanisms, for example,
a proprietary mechanism to exchange the Splicing Interval, or the a proprietary mechanism to exchange the Splicing Interval, or the
substitutive sender is implemented together with the main RTP sender substitutive sender is implemented together with the main RTP sender
inside a single device. To ensure the Splicing Interval is valid for inside a single device. To ensure 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 common reference clock depends on the achieve accurate splicing. The requirements for the common reference
codec the media content using. 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 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 timestamps, to indicate when to start and end the splicing to the
splicer: the timestamp of the first substitutive RTP packet at 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 splicing in point, and the timestamp of the first main RTP packet at
the splicing out point. 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 main and the substitutive prepare the substitutive stream. The main and the substitutive
content providers MUST ensure that the RTP timestamp of the first content providers MUST ensure that the RTP timestamp of the first
skipping to change at page 6, line 25 skipping to change at page 7, line 9
After the splicer intercepts the RTP header extension and derives the After the splicer intercepts the RTP header extension and derives the
Splicing Interval, it will generate its own stream and SHOULD 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.
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 the RTP header extension, the main RTP sender includes
the Splicing Interval in an RTCP splicing notification message. the Splicing Interval in an RTCP splicing notification message.
Whether the in-band NTP-format timestamps are included or not, the Whether or not the timestamps are included in the RTP header
main RTP sender MUST send the RTCP splicing notification message to extension, the main RTP sender MUST send the RTCP splicing
provide robustness in case of any splicing-unaware middlebox that notification message. This provide robustness in the case where a
might strip RTP header extensions. middlebox strips 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-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 9, line 16 skipping to change at page 9, line 16
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 message and the other failure case, e.g., the RTP header
extension is stripped on the path. extension is stripped on the path.
Given that there may be a splicing un-aware middlebox 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 between the main RTP sender and the splicer, the main and the
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.
If a mixer works as the splicer [RFC6828] and it follows [RFC3550], The splicer can be implemented to have its own SSRC, and send RTCP
the RTP sender whose content is being passed to a downstream receiver reception reports to the senders of the main and substitutive RTP
will see the reception quality of its stream as received by the mixer streams. This allows the senders to detect problems on the path to
and the reception quality of the processed stream as received by the the splicer. Alternatively, it is possible to implement the splicer
receiver; The RTP sender whose content is not being passed to a such that it has no SSRC, and does not send RTCP reports; this
downstream receiver will only see the reception quality of its stream prevents the senders from being able to monitor the quality to the
as received by the mixer. In such a case, the main RTP sender can path to the splicer.
learn that splicing failed if it still sees the RTCP RR packets sent
from downstream receivers when the splicing starts; In a similar
manner, the substitutive sender can also learn that splicing failed
if it does not receive any RTCP RR packets from downstream receivers
when the splicing starts.
Other cases where senders and receivers are in different RTCP domains If the splicer has an SSRC and sends its own RTCP reports, it can
may require translation of RTCP reports, or additional reporting, if choose not to pass RTCP reports it receives from the receivers to the
the senders want to detect splicing problems. 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 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 in some out of band signaling
to fall back to the payload specific mechanisms it supports, e.g., ways to fall back to the payload specific mechanisms it supports,
MPEG-TS splicing solution defined in [SCTE35], or just abandon the e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon
splicing. 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 "urn:ietf:params:rtp-hdrext:splicing-
interval". interval".
This document extends the standard semantics defined in SDP Grouping This document extends the standard semantics defined in SDP Grouping
Framework [RFC5888] with a new semantic: SPLICE 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
skipping to change at page 15, line 20 skipping to change at page 15, line 26
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 [RFC5285] apply. If the general mechanism for RTP header extensions [RFC5285] apply. The
the RTP splicing mechanism described in [RFC6828] is in use, its splicer MUST either be a mixer or a translator, and has all the
security considerations also apply. 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.
In Secure Real-time Transport Protocol (SRTP)[RFC3711], RTP header End to end source authentication is not possible with any known
extensions are authenticated but not encrypted. For a malicious existing splicing solution. A new solution can theoretically be
endpoint without the key, it can observe the splicing time in the RTP developed that enables identifying the participating entities and
header, and it can intercept the substitutive content and even what each provides, i.e., the different media sources, man and
replace it with a different one if the substitutive stream does not substituting, and the splicer providing the RTP-level integration of
use any security like SRTP and the splicer does not authenticate the the media payloads in a common timeline and synchronization context.
main and substitutive content sources.
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.
If there is a concern about the confidentiality of the splicing time If there is a concern about the confidentiality of the splicing time
information, header extension encryption [RFC6904] SHOULD be used. information, header extension encryption [RFC6904] SHOULD be used.
However, the malicious endpoint may get the splicing time information However, the malicious endpoint may get the splicing time information
by other means, e.g., inferring from the communication between the by other means, e.g., inferring from the communication between the
main and substitutive content sources. To avoid invalid substitutive main and substitutive content sources. To avoid the insertion of
contents are inserted, the splicer MUST have some mechanisms to invalid substitutive content, the splicer MUST have some mechanisms
authenticate the substitutive stream source. to authenticate the substitutive stream source.
For cases that the splicing time information is changed by a For cases that the splicing time information is changed by a
malicious endpoint, the splicing may fail since it will not be malicious endpoint, the splicing may fail since it will not be
available at the right time for the substitutive media to arrive, available at the right time for the substitutive media to arrive,
which may also break an undetectable splicing. To mitigate this which may also break an undetectable splicing. To mitigate this
effect, the splicer SHOULD NOT forward the splicing time information effect, the splicer SHOULD NOT forward the splicing time information
RTP header extension defined in Section 4.1 to the receivers. And it RTP header extension defined in Section 4.1 to the receivers. And it
MUST NOT forward this header extension when considering an MUST NOT forward this header extension when considering an
undetectable splicing. undetectable splicing.
 End of changes. 15 change blocks. 
49 lines changed or deleted 101 lines changed or added

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