RFC 2198 (rfc2198) - Page 3 of 11

RTP Payload for Redundant Audio Data

RFC 2198          RTP Payload for Redundant Audio Data    September 1997


     o There is a large overhead from the number of bytes needed for
       the extension header (4) and the possible padding that is needed
       at the end of the extension to round up to a four byte  boundary
       (up to 3 bytes).  For many applications this overhead is
       unacceptable.

     o Use of the header extension limits applications to a single
       redundant encoding, unless further structure is introduced into
       the extension.  This would result in further overhead.

   For these reasons, the use of RTP header extension to hold redundant
   audio encodings is disregarded.

   The RTP profile for audio and video conferences [3] lists a set of
   payload types and provides for a dynamic range of 32 encodings that
   may be defined through a conference control protocol.  This leads to
   two possible schemes for assigning additional RTP payload types for
   redundant audio applications:

     1.A dynamic encoding scheme may be defined, for each combination
       of primary/redundant payload types, using the RTP dynamic payload
       type range.

     2.A single fixed payload type may be defined to represent a packet
       with redundancy.  This may then be assigned to either a static
       RTP payload type, or the payload type for this may be assigned
       dynamically.

   It is possible to define a set of payload types that signify a
   particular combination of primary and secondary encodings for each of
   the 32 dynamic payload types provided.  This would be a slightly
   restrictive yet feasible solution for packets with a single block of
   redundancy as the number of possible combinations is not too large.
   However the need for multiple blocks of redundancy greatly increases
   the number of encoding combinations and makes this solution not
   viable.

   A modified version of the above solution could be to decide prior to
   the beginning of a conference on a set a 32 encoding combinations
   that will be used for the duration of the conference.  All tools in
   the conference can be initialized with this working set of encoding
   combinations.  Communication of the working set could be made through
   the use of an external, out of band, mechanism.  Setup is complicated
   as great care needs to be taken in starting tools with identical
   parameters.  This scheme is more efficient as only one byte is used
   to identify combinations of encodings.





Perkins, et. al.            Standards Track