A More Loss-Tolerant RTP Payload Format for MP3 Audio
RFC 5219

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                       R. Finlayson
Request for Comments: 5219                           Live Networks, Inc.
Obsoletes: 3119                                            February 2008
Category: Standard Track

         A More Loss-Tolerant RTP Payload Format for MP3 Audio

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.

Abstract

   This document describes an 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.  This document obsoletes RFC 3119, correcting typographical
   errors in the "SDP usage" section and pseudo-code appendices.

Finlayson                   Standards Track                     [Page 1]
RFC 5219                                                   February 2008

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. The Structure of MP3 Frames .....................................3
   4. A New Payload Format ............................................4
      4.1. ADU Frames .................................................4
      4.2. ADU Descriptors ............................................4
      4.3. Packing Rules ..............................................5
      4.4. RTP Header Fields ..........................................6
      4.5. Handling Received Data .....................................6
   5. Handling Multiple MPEG Audio Layers .............................6
   6. Frame Packetizing and Depacketizing .............................7
   7. ADU Frame Interleaving ..........................................8
   8. IANA Considerations ............................................10
   9. SDP Usage ......................................................11
   10. Security Considerations .......................................11
   11. Acknowledgements ..............................................11
   12. Normative References ..........................................12
   Appendix A. Translating between "MP3 Frames" and "ADU Frames" .....13
      A.1. Converting a Sequence of "MP3 Frames"
           to a Sequence of "ADU Frames" .............................14
      A.2. Converting a Sequence of "ADU Frames"
           to a Sequence of "MP3 Frames" .............................15
   Appendix B. Interleaving and Deinterleaving .......................18
      B.1. Interleaving a Sequence of "ADU Frames" ...................18
      B.2. Deinterleaving a Sequence of (Interleaved) "ADU Frames" ...19
   Appendix C. Changes from RFC 3119 .................................20

1.  Introduction

   While the RTP payload format defined in RFC 2250 [1] 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 2]
RFC 5219                                                   February 2008

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

3.  The Structure of MP3 Frames

   In this section we give a brief overview of the structure of an MP3
   frame.  (For a more detailed description, see the MPEG-1 audio [3]
   and MPEG-2 audio [4] specifications.)

   Each MPEG audio frame begins with a 4-byte header.  Information
   defined by this header includes:

   -  Whether the audio is MPEG-1 or MPEG-2.