A More Loss-Tolerant RTP Payload Format for MP3 Audio (RFC3119)
Original Publication Date: 2001-Jun-01
Included in the Prior Art Database: 2005-May-18
Internet Society Requests For Comment (RFCs)
This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss.
Network Working Group R.
Request for Comments: 3119 LIVE.COM
Category: Standards Track June 2001
A More Loss-Tolerant RTP Payload Format for MP3 Audio
Status of this Memo
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.
Copyright (C) The Internet Society (2001). All Rights Reserved.
describes a RTP (Real-Time Protocol) payload format for
transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III
audio (commonly known as "MP3"). This format is an alternative to
that described in RFC 2250, and performs better if there is packet
While the RTP
payload format defined in RFC 2250  is generally
applicable to all forms of MPEG audio or video, it is sub-optimal for
MPEG 1 or 2, layer III audio (commonly known as "MP3"). The reason
for this is that an MP3 frame is not a true "Application Data Unit" -
it contains a back-pointer to data in earlier frames, and so cannot
be decoded independently of these earlier frames. Because RFC 2250
defines that packet boundaries coincide with frame boundaries, it
handles packet loss inefficiently when carrying MP3 data. The loss
of an MP3 frame will render some data in previous (or future) frames
useless, even if they are received without loss.
In this document
we define an alternative RTP payload format for MP3
audio. This format uses a data-preserving rearrangement of the
original MPEG frames, so that packet boundaries now coincide with
true MP3 "Application Data Units", which can also (optionally) be
rearranged in an interleaving pattern. This new format is therefore
more data-efficient than RFC 2250 in the face of packet loss.
Finlayson Standards Track [Page 1]
RFC 3119 Loss-Tolerant RTP Payload Format for MP3 Audio June 2001
2. The Structure of MP3 Frames
In this section
we give a brief overview of the structure of a MP3
frame. (For more detailed description, see the MPEG 1 audio  and
MPEG 2 audio  specifications.)
Each MPEG audio
frame begins with a 4-byte header.
defined by this header includes:
- Whether the audio is MPEG 1 or MPEG 2.
- Whether the audio is layer I, II, or III.
(The remainder of this d...