Skip to main content

RTP/RTCP extension for RTP Splicing Notification
draft-xia-avtext-splicing-notification-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Jinwei Xia , Rachel Huang
Last updated 2013-02-18
Replaced by draft-ietf-avtext-splicing-notification, RFC 8286
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-xia-avtext-splicing-notification-00
AVTEXT Working Group                                              J. Xia
Internet-Draft                                                 R. Huang
Intended status: Standards Track                                  Huawei
Expires: August 22, 2013                               February 18, 2013

            RTP/RTCP extension for RTP Splicing Notification
               draft-xia-avtext-splicing-notification-00

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 RTP mixer is designed to handle RTP splicing in [RFC6828],
   but how the RTP mixer knows when to start and end the splicing is
   still unspecified.

   This memo defines two RTP/RTCP extensions to indicate the splicing
   related information to the RTP mixer: 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 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 August 22, 2013.

Copyright Notice

   Copyright (c) 2013 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

Xia & Huang              Expires August 22, 2013                [Page 1]
Internet-Draft            Splicing Notification            February 2013

   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
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of RTP Splicing Notification  . . . . . . . . . . . .  4
   4.  Conveying Splicing Metadata in RTP/RTCP extensions . . . . . .  5
     4.1.  RTP Header Extention . . . . . . . . . . . . . . . . . . .  5
     4.2.  RTCP Splicing Notification Message . . . . . . . . . . . .  6
   5.  Reduing Splicing Latency . . . . . . . . . . . . . . . . . . .  7
   6.  Failure Cases  . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Xia & Huang              Expires August 22, 2013                [Page 2]
Internet-Draft            Splicing Notification            February 2013

1.  Introduction

   Splicing is a process that replaces some multimedia content with
   other multimedia content and delivers the substitutive multimedia
   content to the receivers during specific, pre-designated time slot.
   Certain timing information about when to start and end the splicing
   must be first acquired by the splicer to start the splicing.  This
   document refers to this information as Splicing Metadata.

   [SCTE35] provides a method that encapsulates the Splicing Metadata
   inside the MPEG2-TS layer in cable TV systems.  But in RTP splicing
   scenario described in [RFC6828], the mixer has to decode the RTP
   packets, search and solve the Splicing Metadata inside the payloads.
   The need for such processing enhances the workload of the mixer and
   limits the size of RTP sessions the mixer can support.

   The document defines an RTP header extension [RFC5285] through which
   the main RTP sender can provide the Splicing Metadata by including it
   in the RTP packets.

   Nevertheless, the Splicing Metadata conveyed in the RTP header
   extension might not reach the mixer successfully, any splicing un-
   aware middlebox on the path between the RTP sender and the mixer
   might strip the RTP header extension.

   To increase robustness against above case, the document also defines
   a new RTCP packet type in a complementary fashion to carry the
   Splicing Metadata to the mixer even though RTCP is inherently
   unreliable too.

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

   Most terminology defined in "Content Splicing for RTP Sessions"
   [RFC6828] applies to this document except the following one:

   Splicing Metadata

      A set of certain metadata that allows the mixer to know when to
      start and end the RTP splicing.  The information consists of a
      couple of NTP-format timestamps on the splicing in point and on
      the splicing out point.

Xia & Huang              Expires August 22, 2013                [Page 3]
Internet-Draft            Splicing Notification            February 2013

3.  Overview of RTP Splicing Notification

   According to RTP Splicing draft [RFC6828], a mixer is designed to do
   splicing on the RTP layer, but it cannot insert the substitutive
   content randomly but only do that at the reserved time slots set by
   the main RTP sender.  This implies the mixer must first know the
   Splicing Metadata from the main RTP sender before splicing starts.

   When a new splicing is forthcoming, the main RTP sender MUST send the
   Splicing Metadata to the mixer.  Usually, the Splicing Metadata
   SHOULD be sent more than once to against the possible packet loss.
   To enable the mixer to get the substitutive content before the
   splicing starts, the main RTP sender MUST send the Splicing Metadata
   far enough in advance.  Alternatively, the main RTP sender can
   estimate when to send the Splicing Metadata based on the round-trip
   time (RTT) following the mechanisms in section 6.4.1 of [RFC3550]
   when the mixer sends RTCP RR to the main sender.

   The substitutive sender also needs to learn the Splicing Metadata
   from the main RTP sender in advance, and thus estimates when to
   transfer the substitutive content to the mixer.  The Splicing
   Metadata could be transmitted from the main RTP sender to the
   substitutive content using some out-of-band mechanisms, the details
   how to achieve that are beyond the scope of this memo.  To ensure the
   Splicing Metadata is valid to the main RTP sender and the
   substitutive RTP sender, the two senders MUST share a common
   reference clock, so the mixer can achieve accurate splicing.

   In this document, the main RTP sender uses a couple of NTP-format
   timestamps, derived from the common reference clock, to indicate when
   to start and end the splicing to the mixer: the timestamp of the
   first substitutive RTP packet on the splicing in point, followed by
   the timestamp of the first main RTP packet on the splicing out point.

   When the substitutive RTP sender gets the Splicing Metadata, it must
   prepare the substitutive stream.  The RTP timestamp of the first
   substitutive RTP packet that would be presented on the receivers MUST
   correspond to the same time instant as the former NTP timestamp in
   the Splicing Metadata.  To enable mixer to know the first
   substitutive RTP packet it begins to output, the substitutive RTP
   sender MUST enable the mixer to know above RTP timestamp in advance,
   e.g., from prior receipt of RTCP SR message.

   When the splicing will end, the RTP timestamp of the first main RTP
   packet that would be presented on the receivers MUST correspond to
   the same time instant as the latter NTP timestamp in the Splicing
   Metadata.

Xia & Huang              Expires August 22, 2013                [Page 4]
Internet-Draft            Splicing Notification            February 2013

4.  Conveying Splicing Metadata in RTP/RTCP extensions

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

4.1.  RTP Header Extention

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

   One variant is defined for this header extension.  The variant
   carries the 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].  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=6   |   NTP timestamp format - Seconds (bit 8-31)   |x
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
      |           NTP timestamp format - Fraction (bit 0-31)          |e
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
      |   ID  | L=6   |   NTP timestamp format - Seconds (bit 8-31)   |s
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
      |           NTP timestamp format - Fraction (bit 0-31)          |o
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n

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

   Note that the inclusion of an RTP header extension will reduce the
   efficiency of RTP header compression.  It is RECOMMENDED that the
   main sender begins to insert the RTP header extensions into a number
   of RTP packets in advance of the splicing starting, while leaving the
   remain RTP packets unmarked.

   After the mixer intercepts the RTP header extension and derives the
   Splicing Metadata, it will generate its own stream and could not
   include the RTP header extension in outgoing packets to reduce header
   overhead.

   Furthermore, whether the in-band NTP-format timestamps are included
   or not, RTCP splicing notification message in next section MUST be

Xia & Huang              Expires August 22, 2013                [Page 5]
Internet-Draft            Splicing Notification            February 2013

   sent to provide robustness in the case of any splicing-unaware
   middlebox that might strip RTP header extensions.

   When SDP is used, the use of the RTP header extensions defined above
   MUST be indicated as specified in [RFC5285].  Therefore, the
   following URI MUST be used:

   o  The URI used for signalling the use of Variant B/56-bit NTP RTP
      header extension in SDP is "urn:ietf:params:rtp-hdrext: splicing-
      metadata-56".

4.2.  RTCP Splicing Notification Message

   Besides the RTP header extension, the main RTP sender includes the
   Splicing Metadata in an RTCP splicing notification message.

   The RTCP splicing notification message is a new RTCP packet type
   defined with PT = 211.  It has a fix header followed by a couple 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=211   |              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

   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.

Xia & Huang              Expires August 22, 2013                [Page 6]
Internet-Draft            Splicing Notification            February 2013

   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 RTCP Sender Report (Section 6.4.1 of [RFC3550]).

   A basic assumption is that the main RTP sender and the mixers are in
   an SSM group with the source being the main RTP sender.  RTCP
   splicing notification message from the main RTP sender is sent via
   multicast to the mixers.

   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 mixer, the RTCP splicing notification
   message may be sent as non-compound RTCP packets.

   When the mixer intercepts the RTCP splicing notification message, it
   MAY NOT forward the message to the receivers in order to reduce RTCP
   bandwidth consumption or to avoid downstream receivers from detecting
   splicing defined in Section 4.5 in [RFC6828].

5.  Reduing Splicing Latency

   When splicing starts or ends, the mixer 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 align with its
   multimedia content to reduce the delay caused by acquiring the
   Reference Information.  The means 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
   synchronizing the separate components of the multimedia streams when
   splicing starts or ends.  Either the main RTP sender or the

Xia & Huang              Expires August 22, 2013                [Page 7]
Internet-Draft            Splicing Notification            February 2013

   substitutive sender SHOULD send the synchronization metadata early
   enough so that the receivers can play out the multimedia in a
   synchronized fashion.  The mechanisms defined in [RFC6051] are
   RECOMMENDED to be adopted to reduce the possible synchronization
   delay.

6.  Failure Cases

   This section examines the implications of losing RTCP splicing
   notification message and other failure case, e.g., the RTP header
   extension is stripped on the path.

   Given there may be splicing un-aware middlebox on the path between
   the main RTP sender and the mixer, one heuristics will be used to
   verify whether or not the Splicing Metadata reaches the mixers.

   If the mixer does not get the Splicing Metadata when the splicing
   starts, it will still output the main content to the downstream
   receivers and forward the RTCP RR packets sent from downstream
   receivers to the main RTP sender.  In such case, the main RTP sender
   can learn the splicing failed.

   In a similar manner, the substitutive sender can learn the splicing
   failed if it does not receive any RTCP RR packets from downstream
   receivers when the splicing starts.

   Upon the detection of a failure, the main RTP sender or the
   substitutive sender SHOULD check the path to the failed mixer, or
   fallback to the payload specific mechanisms, e.g., MPEG-TS splicing
   solution defined in [SCTE35].

7.  Security Considerations

   The security considerations of the RTP specification [RFC3550], the
   general mechanism for RTP header extensions [RFC5285] and the
   security considerations of the RTP splicing specification [RFC6828]
   apply.

   The RTP header extension defined in Section 4.1 include two NTP-
   format timestamps.  In the Secure Real-time Transport Protocol
   (SRTP)[RFC3711], RTP header extensions are authenticated but not
   encrypted.  A malicious endpoint could choose to set the values in
   this header extension falsely, so as to falsely claim the splicing
   time.

   In scenarios where this is a concern, additional mechanisms MUST be

Xia & Huang              Expires August 22, 2013                [Page 8]
Internet-Draft            Splicing Notification            February 2013

   used to protect the confidentiality of the header extension.  This
   mechanism could be header extension encryption [SRTP-ENCR-HDR], or a
   lower-level security and authentication mechanism such as IPsec
   [RFC4301].

8.  SDP Signaling

   TBD

9.  IANA considerations

   TBD

10.  Acknowledgments

   TBD

11.  References

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

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

   [RFC5905]  Mills, D., Martin, J., 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.

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

Xia & Huang              Expires August 22, 2013                [Page 9]
Internet-Draft            Splicing Notification            February 2013

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

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

   [SRTP-ENCR-HDR]
              Lennox, J., "Encryption of Header Extensions in the Secure
              Real-Time Transport Protocol (SRTP)",
              draft-ietf-avtcore-srtp-encrypted-header-ext-04 (work in
              progress), January 2013.

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

Authors' Addresses

   Jinwei Xia
   Huawei
   101 Software Avenue
   Nanjing, Yuhua District  210012
   China

   Phone: +86-025-84565890
   Email: xiajinwei@huawei.com

Xia & Huang              Expires August 22, 2013               [Page 10]
Internet-Draft            Splicing Notification            February 2013

   Rachel Huang
   Huawei
   101 Software Avenue
   Nanjing, Yuhua District  210012
   China

   Phone: +86-025-84565890
   Email: rachel.huang@huawei.com

Xia & Huang              Expires August 22, 2013               [Page 11]