Skip to main content

RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8286.
Authors Jinwei Xia , Roni Even , Rachel Huang , Deng Lingli
Last updated 2015-11-26
Replaces draft-xia-avtext-splicing-notification
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Jonathan Lennox
Shepherd write-up Show Last changed 2015-10-20
IESG IESG state Became RFC 8286 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ben Campbell
Send notices to (None)
draft-ietf-avtext-splicing-notification-03
AVTEXT Working Group                                              J. Xia
INTERNET-DRAFT                                                   R. Even
Intended Status: Standards Track                                R. Huang
Expires: May 30, 2016                                             Huawei
                                                                 L. Deng
                                                            China Mobile
                                                       November 27, 2015

            RTP/RTCP extension for RTP Splicing Notification
               draft-ietf-avtext-splicing-notification-03

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
   related information to the splicer: an RTP header extension that
   conveys the information in-band and an RTCP packet that conveys the
   information out-of-band.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   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

 

Xia                       Expires May 30, 2016                  [Page 1]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

Copyright and License Notice

   Copyright (c) 2015 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
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Overview of RTP Splicing Notification . . . . . . . . . . . . .  4
   3  Conveying Splicing Interval in RTP/RTCP extensions  . . . . . .  5
     3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . .  5
     3.2 RTCP Splicing Notification Message . . . . . . . . . . . . .  6
   4  Reducing Splicing Latency . . . . . . . . . . . . . . . . . . .  7
   5  Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6 SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1 Declarative SDP  . . . . . . . . . . . . . . . . . . . . . .  9
     6.2 Offer/Answer without BUNDLE  . . . . . . . . . . . . . . . .  9
     6.3 Offer/Answer with BUNDLE: All Media are spliced  . . . . . . 10
     6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced  . . 12
   7  Security Considerations . . . . . . . . . . . . . . . . . . . . 13
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
     8.1  RTCP Control Packet Types . . . . . . . . . . . . . . . . . 14
     8.2  RTP Compact Header Extensions . . . . . . . . . . . . . . . 14
     8.3 SDP Grouping Semantic Extension  . . . . . . . . . . . . . . 14
   9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   10  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

 

Xia                       Expires May 30, 2016                  [Page 2]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

1  Introduction

   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.

   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:

   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.

 

Xia                       Expires May 30, 2016                  [Page 3]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

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
   sent more than once to mitigate the possible packet loss. To enable
   the splicer to get the substitutive content before the splicing
   starts, the main RTP sender MUST send the Splicing Interval far
   ahead. For example, the main RTP sender can estimate when to send the
   Splicing Interval based on the round-trip time (RTT) following the
   mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP
   RR to the main sender.

   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.

   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
   substitutive RTP packet that would be presented to the receivers
   corresponds to the same time instant as the former NTP timestamp in
   the Splicing Interval. To enable the splicer to know the first
   substitutive RTP packet it needs to send, the substitutive RTP sender
   MUST send the substitutive RTP packet ahead of the Splicing In point,
   allowing the splicer to find out the timestamp of this first RTP
   packet in the substitutive RTP stream, e.g., using a prior RTCP SR
   message.
 

Xia                       Expires May 30, 2016                  [Page 4]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   When the splicing will end, the main content provider and the
   substitutive content provider MUST ensure the RTP timestamp of the
   first main RTP packet that would be presented on the receivers
   corresponds to the same time instant as the latter NTP timestamp in
   the Splicing Interval.

3  Conveying Splicing Interval in RTP/RTCP extensions

   This memo defines two backwards compatible RTP extensions to convey
   the Splicing Interval to the splicer: an RTP header extension and an
   RTCP splicing notification message.

3.1 RTP Header Extension

   The RTP header extension mechanism defined in [RFC5285] can be
   adapted to carry the Splicing Interval consisting of a pair of NTP-
   format timestamps.

   One variant is defined for this header extension. It carries the 7
   octets splicing-out NTP timestamp (lower 24-bit part of the Seconds
   of a NTP-format timestamp and the 32 bits of the Fraction of a NTP-
   format timestamp as defined in [RFC5905]), followed by the 8 octets
   splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in
   [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are
   inferred from the top 8 bits of the splicing-in NTP timestamp. This
   is unambiguous, under the assumption that the splicing-out time is
   after the splicing-in time, and the splicing interval is less than
   2^25 seconds. If the 7 octets splicing-out NTP timestamp is smaller
   than the lower 7 octets splicing-in NTP timestamp, it implies a wrap
   of the 64-bit splicing-out NTP timestamp which will then be
   calculated by the 7 octets splicing-out NTP timestamp plus
   0x100000000. Otherwise, the top 8 octets of splicing-out NTP
   timestamp is equal to the top 8 octets of splicing-in NTP timestamp. 

   The format is shown in Figures 1.

        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       0xBE    |    0xDE       |           length=4            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
      |   ID  | L=15  | OUT NTP timestamp format - Seconds (bit 8-31) |x
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
      |       OUT NTP timestamp format - Fraction (bit 0-31)          |e
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
      |       IN  NTP timestamp format - Seconds (bit 0-31)           |s
 

Xia                       Expires May 30, 2016                  [Page 5]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
      |       IN  NTP timestamp format - Fraction (bit 0-31)          |o
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n

                    Figure 1: Sample hybrid NTP Encoding Using
                           the One-Byte Header Format

   Since the inclusion of an RTP header extension will reduce the
   efficiency of RTP header compression, it is RECOMMENDED that the main
   sender inserts the RTP header extensions into only a number of RTP
   packets, instead of all the RTP packets, prior to the splicing in.

   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.

   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                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             IN NTP Timestamp (most significant word)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             IN NTP Timestamp (least significant word)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             OUT NTP Timestamp (most significant word)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             OUT NTP Timestamp (least significant word)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: RTCP Splicing Notification Message

 

Xia                       Expires May 30, 2016                  [Page 6]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   The RSI packet includes the following fields:

   Length: 16 bits

      As defined in [RFC3550], the length of the RTCP packet in 32-bit
      words minus one, including the header and any padding.

   SSRC: 32 bits

      The SSRC of the Main RTP Sender.

   Timestamp: 64 bits

      Indicates the wallclock time when this splicing starts and ends.
      The full-resolution NTP timestamp is used, which is a 64-bit,
      unsigned, fixed-point number with the integer part in the first 32
      bits and the fractional part in the last 32 bits.  This format is
      similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550]).

   The RTCP splicing notification message can be appended to RTCP SR the
   main RTP sender generates in compound RTCP packets, and hence follows
   the compound RTCP rules defined in Section 6.1 in [RFC3550].

   If the use of non-compound RTCP [RFC5506] was previously negotiated
   between the sender and the splicer, the RTCP splicing notification
   message may be sent as non-compound RTCP packets.

   When the splicer intercepts the RTCP splicing notification message,
   it SHOULD NOT forward the message to the down-stream receivers in
   order to reduce RTCP bandwidth consumption. And if the splicer wishes
   to prevent the downstream receivers from detecting splicing, it MUST
   NOT forward the message.

4  Reducing Splicing Latency

   When splicing starts or ends, the splicer outputs the multimedia
   content from another sender to the receivers. Given that the
   receivers must first acquire certain information ([RFC6285] refers to
   this information as Reference Information) to start processing the
   multimedia data, either the main RTP sender or the substitutive
   sender SHOULD provide the Reference Information together with its
   multimedia content to reduce the delay caused by acquiring the
   Reference Information. The methods by which the Reference Information
   is distributed to the receivers is out of scope of this memo.

   Another latency element is synchronization caused delay. The
   receivers must receive enough synchronization metadata prior to
 

Xia                       Expires May 30, 2016                  [Page 7]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   synchronizing the separate components of the multimedia streams when
   splicing starts or ends. Either the main RTP sender or the
   substitutive sender SHOULD send the synchronization metadata early
   enough so that the receivers can play out the multimedia in a
   synchronized fashion. The main RTP sender and the substitutive sender
   can be coordinated by some proprietary out-of-band mechanisms to
   decide when and whom to send the metadata. If both send the
   information, the splicer SHOULD pick one based on the current
   situation, e.g., choosing media sender when synchronizing the main
   media content while choosing the information from the substitutive
   sender when synchronizing the spliced content. The mechanisms defined
   in [RFC6051] are RECOMMENDED to be adopted to reduce the possible
   synchronization delay.

 

Xia                       Expires May 30, 2016                  [Page 8]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

5  Failure Cases

   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.

   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.

   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.

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
   stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP
   stream is the one with the extended extmap attribute, and the other
   one is substitutive stream. A single m-line MUST NOT be included in
   different SPLICE groups at the same time. The main RTP sender
 

Xia                       Expires May 30, 2016                  [Page 9]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   provides the information about both main and substitutive sources.

   The extended SDP attribute specified in this document is applicable
   for offer/answer content [RFC3264] and do not affect any rules when
   negotiating offer and answer. When used with multiple m-lines,
   substitutive RTP MUST be applied only to the RTP packets whose SDP m-
   line is in the same group with the substitutive stream using SPLICE
   and has the extended splicing extmap attribute. This semantic is also
   applicable for BUNDLE cases.

   The following examples show how SDP signaling could be used for
   splicing in different cases.

6.1 Declarative SDP

              v=0
              o=xia 1122334455 1122334466 IN IP4 splicing.example.com
              s=RTP Splicing Example
              t=0 0
              a=group:SPLICE 1 2
              m=video 30000 RTP/AVP 100
              i=Main RTP Stream
              c=IN IP4 233.252.0.1/127
              a=rtpmap:100 MP2T/90000
              a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
              a=mid:1
              m=video 30002 RTP/AVP 100
              i=Substitutive RTP Stream
              c=IN IP4 233.252.0.2/127
              a=sendonly
              a=rtpmap:100 MP2T/90000
              a=mid:2

         Figure 3: Example SDP for a single-channel splicing scenario

   The splicer receiving the SDP message above receives one MPEG2-TS
   stream (payload 100) from the main RTP sender (with multicast
   destination address of 233.252.0.1) on port 30000, and/or receives
   another MPEG2-TS stream from the substitutive RTP sender (with
   multicast destination address of 233.252.0.2) on port 30002.  But at
   a particular point in time, the splicer only selects one stream and
   outputs the content from the chosen stream to the downstream
   receivers.

6.2 Offer/Answer without BUNDLE

   SDP Offer - from main RTP sender

 

Xia                       Expires May 30, 2016                 [Page 10]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

            v=0
            o=xia 1122334455 1122334466 IN IP4 splicing.example.com
            s=RTP Splicing Example
            t=0 0
            a=group:SPLICE 1 2
            m=video 30000 RTP/AVP 31 100
            i=Main RTP Stream
            c=IN IP4 splicing.example.com
            a=rtpmap:31 H261/90000
            a=rtpmap:100 MP2T/90000
            a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
            a=sendonly
            a=mid:1
            m=video 40000 RTP/AVP 31 100
            i=Substitutive RTP Stream
            c=IN IP4 substitutive.example.com
            a=rtpmap:31 H261/90000
            a=rtpmap:100 MP2T/90000
            a=sendonly
            a=mid:2

   SDP Answer - from splicer

            v=0
            o=xia 1122334455 1122334466 IN IP4 splicer.example.com
            s=RTP Splicing Example
            t=0 0
            a=group:SPLICE 1 2
            m=video 30000 RTP/AVP 100
            i=Main RTP Stream
            c=IN IP4 splicer.example.com
            a=rtpmap:100 MP2T/90000
            a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
            a=recvonly
            a=mid:1
            m=video 40000 RTP/AVP 100
            i=Substitutive RTP Stream
            c=IN IP4 splicer.example.com
            a=rtpmap:100 MP2T/90000
            a=recvonly
            a=mid:2

   Only codecs that are supported both by the main RTP stream and the
   substitutive RTP stream could be negotiated with SDP O/A. And the
   splicer MUST choose the same codec for both of these two streams.

6.3 Offer/Answer with BUNDLE: All Media are spliced
 

Xia                       Expires May 30, 2016                 [Page 11]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   In this example, the bundled audio and video media have their own
   substitutive media for splicing:

   1.  An Offer, in which the offerer assigns a unique address and a
   substitutive media to each bundled "m="line for splicing within the
   BUNDLE group.

   2.  An answer, in which the answerer selects its own BUNDLE address,
   and leave the substitutive media untouched.

   SDP Offer - from main RTP sender

          v=0
          o=alice 1122334455 1122334466 IN IP4 splicing.example.com
          s=RTP Splicing Example
          c=IN IP4 splicing.example.com
          t=0 0
          a=group:SPLICE foo 1
          a=group:SPLICE bar 2
          a=group:BUNDLE foo bar
          m=audio 10000 RTP/AVP 0 8 97
          a=mid:foo
          b=AS:200
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
          a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
          a=sendonly
          m=video 10002 RTP/AVP 31 32
          a=mid:bar
          b=AS:1000
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000
          a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
          a=sendonly
          m=audio 20000 RTP/AVP 0 8 97
          i=Substitutive audio RTP Stream
          c=IN IP4 substitive.example.com
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
          a=sendonly
          a=mid:1
          m=video 20002 RTP/AVP 31 32
          i=Substitutive video RTP Stream
          c=IN IP4 substitive.example.com
          a=rtpmap:31 H261/90000
 

Xia                       Expires May 30, 2016                 [Page 12]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

          a=rtpmap:32 MPV/90000
          a=mid:2
          a=sendonly

   SDP Answer - from the splicer

          v=0
          o=bob 2808844564 2808844564 IN IP4 splicer.example.com
          s=RTP Splicing Example
          c=IN IP4 splicer.example.com
          t=0 0
          a=group:SPLICE foo 1
          a=group:SPLICE bar 2
          a=group:BUNDLE foo bar
          m=audio 30000 RTP/AVP 0
          a=mid:foo
          b=AS:200
          a=rtpmap:0 PCMU/8000
          a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
          a=recvonly
          m=video 30000 RTP/AVP 32
          a=mid:bar
          b=AS:1000
          a=rtpmap:32 MPV/90000
          a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
          a=recvonly
          m=audio 30002 RTP/AVP 0
          i=Substitutive audio RTP Stream
          c=IN IP4 splicer.example.com
          a=rtpmap:0 PCMU/8000
          a=recvonly
          a=mid:1
          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

6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced

   In this example, the substitutive media only applies for video when
   splicing:

   1. An Offer, in which the offerer assigns a unique address to each
   bundled "m="line within the BUNDLE group, and assigns a substitutive
   media to the bundled video "m=" line for splicing.

 

Xia                       Expires May 30, 2016                 [Page 13]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   2. An answer, in which the answerer selects its own BUNDLE address,
   and leave the substitutive media untouched.

   SDP Offer - from the main RTP sender:

          v=0
          o=alice 1122334455 1122334466 IN IP4 splicing.example.com
          s=RTP Splicing Example
          c=IN IP4 splicing.example.com
          t=0 0
          a=group:SPLICE bar 2
          a=group:BUNDLE foo bar
          m=audio 10000 RTP/AVP 0 8 97
          a=mid:foo
          b=AS:200
          a=rtpmap:0 PCMU/8000
          a=rtpmap:8 PCMA/8000
          a=rtpmap:97 iLBC/8000
          a=sendonly
          m=video 10002 RTP/AVP 31 32
          a=mid:bar
          b=AS:1000
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000
          a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
          a=sendonly
          m=video 20000 RTP/AVP 31 32
          i=Substitutive video RTP Stream
          c=IN IP4 substitutive.example.com
          a=rtpmap:31 H261/90000
          a=rtpmap:32 MPV/90000
          a=mid:2
          a=sendonly

   SDP Answer - from the splicer:

          v=0
          o=bob 2808844564 2808844564 IN IP4 splicer.example.com
          s=RTP Splicing Example
          c=IN IP4 splicer.example.com
          t=0 0
          a=group:SPLICE bar 2
          a=group:BUNDLE foo bar
          m=audio 30000 RTP/AVP 0
          a=mid:foo
          b=AS:200
          a=rtpmap:0 PCMU/8000
          a=recvonly
 

Xia                       Expires May 30, 2016                 [Page 14]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

          m=video 30000 RTP/AVP 32
          a=mid:bar
          b=AS:1000
          a=rtpmap:32 MPV/90000
          a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
          a=recvonly
          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.

   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. 

   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.

   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.

8  IANA Considerations

8.1  RTCP Control Packet Types
 

Xia                       Expires May 30, 2016                 [Page 15]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   Based on the guidelines suggested in [RFC5226], a new RTCP packet
   format has been registered with the RTCP Control Packet Type (PT)
   Registry:

         Name: SNM

         Long name: Splicing Notification Message

         Value: TBA

         Reference: This document

8.2  RTP Compact Header Extensions

   The IANA has also registered a new RTP Compact Header Extension
   [RFC5285], according to the following:

         Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval

         Description: Splicing Interval

         Contact: Jinwei Xia <xiajinwei@huawei.com>

         Reference: This document

8.3 SDP Grouping Semantic Extension

   This document request IANA to register the new SDP grouping semantic
   extension called "SPLICE".

         Semantics: Splice

         Token:SPLICE

         Reference: This document

         Contact: Jinwei Xia <xiajinwei@huawei.com>

9 Acknowledgement

   The authors would like to thank the following individuals who help to
   review this document and provide very valuable comments: Colin
   Perkins, Bo Burman, Stephen Botzko, Ben Campbell. 

10  References

10.1  Normative References
 

Xia                       Expires May 30, 2016                 [Page 16]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   [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.

   [RFC3264]  Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model
              with the Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, July 2008.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
              Flows", RFC 6051, November 2010.

10.2  Informative References

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, April 2009.

   [RFC6285]  Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
              "Unicast-Based Rapid Acquisition of Multicast RTP
              Sessions", RFC 6285, June 2011.

   [RFC6904]  Lennox, J.,"Encryption of Header Extensions in the Secure
              Real-Time Transport Protocol (SRTP)", April 2013.

   [SCTE35]   Society of Cable Telecommunications Engineers (SCTE),
              "Digital Program Insertion Cueing Message for Cable",
              2011.
 

Xia                       Expires May 30, 2016                 [Page 17]
INTERNET DRAFT         RTP Splicing Notification       November 27, 2015

   [RFC6828]  Xia, J., "Content Splicing for RTP Sessions", RFC 6828,
              January 2013.

Authors' Addresses

   Jinwei Xia
   Huawei

   Email: xiajinwei@huawei.com

   Roni Even
   Huawei

   Email: ron.even.tlv@gmail.com

   Rachel Huang
   Huawei

   Email: rachel.huang@huawei.com

   Lingli Deng
   China Mobile

   Email: denglingli@chinamobile.com

Xia                       Expires May 30, 2016                 [Page 18]