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

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    avt mailing list <avt@ietf.org>, 
    avt chair <avt-chairs@tools.ietf.org>
Subject: Protocol Action: 'A More Loss-Tolerant RTP Payload 
         Format for MP3 Audio' to Proposed Standard 

The IESG has approved the following document:

- 'A More Loss-Tolerant RTP Payload Format for MP3 Audio '
   <draft-ietf-avt-rfc3119bis-06.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:

Technical Summary
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. (This document updates (and obsoletes) RFC 3119, correcting
typographical errors in the "SDP usage" section and pseudo-code

Working Group Summary
The working group agrees that the corrections to RFC 3119 are 

Document Quality
There are known implementations of this payload format.

Colin Perkins is the document shepherd.

Note to RFC Editor
Please add the following Appendix to the end of the document:

Appendix C: Changes from RFC 3119

   The primary change from RFC 3119 is to correct the encoding name in
the "SDP usage" section.  The correct encoding name is "mpa-robust". 
Also, the term "media type" replaces "mime type".  Finally, some minor bug
fixes and clarifications were made to the (non-normative) pseudo code in
Appendix A and Appendix B.

Please add the following sentence as a new line at the end of section 9
("SDP usage"):

    Note that the RTP timestamp frequency MUST be 90000.

Please add the following new paragraph to the end of section 4.1 ("ADU

    Note that there is a one-to-one mapping between MP3 frames and ADU
frames. Because MP3 frames are self-describing, with the bitrate (and
sampling frequency) encoded within the 4-byte MPEG header, the same is
true for ADU frames.  Therefore, as with MP3 streams, the bitrate can
change within a stream, and this may be used for congestion control.