Internet DRAFT - draft-xia-avt-splicing-for-rtp

draft-xia-avt-splicing-for-rtp






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]