AVTEXT A. Begen
Internet-Draft Cisco
Intended status: Standards Track C. Perkins
Expires: September 22, 2013 University of Glasgow
March 21, 2013
Duplicating RTP Streams
draft-ietf-avtext-rtp-duplication-02
Abstract
Packet loss is undesirable for real-time multimedia sessions, but can
occur due to congestion, or other unplanned network outages. This is
especially true for IP multicast networks, where packet loss patterns
can vary greatly between receivers. One technique that can be used
to recover from packet loss without incurring unbounded delay for all
the receivers is to duplicate the packets and send them in separate
redundant streams. 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 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 September 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
publication of this document. Please review these documents
Begen & Perkins Expires September 22, 2013 [Page 1]
Internet-Draft RTP Duplication March 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Requirements Notation . . . . . . . . . . . . 3
3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 3
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4
3.3. Dual Streaming over a Single Path or Multiple Paths . . . 4
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 5
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 6
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 7
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 7
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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, even in
a carefully managed network. This loss might be due to congestion,
it might also be a result of an unplanned outage caused by a flapping
link, link or interface failure, a software bug, or a maintenance
datatracker.ietf.org