--- 1/draft-ietf-avtext-splicing-notification-03.txt 2016-01-26 01:15:04.278393285 -0800 +++ 2/draft-ietf-avtext-splicing-notification-04.txt 2016-01-26 01:15:04.318394289 -0800 @@ -1,21 +1,21 @@ AVTEXT Working Group J. Xia INTERNET-DRAFT R. Even Intended Status: Standards Track R. Huang -Expires: May 30, 2016 Huawei +Expires: July 29, 2016 Huawei L. Deng China Mobile - November 27, 2015 + January 26, 2016 RTP/RTCP extension for RTP Splicing Notification - draft-ietf-avtext-splicing-notification-03 + 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 @@ -39,21 +39,21 @@ 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 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. 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 @@ -90,55 +90,84 @@ 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. But in the RTP - splicing scenario described in [RFC6828], the mixer designed as the - splicer has to decode the RTP packets and search for the Splicing - Interval inside the payloads. The need for such processing increases - the workload of the mixer and limits the number of RTP sessions the - mixer can support. + 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]. - The terminology defined in "Content Splicing for RTP Sessions" - [RFC6828] applies to this document and in addition, we define: + 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 + 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 @@ -153,22 +182,23 @@ The substitutive sender also needs to learn the Splicing Interval 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 common reference clock depends on the - codec the media content using. + 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 @@ -241,24 +271,24 @@ 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. 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 the in-band NTP-format timestamps are included or not, the - main RTP sender MUST send the RTCP splicing notification message to - provide robustness in case of any splicing-unaware middlebox that - might strip RTP header extensions. + 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 | @@ -339,42 +369,50 @@ 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. - If a mixer works as the splicer [RFC6828] and it follows [RFC3550], - the RTP sender whose content is being passed to a downstream receiver - will see the reception quality of its stream as received by the mixer - and the reception quality of the processed stream as received by the - receiver; The RTP sender whose content is not being passed to a - downstream receiver will only see the reception quality of its stream - as received by the mixer. In such a case, the main RTP sender can - 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. + 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. - Other cases where senders and receivers are in different RTCP domains - may require translation of RTCP reports, or additional reporting, if - the senders want to detect splicing problems. + 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 - to fall back to the payload specific mechanisms it supports, e.g., - MPEG-TS splicing solution defined in [SCTE35], or just abandon the - splicing. + 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". 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 @@ -628,39 +668,53 @@ 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. If - the RTP splicing mechanism described in [RFC6828] is in use, its - security considerations also apply. + 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. - In Secure Real-time Transport Protocol (SRTP)[RFC3711], RTP header - extensions are authenticated but not encrypted. 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. + 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. 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 invalid substitutive - contents are inserted, the splicer MUST have some mechanisms to - authenticate the substitutive stream source. + 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.