rfc-3119

A More Loss-Tolerant RTP Payload Format for MP3 Audio

R. Finlayson
date2001-06 streamIETF arearai wgavt statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc3119 doi10.17487/RFC3119 errataview
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. [STANDARDS-TRACK]

obsoleted by

Extracted elements (24)

design-rationale §6

An interleave cycle pattern such as 1,3,5,7,0,2,4,6 (cycle size 8) has the property that any loss of up to four consecutive ADUs in the interleaved stream produces a deinterleaved stream with no gaps greater than one, maximizing audio continuity under burst loss.

rtp, realtime, measurement

design-rationale §5

Interleaving can only be applied to ADU frames (not the original MP3 frames) because the back-pointer structure of MP3 frames makes reordering them across packet boundaries impossible without data loss. This is why interleaving was not feasible under RFC 2250.

rtp, realtime

design-rationale §1

RFC 2250 is suboptimal for MP3 because an MP3 frame is not a true Application Data Unit — it contains a back-pointer (main_data_begin) to data in earlier frames and cannot be decoded independently. Packet boundaries coinciding with frame boundaries thus cause packet loss to render data in adjacent frames useless even when those frames are received intact.

rtp, realtime

design-rationale §6

The ISN is split into an Interleave Cycle Count and Interleave Index (rather than a single 11-bit counter) so that receivers can detect when a complete interleave cycle has passed and release buffered ADU frames to decoding without waiting indefinitely for lost frames. When the receiver sees a frame with a new Interleave Cycle Count, it releases all buffered frames from the prior cycle.

rtp, realtime

interoperability-note §4

Layer I and layer II MPEG audio frames are self-contained (no back-pointer) and are transmitted 'as is' with only an ADU descriptor prepended; only layer III (MP3) frames are converted to ADU frames. Receivers leave layer I/II frames untouched after removing the ADU descriptor, but convert layer III ADU frames back to MP3 frames.

rtp, realtime

interoperability-note §7

The audio/mpa-robust MIME type registered by this document is explicitly incompatible with both the audio/mpa and audio/mpeg MIME types; implementations cannot substitute one for the other.

rtp, realtime

normative-requirement §6 MUST

Each receiving implementation of this payload format MUST recognize the ISN and be able to perform deinterleaving of incoming ADU frames. A sending implementation MAY choose not to perform interleaving, in which case the high-order 11 bits of each MPEG header remain 0xFFE.

rtp, realtime

normative-requirement §3.2 MUST

Receivers MUST be able to accept an ADU descriptor of either 1-byte or 2-byte form.

rtp, realtime

normative-requirement §3.2 MAY

Senders MAY use a 1-byte ADU descriptor (6-bit ADU size) for ADU frames smaller than 64 bytes, but MUST use a 2-byte descriptor for ADU frames of 64 bytes or more.

rtp, realtime

normative-requirement §3.4 SHOULD

Senders SHOULD set the RTP M bit to zero in each outgoing packet, as this payload format defines no use for it.

rtp, realtime

normative-requirement §3.4 MUST NOT

The static payload type 14 defined for MPEG audio MUST NOT be used with this payload format. A dynamic payload type in the range [96, 127] MUST be used instead.

rtp, realtime

normative-requirement §8 REQUIRED

When conveying session information via SDP, the encoding name SHALL be 'mpa-robust' (matching the MIME subtype). Example SDP: 'a=rtpmap:121 mpa-robust/90000'.

rtp, realtime

protocol-element §3.1

An ADU frame consists of: the 4-byte MPEG header (with optional replacement of the high-order 11 bits by an Interleaving Sequence Number), the optional 2-byte CRC field, the side info structure, and the complete encoded audio data for the ADU spanning from main_data_begin of this frame to the start of the next frame's back-pointer.

rtp, realtime

protocol-element §2

An MP3 ADU (Application Data Unit) is defined by the 'side info' structure's main_data_begin field, which is a back-pointer in bytes to the start of the ADU counted from the beginning of the frame, excluding header, CRC, and side info. ADUs vary in length but average the MP3 frame size minus header, CRC, and side info; in MPEG literature this is called the 'bit reservoir'.

rtp, realtime

protocol-element §6

If interleaving is not used by the sender, the high-order 11 bits of each MPEG header remain 0xFFE. Receivers detect this as a sequence of identical ISNs and simply release ADU frames sequentially without reordering, treating each frame as if the Interleave Cycle Count changed with each arrival.

rtp, realtime

protocol-element §3.4

The RTP timestamp is a 32-bit 90 kHz value representing the presentation time of the first ADU packed within the packet. When interleaving is used, outgoing RTP timestamps will not necessarily be monotonically non-decreasing.

rtp, realtime

protocol-element §5

The send-side pipeline is: (1) MP3 frames to ADU frames via main_data_begin extraction, (2) optional interleaving of ADU frames, (3) packetization into RTP packets. The receive-side pipeline reverses these steps: (4) sort by RTP sequence number, (5) depacketize ADU frames using C flag, (6) deinterleave, (7) convert ADU frames back to MP3 frames.

rtp, realtime

protocol-element §A.2

When converting ADU frames back to MP3 frames, dummy ADUs with aduDataSize of zero must be inserted whenever a received ADU's back-pointer would overlap beyond the data of the preceding ADU, a situation that arises when an intermediate ADU was lost due to packet loss.

rtp, realtime

protocol-element §3.3

When multiple ADU frames fit completely within one RTP packet, more than one successive ADU descriptor + ADU frame MAY be packed into a single packet. When a single ADU descriptor + ADU frame exceeds the RTP packet size, the ADU frame is split across successive packets, each carrying its own ADU descriptor with the same total ADU size; only the first packet's descriptor has C=0; subsequent packets have C=1.

rtp, realtime

registry §7

This document registers the MIME media type audio/mpa-robust for MP3 audio transported via RTP as specified in RFC 3119. It has no required or optional parameters, is only for RTP transfer, and is incompatible with audio/mpa and audio/mpeg.

rtp, realtime, registry

security-consideration §9 SHOULD

When a session using this payload format is encrypted and interleaving is used, the sender SHOULD ensure that any encryption key change coincides with the start of a new interleave cycle, to avoid decryption failures caused by a key boundary falling within a cycle. Otherwise, security considerations are identical to those of RFC 2250.

rtp, realtime, security, crypto

state-machine §6

The deinterleaver maintains a 32-entry buffer indexed by Interleave Index. A new interleave cycle is triggered when the incoming Interleave Cycle Count differs from iccLastSeen, or when the current Interleave Index equals iiLastSeen (indicating non-interleaved mode). On cycle transition, all non-NULL buffered ADU frames are released in order to the ADU-to-MP3 conversion step and the buffer is cleared.

rtp, realtime

wire-format §3.2

A 1-byte ADU descriptor encodes a Continuation flag C (1 bit), a Type flag T=0 (1 bit), and ADU size (6 bits, max 63 bytes). A 2-byte ADU descriptor encodes C (1 bit), T=1 (1 bit), and ADU size (14 bits, for frames of 64 bytes or more). The ADU size field gives the size of the following ADU frame in bytes, not including the descriptor itself.

rtp, realtime

wire-format §6

The Interleaving Sequence Number (ISN) reuses the high-order 11 bits of the 4-byte MPEG header (the syncword, normally always 0xFFE), encoding an 8-bit Interleave Index in bits 0–7 and a 3-bit Interleave Cycle Count in bits 8–10. Upon reception the 11 bits are restored to 0xFFE.

rtp, realtime