RTP Payload Format for ITU-T Recommendation G.722.1
obsoleted by
- rfc-5577 — RTP Payload Format for ITU-T Recommendation G.722.1
Extracted elements (24)
Because G.722.1 uses Huffman coding within a fixed-size frame, it is impossible to identify individual encoded parameters in the bit stream without fully decoding the frame; therefore the payload format simply preserves the raw bit sequence without reframing.
Both standard bit rates (24 kbit/s yielding 60-octet frames, 32 kbit/s yielding 80-octet frames) are chosen to allow natural octet alignment, avoiding the need for any padding bits.
Non-standard bit rates must be multiples of 400 specifically to maintain octet alignment; without this constraint, frames would not end on octet boundaries and undefined padding would be required.
The number of frames per RTP packet is left to application policy rather than fixed, because telephony favors low frame counts for low latency while streaming/messaging applications can tolerate higher counts for efficiency.
The coding algorithm can operate at any user-specified bit rate (not just 24 or 32 kbit/s) via linear scaling, producing frames whose size in bits equals 1/50 of the bit rate; non-standard rates must follow the same payload format as standard rates.
The RTP payload type assignment for G.722.1 is outside the scope of this document; it is expected that the applicable RTP profile will assign a payload type, or a dynamic range value shall be chosen.
A separate out-of-band method is REQUIRED to indicate the bit rate, since no in-band bit rate change notification is provided within the G.722.1 bit stream.
All frames contained in a single RTP packet MUST be of the same length (same bit rate), and frames MUST NOT be split between RTP packets.
An RTP packet SHALL only contain G.722.1 frames of the same bit rate.
For the MIME 'bitrate' parameter at standard G.722.1 rates, the value MUST be either 24000 or 32000. For non-standard rates, the value MUST be a multiple of 400, with RECOMMENDED range of 16000 to 32000.
Senders SHOULD NOT include more G.722.1 frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
The bit rate MUST remain constant for a particular payload type value. An application MAY switch bit rates from packet to packet by defining two payload type values and switching between them.
The G.722.1 bit stream MUST be mapped into an octet-aligned RTP payload as illustrated in Figure 2, with bits transmitted MSB to LSB.
The RTP timestamp for G.722.1 MUST be in units of 1/16000 of a second, reflecting the 16 kHz sampling rate clock used by G.722.1.
When conveying G.722.1 information in SDP, the encoding name SHALL be 'G7221'.
When operating at non-standard rates, any bit rate value MUST be a multiple of 400 to maintain octet alignment without requiring padding bits.
G.722.1 uses a fixed frame size of 20 ms, a 16 kHz sampling rate, and compresses 50 Hz–7 kHz audio at 24 kbit/s or 32 kbit/s using variable-length (Huffman) coding within a fixed frame bit count.
The MIME media type is 'audio/G7221' with required parameter 'bitrate' (the data rate in bits/sec) and optional parameter 'ptime' (recommended packet duration in milliseconds).
The number of G.722.1 frames in an RTP packet is not transmitted in the payload; receivers determine the frame count by dividing the total payload octet count by the expected octets per frame (60 or 80).
A denial-of-service threat exists if a codec has non-uniform receiver-side computational load, allowing attackers to inject complex-to-decode datagrams. The document notes that G.722.1 does not exhibit significant non-uniformity, mitigating this risk.
Confidentiality of G.722.1 media streams is achieved through encryption per the RTP specification. Since compression is applied end-to-end, encryption may be performed after compression without conflict.
Receivers may be overloaded by excessive packet volume (desired or not). Network-layer authentication can filter undesired sources, though its processing cost may itself be prohibitive; future IGMP and multicast routing extensions may allow source pruning.
G.722.1 bit stream bits are mapped into RTP octets in order from MSB (most significant bit) to LSB (least significant bit), with 480 bits (60 octets) per frame at 24 kbit/s and 640 bits (80 octets) per frame at 32 kbit/s.
The RTP payload for G.722.1 consists of the standard RTP header followed by one or more complete G.722.1 frames, with no additional payload-specific header. At 24 kbit/s, each frame is 60 octets; at 32 kbit/s, each frame is 80 octets.