Internet DRAFT - draft-crossman-avt-rtp-g7221
draft-crossman-avt-rtp-g7221
Network Working Group Name
A. Crossman
Internet Draft
PictureTel
Document: <draft-ietf-avt-rtp-g7221-00.txt>
December 1999
Category: Standards Track
RTP Payload Load Format for ITU-T Recommendation G.722.1
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [ ].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
ITU-T Recommendation G.722.1 [ ] is a wideband coder, it operates at
one of two selectable bit rates, 24kbit/s or 32kbit/s. This
document describes the payload format for including G.722.1
generated bit streams within an RTP packet [ ]. Also included here
are the necessary details for the use of G.722.1 with MIME [ ] and
SDP [ ].
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [ ].
3. Overview of ITU-T Recommendation G.722.1
G.722.1 is a low complexity coder, it compresses 50Hz - 7kHz audio
signals into one of two bit rates, 24 kbit/s or 32 kbit/s. The
coder may be used for speech, music and other types of audio.
Some of the applications for which this coder is suitable are:
o Real-time communications such as videoconferencing and
telephony.
o Streaming audio
o Archival and messaging
A fixed frame size of 20ms is used, and for any given bit rate the
number of bits in a frame is a constant.
4. RTP payload format for G.722.1
The RTP timestamp MUST be in units of 1/16000 of a second. The RTP
payload for G.722.1 has the following format:
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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G.722.1 uses 20 ms frames and a sampling rate clock of 16 kHz. The
bit rate can be changed at any 20ms frame boundary, although bit
rate change notification is not provided inband 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). When operating at 24 kbit/s, 480 bits (60
octets) are produced per frame, and when operating at 32 kbit/s, 640
bits (80 octets) are produced per frame. Thus, both bit rates allow
for octet alignment without the need for padding bits.
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 coder parameters/fields contained within the bit stream
without first completely decoding the entire frame.
For the purposes of packetizing the bit stream in RTP, it is only
necessary to consider the sequence of bits as output by the G.722.1
encoder, and present the same sequence to the decoder. The payload
format described here maintains this sequence.
Figure 3.1 illustrates how the G.722.1 bit stream MUST be mapped
into an octet aligned RTP payload.
An RTP packet SHALL only contain G.722.1 frames of the same bit
rate.
first bit last bit
transmitted transmitted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence of bits (480 or 640) generated by the |
| G.722.1 encoder for transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| | | ... | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB|MSB... LSB| |MSB... LSB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
RTP RTP RTP
octet 1 octet 2 octet
60 or 80
Figure 3.1 The G.722.1 encoder bit stream is split into a
sequence of octets (60 or 80 depending on the bit rate),
and each octet is in turn mapped into an RTP octet.
The ITU-T standardized bit rates for G.722.1 are 24 kbit/s and
32kbit/s. However, the coding algorithm itself has the capability
to run at any user specified bit rate (not just 24 and 32kbit/s û
see section 5 for further details on acceptable non-standard bit
rate values) while maintaining an audio bandwidth of 50 Hz to 7 kHz.
When operating at non-standard rates the payload format SHOULD
follow the guidelines illustrated in Figure 3.1. For example, a bit
rate of 16.4 kbit/s will result in a frame of size 328 bits or 41
octets which are mapped into RTP per Figure 3.1.
4.1 Multiple G.722.1 frames in a RTP packet
More than one G.722.1 frame may be included in a single RTP packet
by a sender.
Senders have the following additional restrictions:
o MUST not include more G.722.1 frames in a single RTP packet than
will fit in the MTU of the RTP transport protocol.
o Frames MUST not be split between RTP packets.
It is RECOMMENDED that the number of frames contained within an RTP
packet be consistent with the application. For example, in a
telephony application where delay is important, then the fewer
frames per packet the lower the delay, whereas for a delay
insensitive streaming or messaging application, many frames per
packet would be acceptable.
4.2 Computing the number of G.722.1 frames
Information describing the number of frames contained in an RTP
packet is not transmitted as part of the RTP payload. The only way
to determine the number of G.722.1 frames is to count the total
number of octets within the RTP packet, and divide the octet count
by the number of expected octets per frame (either 60 or 80 per
frame, for 24 kbit/s and 32 kbit/s respectively).
5. MIME registration of G.722.1
MIME media type name: audio
MIME subtype: g7221
Required parameters: None
Optional parameters:
bitrate: the data rate for the audio bit stream. This
parameter is necessary because the bit rate is not signaled
within the G.722.1 bit stream. At the standard G.722.1 bit
rates, the value MUST be either 24000 or 32000. If using the
non-standard bit rates, then it is RECOMMENDED values in the
range 16000 to 32000 be used, and that any value SHOULD be a
multiple of 400 (this maintains octet alignment and does not
then require (undefined) padding bits for each frame if not
octet aligned).
ptime: RECOMMENDED duration of each packet in milliseconds.
Published specification:
see ITU-T Recommendation G.722.1 for encoding algorithm
details.
6. SDP usage of G.722.1
When conveying information by SDP [5], the encoding name SHALL be
ôg7221ö (the same as the MIME subtype). An example of the media
representation in SDP might be:
m=audio 49000 RTP/AVP 121
a=rtpmap:121 g7221/16000
a=fmtp:121 bitrate=24000
where ôbitrateö is a variable that may take on values of 24000 or
32000 at the standard rates, or values from 16000 to 32000 (and
SHOULD be an integer multiple of 400) at the non-standard rates.
7. Security Considerations
The registration procedure specified in this memo does not impose
any security considerations on its own.
8. References
9. Acknowledgments
The author wishes to thank Steve Casner and Colin Perkins for their
review of this draft.
10. Author's Addresses
Antony Crossman
PictureTel Corporation
100 Minuteman Road
Andover, MA 01810
USA
Phone: +1 (978) 292 4557
Email: tonyc@pictel.com
Full Copyright Statement
"Copyright (C) The Internet Society (December, 1999). All Rights
Reserved. This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in part,
without restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be modified
in any way, such as by removing the copyright notice or references
to the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
ITU-T Recommendation G.722.1, available online from the ITU
bookstore at http://www.itu.int
H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
Transport Protocol for real-time applications, ôRFC 1889, January
1996, updated by draft-ietf-avt-rtp-new (work in porgress).
N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC 2045,
November 1996.
M. Handley and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Payload Load Format G.722.1 Dec 1999
Crossman Category - Expiration 4
Crossman Category - Expiration 1
