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/ |