Internet DRAFT - draft-xia-avtext-splicing-notification
draft-xia-avtext-splicing-notification
AVTEXT Working Group J. Xia
INTERNET-DRAFT R. Even
Intended Status: Standards Track R. Huang
Expires: August 17, 2014 Huawei
L. Deng
China Mobile
February 13, 2014
RTP/RTCP extension for RTP Splicing Notification
draft-xia-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 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 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 August 17, 2014 [Page 1]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
Copyright and License 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
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 Extention . . . . . . . . . . . . . . . . . . . . 5
3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6
4 Reduing Splicing Latency . . . . . . . . . . . . . . . . . . . 7
5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 9
8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 10
9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1 Normative References . . . . . . . . . . . . . . . . . . . 10
10.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Xia Expires August 17, 2014 [Page 2]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
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
MUST 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 mixer to start the splicing. This document
refers to this information as Splicing Interval.
[SCTE35] provides a method that encapsulates the Splicing Interval
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 Interval 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 Interval by including it
in the RTP packets.
Nevertheless, the Splicing Interval 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 Interval to the mixer even though RTCP is inherently
unreliable too.
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].
Most terminology defined in "Content Splicing for RTP Sessions"
[RFC6828] applies to this document except the following one.
Splicing Interval:
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 Expires August 17, 2014 [Page 3]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
2 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 Interval from the main RTP sender before splicing starts.
When a new splicing is forthcoming, the main RTP sender MUST send the
Splicing Interval to the mixer. Usually, the Splicing Interval 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 Interval far enough in
advance. Alternatively, 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 mixer 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 mixer. The Splicing Interval
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
Interval 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, and the
timestamp of the first main RTP packet on the splicing out point.
When the substitutive RTP sender gets the Splicing Interval, 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 Interval. 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
Interval.
Xia Expires August 17, 2014 [Page 4]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
3 Conveying Splicing Interval in RTP/RTCP extensions
This memo defines two backwards compatible RTP extensions to convey
the Splicing Interval to the mixer: an RTP header extension and an
RTCP splicing notification message.
3.1 RTP Header Extention
The RTP header extension mechanism defined in [RFC5285] can be
adapted to carry the Splicing Interval consisting of a couple 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
referred from the top 8 bits of the splicing-in NTP timestamp, under
the consumption that the splicing-out time is after the splicing-in
time, and the splicing interval is less than 2^25 seconds, this order
allows full resolution for splicing-in NTP timestamp while keeping 4
octets alignment.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN NTP timestamp format - Fraction (bit 0-31) |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
Figure 1: Sample hybrid 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
Xia Expires August 17, 2014 [Page 5]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
remain RTP packets unmarked.
After the mixer intercepts the RTP header extension and derives the
Splicing Interval, 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
sent to provide robustness in the case of any splicing-unaware
middlebox that might strip RTP header extensions.
3.2 RTCP Splicing Notification Message
Besides the RTP header extension, the main RTP sender includes the
Splicing Interval in an RTCP splicing notification message.
The RTCP splicing notification message is a new RTCP packet type. 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=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
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
Xia Expires August 17, 2014 [Page 6]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
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]).
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].
4 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
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.
5 Failure Cases
Xia Expires August 17, 2014 [Page 7]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
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 Interval reaches the mixers.
If the mixer does not get the Splicing Interval 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].
6 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 also reuses the Flow Identification (FID) semantics
defined in SDP Grouping Framework [RFC5888] to represent the
relationship between the main RTP stream and the substitutive RTP
stream.
The next example shows how the "group" attribute used with FID
semantics can indicate RTP splicing support on RTP sender.
v=0
o=xia 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example
t=0 0
a=group:FID 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
Xia Expires August 17, 2014 [Page 8]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
a=mid: 1
m= video 30001 RTP/AVP 100
i=Substitutive RTP Stream
c=IN IP4 233.252.0.2/127
a=sendonly
a=mid: 2
Figure 3: Example SDP for a single-channel splicing scenario
The mixer 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 30001. But at
a particular point in time, the mixer only selects one stream and
output the content from the chosen stream to the downstream
receivers.
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
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 IANA Considerations
8.1 RTCP Control Packet Types
Based on the guidelines suggested in [RFC5226], a new RTCP packet
format has been registered with the RTCP Control Packet Type (PT)
Registry:
Xia Expires August 17, 2014 [Page 9]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
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
9 Acknowledges
TBD
10 References
10.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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[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,
Xia Expires August 17, 2014 [Page 10]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
"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.
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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[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.
Authors' Addresses
Jinwei Xia
Huawei
Email: xiajinwei@huawei.com
Xia Expires August 17, 2014 [Page 11]
INTERNET DRAFT RTP Splicing Notification February 13, 2014
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 August 17, 2014 [Page 12]
