RTP Payload for Redundant Audio Data
RFC 2198

Document Type RFC - Proposed Standard (September 1997; No errata)
Updated by RFC 6354
Authors Jean-Chrysostome Bolot  , Mark Handley  , Vicky Hardman  , Isidor Kouvelas  , Colin Perkins 
Last updated 2013-03-02
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2198 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        C. Perkins
Request for Comments: 2198                                  I. Kouvelas
Category: Standards Track                                     O. Hodson
                                                             V. Hardman
                                              University College London
                                                             M. Handley
                                                             J.C. Bolot
                                                         A. Vega-Garcia
                                                       S. Fosse-Parisis
                                                 INRIA Sophia Antipolis
                                                         September 1997

                  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.

1  Introduction

   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 [1].  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.

2  Requirements/Motivation

   The requirements for a redundant encoding scheme under RTP are as

     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                     [Page 2]
Show full document text