RTP Payload Format for Generic Forward Error Correction
RFC 5109

 
Document Type RFC - Proposed Standard (December 2007; Errata)
Obsoletes RFC 3009, RFC 2733
Last updated 2013-03-02
Replaces draft-li-ulp
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5109 (Proposed Standard)
Telechat date
Responsible AD Cullen Jennings
Send notices to csp@csperkins.org, magnus.westerlund@ericsson.com, adamli@hyervision.com
Network Working Group                                         A. Li, Ed.
Request for Comments: 5109                                 December 2007
Obsoletes: 2733, 3009
Category: Standards Track

        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.

Abstract

   This document specifies a payload format for generic Forward Error
   Correction (FEC) for media data encapsulated in RTP.  It is based on
   the exclusive-or (parity) operation.  The payload format described in
   this document allows end systems to apply protection using various
   protection lengths and levels, in addition to using various
   protection group sizes to adapt to different media and channel
   characteristics.  It enables complete recovery of the protected
   packets or partial recovery of the critical parts of the payload
   depending on the packet loss situation.  This scheme is completely
   compatible with non-FEC-capable hosts, so the receivers in a
   multicast group that do not implement FEC can still work by simply
   ignoring the protection data.  This specification obsoletes RFC 2733
   and RFC 3009.  The FEC specified in this document is not backward
   compatible with RFC 2733 and RFC 3009.

Li                          Standards Track                     [Page 1]
RFC 5109           RTP Payload Format for Generic FEC      December 2007

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................5
   3. Basic Operation .................................................6
   4. Parity Codes ....................................................7
   5. Uneven Level Protection (ULP) ...................................7
   6. RTP Media Packet Structure ......................................9
   7. FEC Packet Structure ............................................9
      7.1. Packet Structure ...........................................9
      7.2. RTP Header for FEC Packets ................................10
      7.3. FEC Header for FEC Packets ................................11
      7.4. FEC Level Header for FEC Packets ..........................12
   8. Protection Operation ...........................................15
      8.1. Generation of the FEC Header ..............................15
      8.2. Generation of the FEC Payload .............................16
   9. Recovery Procedures ............................................16
      9.1. Reconstruction of the RTP Header ..........................16
      9.2. Reconstruction of the RTP Payload .........................18
   10. Examples ......................................................19
      10.1. An Example Offers Similar Protection as RFC 2733 .........19
      10.2. An Example with Two Protection Levels ....................21
      10.3. An Example with FEC as Redundant Coding ..................26
   11. Security Considerations .......................................29
   12. Congestion Considerations .....................................30
   13. IANA Considerations ...........................................31
      13.1. Registration of audio/ulpfec .............................31
      13.2. Registration of video/ulpfec .............................32
      13.3. Registration of text/ulpfec ..............................34
      13.4. Registration of application/ulpfec .......................35
   14. Multiplexing of FEC ...........................................36
      14.1. FEC as a Separate Stream .................................36
      14.2. FEC as Redundant Encoding ................................38
      14.3. Offer / Answer Consideration .............................39
   15. Application Statement .........................................40
   16. Acknowledgments ...............................................42
   17. References ....................................................42
      17.1. Normative References .....................................42
      17.2. Informative References ...................................43

1.  Introduction

   The nature of real-time applications implies that they usually have
   more stringent delay requirements than normal data transmissions.  As
   a result, retransmission of the lost packets is generally not a valid
   option for such applications.  In these cases, a better method to
   attempt recovery of information from packet loss is through Forward
   Error Correction (FEC).  FEC is one of the main methods used to
Show full document text