%% You should probably cite draft-ietf-avt-rfc3119bis instead of this I-D. @techreport{finlayson-rtp-mp3-00, number = {draft-finlayson-rtp-mp3-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-finlayson-rtp-mp3/00/}, author = {Dr. Ross Finlayson}, title = {{A More Loss-Tolerant RTP Payload Format for MP3 Audio}}, pagetotal = 2, year = 1999, month = feb, day = 24, abstract = {While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable 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 a new RTP payload format for MP3 audio. The new format is essentially the same as that defined in RFC 2250, except for a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 'Application Data Units'. This new format is therefore more data efficient in the face of packet loss.}, }