AVT Working Group J. Xia Internet-Draft Huawei Intended status: Informational October 16, 2010 Expires: April 19, 2011 Content Splicing for RTP Sessions draft-xia-avt-splicing-for-rtp-00 Abstract This memo outlines RTP splicing. Splicing is a process that allows a new multimedia stream to be inserted into current multimedia stream and to be conveyed to receiver for a period of time. This memo discusses the requirements of RTP splicing. In order to satisfy the requirements, this memo lists several existing intermediary network elements as alternatives and evaluates whether one of alternatives can be used to perform RTP splicing. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 19, 2011. Copyright Notice Copyright (c) 2010 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 Xia Expires April 19, 2011 [Page 1] Internet-Draft seamless splicing October 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTP Splicing Topologies . . . . . . . . . . . . . . . . . . . 4 4. List of Alternatives for RTP Splicing . . . . . . . . . . . . 7 4.1. Translator . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Mixer . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. MCU . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Recommended Solution for RTP Splicing . . . . . . . . . . . . 8 6. RTCP Sender Report Extensions . . . . . . . . . . . . . . . . 10 7. Implementation considerations . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Xia Expires April 19, 2011 [Page 2] Internet-Draft seamless splicing October 2010 1. Introduction Splicing is a process that allows a new multimedia stream to be inserted into current multimedia stream and to be conveyed to receiver for a period of time. Splicing can be used for audio or video RTP streams. One representative use case of using splicing is targeted advertisements (ads) insertion, which allows operators to override current program flow inserting its own targeted ads. So far [SCTE30] and [SCTE35] have standardized splicing for MPEG2-TS application, but to date there is no specification how to perform content splicing for RTP sessions [RFC3550]. In this document, we describe the topology of RTP splicing, and bring up the requirements of RTP splicing. Then we list several existing intermediary network elements as alternatives to handle RTP splicing and evaluate whether one of them can be off-the-shelf to satisfy the requirements on the aspect of feasibility, implementation complexity and backward compatibility. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Primary RTP Stream A RTP stream RTP receiver is currently enjoying. A primary RTP stream is replaced by insertion RTP stream in part. Insertion RTP Stream A RTP stream overrides primary RTP stream in part. Insertion RTP stream is output to RTP receiver for a period of time. Splicer An intermediary node that inserts insertion RTP stream into primary RTP stream. Splicer sends insertion RTP stream to RTP receiver at the start of splicing, then switch back to primary RTP stream at the end of splicing. Xia Expires April 19, 2011 [Page 3] Internet-Draft seamless splicing October 2010 3. RTP Splicing Topologies In this document, we assume an intermediary network element, which is referred to as Splicer, receives primary RTP stream and insertion RTP stream(s), and outputs only one of these streams to RTP receiver at a point in time. The switch between the primary RTP stream and the insertion RTP stream(s) may be repeated during the RTP session. The RTP receiver receives only one stream at any point of time. The splicing topology is depicted in Figure 1. The Splicer receives the primary RTP stream from media sender A and the insertion RTP stream from media sender C. Then Splicer selects one single RTP stream, either from A or from C, and outputs it to RTP receiver B and D over unicast or multicast paths. The criteria for stream selection are based on the policy from media sender A. How the policy is calculated is out of scope and not be discussed herein. The policy can be contained in extended RTCP SR sent from media source. Once Splicer receives RTCP SR packet, Splicer will learn how to splicing from the policy information, then strip the policy part from SR packet prior to forwarding the SR packet to RTP receiver. The specific RTCP SR extension are described in section 6. +---+ | C | +---+ | | v +------------+ +---+ | |---->| B | +---+ | | +---+ | A |----->| Splicer | +---+ | | +---+ | |---->| D | +------------+ +---+ Figure 1: Splicing Topology There may be more than one insertion RTP streams from different insertion sources. However, in order to facilitate the splicing process, we depict the simplest splicing stream flows scenario with only one insertion RTP stream in Figure 2. Xia Expires April 19, 2011 [Page 4] Internet-Draft seamless splicing October 2010 +---------+ +------+ +---------++----------+ | Media | | Ads | | || RTP | | Source | |Source| | Splicer || Receiver | | | | | | || | +---------+ +------+ +---------++----------+ | | | | | | | | | | | | |-----------|--------------->|-------->| | | | | | | Splicing begin | | | | | | |***************>|********>| | | | | |-----------|--------------->| | | | | | | | | | | | Splicing end | | | | | |-----------|--------------->|-------->| | | | | | |***************>| | | | | | | | | | ---------> Primary RTP Stream *********> Insertion RTP Stream Figure 2: Splicing Stream Flows 1. When splicing begins, Splicer ceases forwarding primary RTP stream, and instead sends the insertion RTP stream to RTP receiver. 2. At the end of splicing, Splicer resumes the primary RTP stream and outputs the primary RTP packets to RTP receiver until next insertion RTP stream comes. In order to guarantee a seamless splicing on RTP receiver, Splicer must carefully handle the joint of primary RTP stream and insertion RTP stream. In particular, Splicer needs to consider following requirements of RTP Splicing: Xia Expires April 19, 2011 [Page 5] Internet-Draft seamless splicing October 2010 REQ-1: Splicer must be designed to operate in either unicast or multicast environment. REQ-2: Splicer may receives multiple input streams, but must not synchronize or mix them into a single output stream. Instead, Splicer should select one of the multiple input streams and output it at any specific time. REQ-3: To prevent the RTP receiver from easily identifying the inserted stream, the Splicer should merge the inserted stream into the primary RTP stream so that it will not be identified based on RTP header information like payload type number, sequence number and SSRC. This requires the Splicer to modify the RTP header of the inserted RTP stream. The Splicer may need to do media transcoding in most cases. REQ-4: Splicer must be designed to guarantee RTP sequence number continuity in the case of switching from the primary RTP stream to the insertion RTP stream, and vice versa. Otherwise, a gap between the primary RTP stream and the insertion RTP stream may cause the RTP receiver to request retransmission for nonexistent packet loss while an overlap of the primary RTP stream and the insertion RTP stream may cause the RTP receiver to discard useful RTP packets due to the duplicate sequence numbers. REQ-5: Splicer must be backward compatible with basic characteristics of [RFC3550], e.g., SSRC identifier collision resolution and loop detection. REQ-6: Since the Splicer does RTP media transcoding on the inserted stream in most cases, Splicer should not simply forward RTCP traffic unaltered during the splicing. Xia Expires April 19, 2011 [Page 6] Internet-Draft seamless splicing October 2010 4. List of Alternatives for RTP Splicing The basic RTP specification [RFC3550] explicitly supports the concept of Translator and Mixer, which are intermediary network elements that are involved in media transport functions. In addition, ITU-T audio- visual conferencing specification [H.323] defines the MCU (Multipoint Control Unit), which is also an intermediary network element that is used in video conference scenario. In order to clarify the terms of Translator, Mixer and MCU, RTP topologies specification [RFC5117] specifically enumerates the different topologies and discusses the properties of each topology. In this section, three alternatives (i.e., Translator, Mixer and MCU) based on [RFC5117] topologies would be evaluated. The following subsections will analyze which alternative can appropriately satisfy the requirements of Splicer. 4.1. Translator Transport Translator (Topo-Trn-Translator) does not modify the media stream itself, but are concerned with transport parameters. Transport Translator forwards RTP packets with their RTP header information intact and simply forwards RTCP packets unmodified as well. Transport Translator does not satisfy the REQ-3, 4 and 6. Media Translator (Topo-Media-Translator), in contrast, modifies the media stream itself. The modification of the media stream can be a full transcoding utilizing a different media codec, thus change the media format and timestamp. In most cases, Media Translator needs only to assign new sequence numbers to the outgoing RTP packets to guarantee the RTP sequence number continuity. Just like Transport Translator, Media Translator always keeps the SSRC identifier intact for any RTP stream across the translator. Meanwhile, Media Translator cannot directly forward RTCP packets corresponding to the transcoded stream, and will need to insert itself into the RTCP flow, acting as a proxy for the RTP receiver. Media Translator seems to dissatisfy REQ-3 (i.e., SSRC inconsistent). 4.2. Mixer Mixer (Topo-Mixer) aggregates multiple RTP streams, mixing them together to generate a new RTP stream. From media sender viewpoint, Mixer plays receiver role and terminates RTP streams sent from media Xia Expires April 19, 2011 [Page 7] Internet-Draft seamless splicing October 2010 sender. While from RTP receiver viewpoint, Mixer plays media sender role and transmits the mixed RTP stream to RTP receiver with Mixer's own SSRC identifier. To facilitate loop detection, Mixer inserts a list of SSRC identifiers of the multiple input RTP streams into the CSRC identifiers field of the new output RTP stream. Mixer is responsible for generating RTCP packets in accordance with its role. It is a RTP receiver and should therefore send Receiver Reports for the media streams it receives. In its role as a media sender, it should also generate Sender Reports for those media streams sent. More details are described in section 7.3 of [RFC3550]. Mixer does not satisfy the REQ-2. 4.3. MCU Video Switching MCU (Topo-Video-switch-MCU) forwards to RTP receiver a single RTP stream, selected from the multiple input RTP streams at a time. The forwarded stream changes during the session. Video Switching MCU may also perform media translation to modify the content in bit-rate, encoding, and timestamp. However, it still may indicate the original sender of the content through the SSRC. Video Switching MCU only forwards RTCP Sender Reports for the currently selected media sender. Other RTCP processing behaviors are similar with Media Translator's. Video Switching MCU does not satisfy the REQ-4 and REQ-3 (i.e., SSRC inconsistent). RTCP-Terminating MCU (Topo-RTCP-terminating-MCU) limits each sender and receiver runs an RTP point-to-point session between itself and RTCP-Terminating MCU. The main feature of RTCP-Terminating MCU is that the SSRC identifiers of the media senders, whose content is included in the Mixer's output, is not indicated in CSRC identifiers list fields of the output RTP stream. RTCP-Terminating MCU terminates RTCP traffic due to point-to-point topology. RTCP-Terminating MCU does not satisfy the REQ-1 and 5. 5. Recommended Solution for RTP Splicing From the analysis of section 4, it seems that none of the alternatives perfectly satisfies the requirements of Splicer. Xia Expires April 19, 2011 [Page 8] Internet-Draft seamless splicing October 2010 However, the topology of Media Translator describes a common translator for primary RTP stream and insertion RTP stream in section 4.1. In fact, an off-the-shelf Media Translator, which only translates primary RTP stream while terminating insertion RTP stream, can well satisfy all the requirements of Splicer. Media Translator terminates the insertion RTP stream whose SSRC does not affect the translator since the insertion RTP stream is a separate stream to the primary RTP stream. When splicing begins, Media Translator transcodes inserted media codec into primary media codec and uses primary media source SSRC identifier in transcoded RTP stream to prevent the RTP receiver from easily identifying the inserted stream. Media Translator also assigns new sequence numbers to the inserted RTP packets. Note that the new sequence numbers of inserted RTP packets must seamlessly follow the sequence of the previous primary RTP packets before splicing. When splicing ends, Media Translator switches back to primary RTP stream. During the splicing, the number of inserted RTP packets is unlikely to equal the number of overridden primary RTP packets because of media transcoding and different entropy coding. This requires Media Translator to modify the sequence numbers of subsequent primary RTP packets rather than directly forwarding them to RTP receiver. Note that the new sequence numbers of subsequent primary RTP packets must seamlessly follow the sequence of the last inserted RTP packet. In this mode, RTP receiver does not need any RTP/RTCP extension for splicing, so there are not any serious backward compatibility issues. In contrast, it places the burden of performing splicing on Splicer. In the event that no insertion RTP stream is coming, the Splicer still decodes and re-encodes the primary RTP stream, recalculates the UDP/IP checksum and originates RR or SR messages in accordance with its role. In such case, overhead could be induced on Splicer compared to just forwarding the primary RTP stream to RTP receiver. If Splicer serves multiple primary RTP streams simultaneously, this may lead to worse overhead on Splicer. Because insertion RTP stream is terminated on Media Translator, this requires Media Translator to generate its own RTCP Receiver Reports for the insertion RTP stream. For the primary RTCP messages, Media Translator needs to interpose itself into RTCP SR, obtaining splicing information from RTCP SR extension and stripping the extension prior to forwarding the SR to RTP receiver. Xia Expires April 19, 2011 [Page 9] Internet-Draft seamless splicing October 2010 [TBD: How to modify RTCP RR on translator is unsolved] When receiving retransmission request for packet loss recovery during splicing, Media Translator first determines the range of lost packets requested by RTP receiver. If the sequence numbers of lost packets are in the range of inserted stream, Media Translator must initiate retransmission request messages on behalf of the RTP receiver toward corresponding retransmission server; Otherwise, Media Translator needs to modify the sequence numbers of the re-encoded primary lost packets prior to forwarding retransmission request to corresponding retransmission server. 6. RTCP Sender Report Extensions [TBD] 7. Implementation considerations When using Media Translator to handle RTP splicing, RTP receiver does not need any RTP/RTCP extension for splicing, so there are not any serious backward compatibility issues. In contrast, it places the burden of performing splicing on Media Translator. In the event that no insertion RTP stream is coming, the Media Translator still needs to decode and re-encode the primary RTP packets, to recalculate the UDP/IP checksum and originate RTCP messages. As a trade-off, overhead could be induced on Media Translator compared to just forwarding the primary RTP stream to RTP receiver. If Media Translator serves multiple primary RTP streams simultaneously, this may lead to worse overhead on Media Translator. 8. Security Considerations The introduction of Media Translator must not diminish the level of security provided in current RTP/RTCP model. Since Media Translator alters the RTP payload, thus preventing the use of end-to-end encryption and source authentication, the Media Translator must be designed as a trusted device to take part in security context, e.g., support SRTP/SRTCP defined in [RFC3711] specification. If encryption is employed, the Media Translator needs to decrypt the inbound media, as well as re-encrypt the outbound media. This requires Media Translator to set up different security associations with media senders and RTP receivers respectively. Xia Expires April 19, 2011 [Page 10] Internet-Draft seamless splicing October 2010 9. IANA Considerations [TBD] 10. Acknowledgments [TBD] 11. 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. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. [SCTE30] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Splicing API", 2001. [SCTE35] Society of Cable Telecommunications Engineers (SCTE), "Digital Program Insertion Cueing Message for Cable", 2004. [H.323] ITU-T Recommendation H.323, "Packet-based multimedia communications systems", June 2006. Xia Expires April 19, 2011 [Page 11] Internet-Draft seamless splicing October 2010 Author's Address Jinwei Xia Huawei Hui Hong Mansion Nanjing, Baixia District 210001 China Phone: +86-025-86622310 Email: xiajinwei@huawei.com Xia Expires April 19, 2011 [Page 12]