An RTP Payload Format for Generic Forward Error Correction
RFC 2733

Document Type RFC - Proposed Standard (December 1999; No errata)
Obsoleted by RFC 5109
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2733 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       J. Rosenberg
Request for Comments: 2733                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                           December 1999

       An RTP Payload Format for Generic Forward Error Correction

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document specifies a payload format for generic forward error
   correction of media encapsulated in RTP. It is engineered for FEC
   algorithms based on the exclusive-or (parity) operation. The payload
   format allows end systems to transmit using arbitrary block lengths
   and parity schemes. It also allows for the recovery of both the
   payload and critical RTP header fields. Since FEC is sent as a
   separate stream, it is backwards compatible with non-FEC capable
   hosts, so that receivers which do not wish to implement FEC can just
   ignore the extensions.

Table of Contents

   1     Introduction ...........................................    2
   2     Terminology ............................................    2
   3     Basic Operation ........................................    3
   4     Parity Codes ...........................................    5
   5     RTP Media Packet Structure .............................    6
   6     FEC Packet Structure ...................................    7
   6.1   RTP Header of FEC Packets ..............................    7
   6.2   FEC Header .............................................    7
   7     Protection Operation ...................................    9
   8     Recovery Procedures ....................................   10
   8.1   Reconstruction .........................................   10
   8.2   Determination of When to Recover .......................   12

Rosenberg & Schulzrinne     Standards Track                     [Page 1]
RFC 2733                      Generic FEC                  December 1999

   9     Example ................................................   16
   10    Use with Redundant Encodings ...........................   17
   11    Indicating FEC Usage in SDP ............................   20
   11.1  FEC as a Separate Stream ...............................   20
   11.2  Use with Redundant Encodings ...........................   21
   11.3  Usage with RTSP ........................................   22
   12    Security Considerations ................................   23
   13    Acknowledgments ........................................   24
   14    Authors' Addresses .....................................   24
   15    Bibliography ...........................................   25
   16    Full Copyright Statement ...............................   26

1 Introduction

   The quality of packet voice on the Internet has been mediocre due, in
   part, to high packet loss rates. This is especially true on wide-area
   connections. Unfortunately, the strict delay requirements of real-
   time multimedia usually eliminate the possibility of retransmissions.

   It is for this reason that forward error correction (FEC) has been
   proposed to compensate for packet loss in the Internet [1] [2]. In
   particular, the use of traditional error correcting codes, such as
   parity, Reed-Solomon, and Hamming codes, has attracted attention. To
   support these mechanisms, protocol support is required.

   This document defines a payload format for RTP [3] which allows for
   generic forward error correction of real time media. In this context,
   generic means that the FEC protocol is (1) independent of the nature
   of the media being protected, be it audio, video, or otherwise, (2)
   flexible enough to support a wide variety of FEC mechanisms, (3)
   designed for adaptivity so that the FEC technique can be modified
   easily without out of band signaling, and (4) supportive of a number
   of different mechanisms for transporting the FEC packets.

2 Terminology

   The following terms are used throughout this document:

       Media Payload: is a piece of raw, un-protected user data which
            is to be transmitted from the sender. The media payload is
            placed inside of an RTP packet.

       Media Header: is the RTP header for the packet containing the
            media payload.

       Media Packet: The combination of a media payload and media
            header is called a media packet.

Rosenberg & Schulzrinne     Standards Track                     [Page 2]
Show full document text