RTP Payload Format for ITU-T Recommendation G.722.1
obsoletes
- rfc-3047 — RTP Payload Format for ITU-T Recommendation G.722.1
Extracted elements (20)
No frame count field is included in the RTP payload because the fixed frame size at any given bit rate allows the receiver to compute the frame count by dividing the payload length by the known octets-per-frame value derived from the payload type.
Non-standard bit rates are constrained to multiples of 400 bits/s so that each 20-ms frame contains an integer number of octets, eliminating the need for undefined padding bits in the RTP payload.
RFC 5577 obsoletes RFC 3047 primarily to add Superwideband (14 kHz) audio support defined in Annex C of the revised ITU-T G.722.1, and to add a 32 kHz sampling rate alongside the original 16 kHz rate. Text was also updated to conform to current RFC and media type registration rules.
A system offering G.722.1 SHOULD include a payload type with a 16 kHz clock rate for backward interoperability with RFC 3047 terminals that do not support the 32 kHz sample rate. Terminals SHOULD offer a media type at 16 kHz to interoperate with such terminals.
A sender SHOULD NOT include more G.722.1 frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
A separate out-of-band method is REQUIRED to indicate the bit rate, because bit rate is not signaled in-band within the G.722.1 bit stream.
All G.722.1 frames within a single RTP packet MUST be of the same length and sampled at the same clock rate, with the same bit rate (octets per frame). Frames MUST NOT be split between RTP packets.
Each combination of clock rate and bitrate parameter that is intended to be used MUST be declared as a separate payload type configuration in the SDP offer.
In SDP, the media name in the 'm=' line MUST be 'audio', the encoding name in 'a=rtpmap' MUST be 'G7221', and only one bitrate SHALL be defined per payload type using the 'bitrate=' parameter in the 'a=fmtp' line.
Non-standard bit rates MUST have a value that is a multiple of 400 bits/s to maintain octet alignment. It is RECOMMENDED that values in the range 16000 to 48000 be used.
The bit rate MUST remain constant for a particular payload type value. An application MAY switch bit rates and clock rates from packet to packet by defining different 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 within each octet.
The Marker (M) bit in the RTP header is set to zero for G.722.1 payloads.
The 'ptime' and 'maxptime' SDP parameters SHOULD be a multiple of 20 ms, matching the G.722.1 frame duration.
The RTP timestamp clock frequency of 32 kHz SHOULD be used unless only an RTP stream sampled at 16 kHz is going to be sent.
The number of G.722.1 frames in an RTP packet is not transmitted in the payload; receivers determine it by dividing the total RTP payload octet count by the expected octets-per-frame derived from the payload type's bit rate.
The RTP payload for G.722.1 consists of the standard RTP header followed by one or more consecutive G.722.1 frames, with no additional payload-specific header fields. The payload type is assigned by the RTP profile or signaled out-of-band.
This document registers the media type audio/G7221, with mandatory parameter 'bitrate' (24000, 32000, or 48000 at 32 kHz; 24000 or 32000 at 16 kHz for standard rates) and optional parameters 'rate', 'ptime', and 'maxptime'.
RTP packets carrying G.722.1 require confidentiality (via payload encryption), integrity protection, and source authentication. SRTP (RFC 3711) is recommended; IPsec and TLS are noted as alternatives. The payload format and decoder present no significant non-uniformity in receiver-side computational complexity and are unlikely to pose a denial-of-service threat.
G.722.1 encoder output is mapped MSB-first into RTP octets. At 24 kbit/s, each frame produces 480 bits (60 octets); at 32 kbit/s, 640 bits (80 octets); at 48 kbit/s, 960 bits (120 octets). All three standard rates are inherently octet-aligned.