Network Working Group C. Perkins
Request for Comments: 2198 I. Kouvelas
Category: Standards Track O. Hodson
University College London
INRIA Sophia Antipolis
RTP Payload for Redundant Audio Data
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.
This document describes a payload format for use with the real-time
transport protocol (RTP), version 2, for encoding redundant audio
data. The primary motivation for the scheme described herein is the
development of audio conferencing tools for use with lossy packet
networks such as the Internet Mbone, although this scheme is not
limited to such applications.
If multimedia conferencing is to become widely used by the Internet
Mbone community, users must perceive the quality to be sufficiently
good for most applications. We have identified a number of problems
which impair the quality of conferences, the most significant of
which is packet loss. This is a persistent problem, particularly
given the increasing popularity, and therefore increasing load, of
the Internet. The disruption of speech intelligibility even at low
loss rates which is currently experienced may convince a whole
generation of users that multimedia conferencing over the Internet is
not viable. The addition of redundancy to the data stream is offered
as a solution . If a packet is lost then the missing information
may be reconstructed at the receiver from the redundant data that
arrives in the following packet(s), provided that the average number
Perkins, et. al. Standards Track [Page 1]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.
The requirements for a redundant encoding scheme under RTP are as
o Packets have to carry a primary encoding and one or more
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: