RFC 3047 (rfc3047) - Page 2 of 8
RTP Payload Format for ITU-T Recommendation G
Alternative Format: Original Text Document
RFC 3047 Payload Format G.722.1 January 2001
A fixed frame size of 20 ms is used, and for any given bit rate the
number of bits in a frame is a constant.
3. RTP payload format for G.722.1
G.722.1 uses 20 ms frames and a sampling rate clock of 16 kHz, so the
RTP timestamp MUST be in units of 1/16000 of a second. The RTP
payload for G.722.1 has the format shown in Figure 1. No additional
header specific to this payload format is required.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of G.722.1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP payload for G.722.1
The encoding and decoding algorithm can change the bit rate at any
20ms frame boundary, but no bit rate change notification is provided
in-band with the bit stream. Therefore, a separate out-of-band
method is REQUIRED to indicate the bit rate (see section 6 for an
example of signaling bit rate information using SDP). For the
payload format specified here, 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 assignment of an RTP payload type for this new packet format is
outside the scope of this document, and will not be specified here.
It is expected that the RTP profile for a particular class of
applications will assign a payload type for this encoding, or if that
is not done then a payload type in the dynamic range shall be chosen.
The number of bits within a frame is fixed, and within this fixed
frame G.722.1 uses variable length coding (e.g., Huffman coding) to
represent most of the encoded parameters [2]. All variable length
codes are transmitted in order from the left most (most significant -
MSB) bit to the right most (least significant - LSB) bit, see [2] for
more details.
The use of Huffman coding means that it is not possible to identify
the various encoded parameters/fields contained within the bit stream
without first completely decoding the entire frame.
Luthi Standards Track