Browse Prior Art Database

An RTP Payload Format for Generic Forward Error Correction (RFC2733)

IP.com Disclosure Number: IPCOM000003329D
Original Publication Date: 1999-Dec-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 20 page(s) / 49K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Rosenberg: AUTHOR [+2]

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 6% of the total text.

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

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 .......................................