A More Loss-Tolerant RTP Payload Format for MP3 Audio
obsoletes
- rfc-3119 — A More Loss-Tolerant RTP Payload Format for MP3 Audio
Extracted elements (20)
Interleaving is applied to ADU frames rather than MP3 frames because MP3 frames' back-pointers make them order-dependent; converting to ADUs first eliminates this dependency, enabling interleaving that was not possible with the RFC 2250 format.
MP3 frames contain a back-pointer ('main_data_begin') to data in earlier frames, meaning they are not true Application Data Units and cannot be decoded independently. RFC 2250's approach of aligning packet boundaries with frame boundaries therefore handles packet loss inefficiently, as loss of one frame can render data in adjacent frames useless.
The ISN is split into an Interleave Cycle Count and an Interleave Index (rather than a single 11-bit counter) to allow receivers to know when to release buffered ADU frames to the decoder. When a frame with a new Cycle Count arrives, all buffered frames from the previous cycle can be released even if some are still missing due to packet loss.
Only layer III (MP3) frames are converted to ADU frames; layer I and II frames, which are self-contained without back-pointers, are sent as-is with only an ADU descriptor prepended. Receivers leave layer I/II frames untouched after removing the descriptor.
The 'audio/mpa-robust' media type is incompatible with both the 'audio/mpa' and 'audio/mpeg' media types defined for RFC 2250. Implementations cannot mix this payload format with those defined in RFC 2250 on the same payload type.
When a receiver sees a sequence of identical ISNs (all 0xFFE, indicating no interleaving was used by the sender), it handles them as if the Interleave Cycle Count changed with each ADU frame, releasing ADU frames sequentially without reordering.
Each receiving implementation 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 remain at 0xFFE.
For ADU frame sizes of 64 bytes or more, senders MUST use a 2-byte ADU descriptor; for smaller sizes, senders MAY use a 1-byte ADU descriptor. Receivers MUST be able to accept an ADU descriptor of either size.
Senders SHOULD set the RTP M bit to zero in each outgoing packet, as this payload format defines no use for the M bit.
The static RTP payload type 14 defined for MPEG audio in RFC 3551 MUST NOT be used with this payload format. A dynamic payload type in the range [96..127] MUST be used instead.
When conveying session information via SDP, the encoding name SHALL be 'mpa-robust' and the RTP timestamp frequency MUST be 90000 Hz.
An ADU frame consists of the 4-byte MPEG header (with high-order 11 bits optionally replaced by an Interleaving Sequence Number), an optional 2-byte CRC, the 'side info' structure, and the complete encoded audio data for the ADU spanning from the current frame's main_data_begin back-pointer to the next frame's back-pointer.
The Continuation (C) flag in the ADU descriptor signals whether the following data is a continuation of an ADU frame split across multiple RTP packets. When splitting occurs, all packets for the same ADU carry the same total ADU size value in their descriptors, and each packet after the first has C=1.
The MP3 'side info' structure length varies by MPEG version and channel mode: 32 bytes for MPEG-1 stereo, 17 bytes for MPEG-1 mono or MPEG-2 stereo, and 9 bytes for MPEG-2 mono. The 'main_data_begin' field within this structure is the back-pointer (in bytes) to the start of the ADU.
The RTP timestamp field 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.
This document registers the 'audio/mpa-robust' media type with IANA. Required parameters: none. Optional parameters: none. The type is defined only for transfer via RTP as specified in RFC 5219.
When a session using this payload format is encrypted and interleaving is in use, the sender SHOULD ensure that any change of encryption key coincides with the start of a new interleave cycle. Otherwise, security considerations are identical to those in RFC 2250.
Frame packetizing proceeds through three steps: (1) MP3 frames → ADU frames via back-pointer resolution, (2) ADU frames → interleaved ADU frames (optional reordering), (3) interleaved ADU frames → RTP packets. Depacketizing reverses this: sort by RTP sequence number, depacketize, deinterleave, then convert ADU frames back to MP3 frames.
A 1-byte ADU descriptor encodes a 1-bit Continuation flag (C), a 1-bit Descriptor Type flag (T=0), and a 6-bit ADU size field. A 2-byte ADU descriptor encodes C, T=1, and a 14-bit ADU size field; the 2-byte form is used for ADU frames of 64 bytes or more.
The Interleaving Sequence Number (ISN) reuses the high-order 11 bits of the 4-byte MPEG header syncword (normally 0xFFE). Bits 0-7 encode an 8-bit Interleave Index and bits 8-10 encode a 3-bit Interleave Cycle Count. Upon reception, these 11 bits are replaced with 0xFFE.