Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio
Extracted elements (27)
Concatenation of E-AC-3 frames in RTP packets is constrained so that program sets and frame sets are kept intact within a single packet. This minimizes the impact of packet loss: losing one packet does not render the contents of another packet unusable.
The bitStreamConfig SDP parameter serves two purposes: enabling pre-session negotiation to avoid sending data a receiver cannot use, and making bit stream structure explicit so a receiver can identify which frames were lost for error mitigation.
E-AC-3 content is not directly compatible with AC-3 decoders but can be converted to AC-3 format with low loss and low computational cost, enabling compatibility with existing broadcast and A/V decoding infrastructure.
Since an AC-3 bit stream is a special case of an E-AC-3 bit stream, carriage of AC-3 frames in the E-AC-3 RTP payload format is permitted, but only for the independent substream of the first (or only) program.
A receiver capable of receiving the E-AC-3 payload format defined in this document MUST also receive the payload format for AC-3 defined in RFC 4184.
A sender that desires to send an AC-3 bit stream in the E-AC-3 payload format SHOULD also offer the session in the AC-3 payload format by including payload types for both 'ac3' and 'eac3'.
Each RTP payload MUST start with the two-byte payload specific header followed by an integral number of complete E-AC-3 frames, or a single fragment of an E-AC-3 frame.
Frames from more than one program set SHOULD NOT be included in the same RTP packet unless all program sets in the packet are complete; similarly for frame sets.
If an E-AC-3 frame exceeds the MTU for a network, it SHOULD be fragmented for transmission within an RTP packet.
In SDP offer/answer, the 'rate' parameter is symmetric and the answer MUST use the same value as the offer, or the answerer removes the payload type.
Packets containing fragments of the same E-AC-3 frame MUST have the same RTP timestamp value.
RTP packets containing fragments of the same E-AC-3 frame SHALL be sent in consecutive order, from first to last fragment, to enable correct reassembly.
The configuration of the E-AC-3 bit stream MUST match the value of the bitStreamConfig SDP parameter for the duration of the session.
The MBZ bits in the payload header SHALL be set to zero by senders and SHALL be ignored by receivers; they are reserved for future extensions.
The NF field MUST be identical for all packets containing fragments of the same E-AC-3 frame, indicating the total number of fragments that make up that frame.
The RTP timestamp of the first packet sent SHOULD be selected at random; thereafter it increases linearly according to the number of samples in each frame (256 samples per block).
To maintain interoperability with AC-3-capable endpoints, an E-AC-3 endpoint SHOULD declare itself also as AC-3 capable (supporting 'audio/ac3' per RFC 4184) when negotiation is possible.
A 'frame set' groups frames carrying six consecutive audio blocks across all programs and substreams; the first frame of each frame set is identified by the Converter Synchronization flag (convsync=1) in the BSI field.
E-AC-3 bit streams support up to eight programs; each program contains one mandatory independent substream (up to 5.1 channels, AC-3 compatible) and up to eight optional dependent substreams for extended channel configurations.
The BSI field carries 'frmsiz' (frame size in 16-bit words minus one), 'fscod' (sampling rate), 'numblkscod' (number of blocks: 1, 2, 3, or 6), and stream type/substream identity fields ('strmtyp' and 'substreamid').
The E-AC-3 frame structure consists of a Sync Information (SI) field, Bit Stream Information (BSI) field, Audio Frame (AF) field, up to six Audio Blocks (AB), an optional auxiliary data field (AUX), and a CRC field. Each AB represents 256 PCM samples per channel.
The E-AC-3 RTP Marker (M) bit is set to one to indicate the payload contains at least one complete E-AC-3 frame or the final fragment of a frame.
The optional SDP parameter 'bitStreamConfig' encodes the program/substream arrangement as a string of type characters ('i' for independent, 'd' for dependent) each followed by the number of audio channels (e.g., 'i6d8d14i6d8').
IANA registered a new media subtype 'audio/eac3' with required parameter 'rate' (32000, 44100, or 48000 Hz) and optional parameter 'bitStreamConfig'. This registration is defined in Section 5.1 of RFC 4598.
Confidentiality, integrity protection, and authentication are not provided by this payload format; they must be provided by an external mechanism such as SRTP (RFC 3711). The format is designed so malformed frames can be detected and discarded by decoders, which conceal errors in audio output until a valid frame is found, preventing crashes from malformed or malicious data.
The E-AC-3 RTP payload header is two octets: a 6-bit MBZ field, a 1-bit Frame Type (F) field indicating complete frames (0) or fragment (1), and an 8-bit Number of Frames/Fragments (NF) field.
The E-AC-3 synchronization word is 0x0B77, occupying the first two octets of every frame, used for frame detection and codec synchronization.