RFC 2198 (rfc2198) - Page 2 of 11

RTP Payload for Redundant Audio Data

RFC 2198          RTP Payload for Redundant Audio Data    September 1997


   of consecutively lost packets is small.  Recent work [4,5] shows that
   packet loss patterns in the Internet are such that this scheme
   typically functions well.

   This document describes an RTP payload format for the transmission of
   audio data encoded in such a redundant fashion.  Section 2 presents
   the requirements and motivation leading to the definition of this
   payload format, and does not form part of the payload format
   definition.  Sections 3 onwards define the RTP payload format for
   redundant audio data.

2  Requirements/Motivation

   The requirements for a redundant encoding scheme under RTP are as
   follows:

     o Packets have to carry a primary encoding and one or more
       redundant encodings.

     o As a multitude of encodings may be used for redundant
       information, each block of redundant encoding has to have an
       encoding type identifier.

     o As the use of variable size encodings is desirable, each encoded
       block in the packet has to have a length indicator.

     o The RTP header provides a timestamp field that corresponds to
       the time of creation of the encoded data.  When redundant
       encodings are used this timestamp field can refer to the time of
       creation of the primary encoding data.  Redundant blocks of data
       will correspond to different time intervals than the primary
       data, and hence each block of redundant encoding will require its
       own timestamp.  To reduce the number of bytes needed to carry the
       timestamp, it can be encoded as the difference of the timestamp
       for the redundant encoding and the timestamp of the primary.

   There are two essential means by which redundant audio may be added
   to the standard RTP specification:  a header extension may hold the
   redundancy, or one, or more, additional payload types may be defined.

   Including all the redundancy information for a packet in a header
   extension would make it easy for applications that do not implement
   redundancy to discard it and just process the primary encoding data.
   There are, however, a number of disadvantages with this scheme:







Perkins, et. al.            Standards Track