Duplicating RTP Streams
RFC 7198
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7198 Cisco
Category: Standards Track C. Perkins
ISSN: 2070-1721 University of Glasgow
April 2014
Duplicating RTP Streams
Abstract
Packet loss is undesirable for real-time multimedia sessions but can
occur due to a variety of reasons including unplanned network
outages. In unicast transmissions, recovering from such an outage
can be difficult depending on the outage duration, due to the
potentially large number of missing packets. In multicast
transmissions, recovery is even more challenging as many receivers
could be impacted by the outage. For this challenge, one solution
that does not incur unbounded delay is to duplicate the packets and
send them in separate redundant streams, provided that the underlying
network satisfies certain requirements. This document explains how
Real-time Transport Protocol (RTP) streams can be duplicated without
breaking RTP or RTP Control Protocol (RTCP) rules.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7198.
Begen & Perkins Standards Track [Page 1]
RFC 7198 RTP Duplication April 2014
Copyright Notice
Copyright (c) 2014 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
2. Terminology and Requirements Notation . . . . . . . . . . . . 4
3. Use Cases for Dual Streaming . . . . . . . . . . . . . . . . 4
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 5
3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 7
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 7
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 9
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 9
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 10
7. Congestion Control Considerations . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Begen & Perkins Standards Track [Page 2]
RFC 7198 RTP Duplication April 2014
1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] is widely used today
for delivering IPTV traffic and other real-time multimedia sessions.
Many of these applications support very large numbers of receivers
and rely on intra-domain UDP/IP multicast for efficient distribution
of traffic within the network.
While this combination has proved successful, there does exist a
weakness. As [RFC2354] noted, packet loss is not avoidable. This
loss might be due to congestion; it might also be a result of an
unplanned outage caused by a flapping link, a link or interface
failure, a software bug, or a maintenance person accidentally cutting
Show full document text