rfc3047.txt

最新的RFC

Network Working Group                                           P. Luthi
Request for Comments: 3047                                    PictureTel
Category: Standards Track                                   January 2001


          RTP Payload Format for ITU-T Recommendation G.722.1

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   International Telecommunication Union (ITU-T) Recommendation G.722.1
   is a wide-band audio codec, which 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.

1. 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 [6].

2. 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





Luthi                       Standards Track                     [Page 1]

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                     [Page 2]

RFC 3047                 Payload Format G.722.1             January 2001


   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.

   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.

   Figure 2 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 2:  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) while
   maintaining an audio bandwidth of 50 Hz to 7 kHz.  This rate change
   is accomplished by a linear scaling of the codec operation, resulting
   in frames with size in bits equal to 1/50 of the corresponding bit
   rate.



Luthi                       Standards Track                     [Page 3]

RFC 3047                 Payload Format G.722.1             January 2001


   When operating at non-standard rates the payload format MUST follow
   the guidelines illustrated in Figure 2.  It is RECOMMENDED that
   values in the range 16000 to 32000 be used, and that any value MUST
   be a multiple of 400 (this maintains octet alignment and does not
   then require (undefined) padding bits for each frame if not octet
   aligned).  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 2.

3.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  SHOULD NOT include more G.722.1 frames in a single RTP packet than
      will fit in the MTU of the RTP transport protocol.

   o  All frames contained in a single RTP packet MUST be of the same
      length, that is they MUST have the same bit rate (octets per
      frame).

   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.

3.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).

4. MIME registration of G.722.1

   MIME media type name: audio

   MIME subtype: G7221





Luthi                       Standards Track                     [Page 4]