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]