An RTP Payload Format for Generic Forward Error Correction
RFC 2733
Document | Type |
RFC - Proposed Standard
(December 1999; No errata)
Obsoleted by RFC 5109
Was draft-ietf-avt-fec (avt WG)
|
|
---|---|---|---|
Authors | Henning Schulzrinne , Jonathan Rosenberg | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) 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