RFC 2198 (rfc2198) - Page 3 of 11
RTP Payload for Redundant Audio Data
Alternative Format: Original Text Document
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