RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec
Extracted elements (29)
A 72000 Hz RTP timestamp clock rate was mandated so that every AMR-WB+ ISF yields an integer number of timestamp ticks per transport frame (960 to 2880 ticks), avoiding fractional-tick arithmetic and providing good conversion ratios to all supported output sampling frequencies.
Multi-channel transport via separate RTP codec instances (as in RFC 3267 for AMR-WB) is omitted because AMR-WB+ natively encodes stereo within a single codec instance, including built-in stereo-to-mono downmixing in the decoder.
Only octet-aligned mode is specified; no bandwidth-efficient mode is defined. Because all AMR-WB+ extension frame types are natively octet-aligned and the primary use case is streaming servers, the bandwidth savings of a bandwidth-efficient mode would be negligible.
The interleaving scheme allows any non-periodic pattern with a displacement distance up to 256 frames (up to 3.41 seconds at the highest ISF), in contrast to RFC 3267's AMR-WB format which only supports fixed periodic patterns. This flexibility accommodates streaming scenarios with widely varying jitter.
An AMR-WB+ endpoint SHOULD also declare 'audio/AMR-WB' capability (per RFC 3267) during SDP negotiation when it supports both, because AMR-WB is a proper subset of AMR-WB+. The AMR-WB+ decoder can receive both stereo and mono frame types regardless of its playout capabilities, since stereo-to-mono downmixing is internal.
Decoding can only start at a super-frame boundary, and it is only RECOMMENDED to start if at least 2 out of 4 transport frames belonging to that super-frame are available. This affects receivers joining a multicast mid-session or re-synchronizing after access-control key changes.
A payload type where channels=1 (mono) SHALL only carry mono content; a payload type with channels=2 MAY carry both mono and stereo. When the 'interleaving' parameter is absent, interleaved mode SHALL NOT be used.
A receiver MUST be prepared to receive any audio frame multiple times because the format allows overlapping packet time periods for redundancy. All redundantly sent frames MUST use the same frame type and ISF and MUST carry the same RTP timestamp, or MUST be a NO_DATA frame (FT=15).
An application implementing this payload format MUST understand all the payload parameters; any mapping of the parameters to a signaling protocol MUST support all parameters.
Both basic mode and interleaved mode SHALL be implemented by any conforming application. The implementation burden of both is small, and requiring both ensures interoperability.
If the receiver finds a mismatch between the size of a received payload and the size indicated by the ToC, the receiver SHOULD discard the packet, because decoding a frame parsed from erroneous ToC data could severely degrade audio quality.
The last octet of each audio frame MUST be padded with zeroes if not all bits in the octet are used; each audio frame MUST be octet-aligned. The ISF field in the payload header SHALL be set to 0 for payloads containing only frames with Frame Type values 0–13.
The RTP header marker bit (M) SHALL be set to 1 whenever the first frame carried in the packet is the first frame in a talkspurt; for all other packets M SHALL be set to 0.
The RTP timestamp clock frequency SHALL be 72000 Hz. This value was chosen so that each ISF's transport frame duration maps to an integer number of timestamp ticks (960 to 2880 ticks depending on ISF).
To maintain interoperability with AMR-WB-capable endpoints, an AMR-WB+ endpoint that also implements RFC 3267 SHOULD declare itself capable of AMR-WB (i.e., also advertising 'audio/AMR-WB'). It is also RECOMMENDED to implement RFC 3267 when implementing this specification.
ToC entries with #frames equal to 0 SHALL NOT be used, and a received packet containing such a ToC entry SHALL be discarded. Similarly, a packet containing a ToC entry with an undefined FT value SHALL be discarded entirely to prevent loss of depacketization synchronization.
When multiple groups of frames are present, ToC entries SHALL be placed in order of increasing RTP timestamp value (modulo 2^32) of the first transport frame the entry represents, independent of payload mode.
AMR-WB+-specific redundancy coding aggregates previously transmitted transport frames together with new ones using a sliding window, allowing a sender to retransmit frames in subsequent packets without session-setup signaling. The receiver identifies duplicates via RTP timestamp matching.
In interleaved mode, RTP timestamp for each frame is derived from the RTP header timestamp plus the sum of (DISi+1)*frame_duration for all preceding frames. The frame duration is determined solely by the ISF value as specified in Table 1. The first frame's DIS1 is ignored; its timestamp equals the RTP header timestamp.
ISF changes combined with packet loss can cause concealment with the wrong frame length, leading to frame boundary misalignment. Section 4.5.1 specifies an algorithm to recover timestamps of lost frames by enumerating plausible ISF transition points using TFI modular arithmetic, falling back to codec reset if more than one ISF change occurred during the loss.
The AMR-WB+ RTP payload consists of three octet-aligned sections in order: a 1-byte payload header, a variable-length table of contents (one or more ToC entries), and the audio data frames. All elements are octet-aligned; only AMR-WB frame types (0–9) require per-frame padding.
The format supports two modes: basic mode, where all frames within a payload are consecutive in time, and interleaved mode, where frames may be non-consecutive. The L flag in the payload header selects between 4-bit (L=0) and 8-bit (L=1) displacement fields in interleaved mode. The ISF must remain constant within a single packet.
IANA registered one new MIME subtype: audio/AMR-WB+. Optional parameters include 'channels' (1 or 2, default 2), 'interleaving' (deinterleaving buffer size in transport frame slots), 'int-delay' (minimum buffering delay in RTP timestamp ticks), 'ptime', and 'maxptime'. This type is restricted to real-time RTP transport.
All audio data bits MUST be encrypted to ensure confidentiality. The payload header and ToC carry only frame type metadata and have lesser confidentiality requirements, but encrypting them is not prohibited. When interleaving is used with encryption and a key change is made, frames from prior keys may remain in the interleaving buffer and be playable by participants denied the new key; interleaving patterns SHOULD NOT overlap key changes.
The payload format has no built-in security mechanisms. RTP packets using this format are subject to general RTP security considerations; external mechanisms such as SRTP (RFC 3711) MAY be used for confidentiality, authentication, and integrity.
To authenticate the sender an external mechanism MUST be used, and it is RECOMMENDED that the mechanism protect both the complete RTP header and payload. Data tampering by a man-in-the-middle could replace audio content or produce erroneous depacketization that degrades quality.
A Table of Contents (ToC) entry in basic mode is 16 bits: F (1 bit, more entries follow), Frame Type (7 bits, codec rate/mode per Table 25 of 3GPP TS 26.290), and #frames (8 bits, count of frames in this group). ToC entries with #frames=0 SHALL NOT be used.
In interleaved mode with L=0, a ToC entry extends the basic 16-bit header with a list of n 4-bit unsigned displacement fields (DIS1..DISn, values 0–15) indicating per-frame decoding-order displacement, with 4-bit padding when n is odd. With L=1, displacement fields are 8 bits each (values 0–255), allowing interleaving depths up to 256 frames.
The payload header is 8 bits wide, containing ISF (5 bits) indicating the Internal Sampling Frequency, TFI (2 bits) indicating the Transport Frame Index (position in the AMR-WB+ super-frame), and L (1 bit) flag indicating whether 4-bit or 8-bit displacement fields are used in interleaved mode.