A More Loss-Tolerant RTP Payload Format for MP3 Audio
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, avt mailing list <email@example.com>, avt chair <firstname.lastname@example.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: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3119bis-06.txt
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 appendices.) Working Group Summary The working group agrees that the corrections to RFC 3119 are needed. Document Quality There are known implementations of this payload format. Personnel 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 frames"): 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.