[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-crossman-avt-rtp-g7221) 00 RFC 3047

Audio/Video Transport Working Group                            P. Luthi
Internet Draft                                               PictureTel
Document: <draft-ietf-avt-rtp-g7221-00.txt>                   June 2000
Category: Standards Track


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

   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 [2] 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 [3].  Also included here
   are the necessary details for the use of G.722.1 with MIME [4] and
   SDP [5].


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


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.

Luthi                                                          [Page 1]


                         Payload Format G.722.1               June 2000

   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 format shown in Figure 1.


       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


   G.722.1 uses 20 ms frames and a sampling rate clock of 16 kHz.  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.

   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.

Luthi                    Category - Expiration                 [Page 2]


                         Payload Format G.722.1               June 2000

   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.

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

Luthi                    Category - Expiration                 [Page 3]


                         Payload Format G.722.1               June 2000

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


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


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

Luthi                    Category - Expiration                 [Page 4]


                         Payload Format G.722.1               June 2000

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

        ptime: RECOMMENDED duration of each packet in milliseconds.

   Encoding considerations:
        This type is only defined for transfer via RTP as specified in
        "draft-ietf-avt-rtp-g7221-01".

   Security considerations: none

   Interoperability considerations: none

   Published specification:
        See ITU-T Recommendation G.722.1 for encoding algorithm
        details.

   Applications which use this media type:
        Audio and video streaming and conferencing tools

   Additional information: none

   Person & email address to contact for further information:
        Patrick Luthi
        Luthip@pictel.com

   Intended usage: COMMON

   Author/Change controller:
        Author: Patrick Luthi
        Change controller: IETF AVT Working Group


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 for describing G.722.1 at 24000 bits/sec might
   be:

        m=audio 49000 RTP/AVP 121
        a=rtpmap:121 G7221/16000

Luthi                    Category - Expiration                 [Page 5]


                         Payload Format G.722.1               June 2000

        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

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  ITU-T Recommendation G.722.1, available online from the ITU
      bookstore at http://www.itu.int.

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

   4  N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions
      (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
      November 1996.

   5  M. Handley and V. Jacobson, "SDP: Session Description Protocol",
      RFC 2327, April 1998.

   6  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997


9. Acknowledgments

   The author wishes to thank Tony Crossman for starting this work on
   G.722.1 packetization and for authoring the initial draft. The
   author also wishes to thank Steve Casner and Colin Perkins for their
   helpful comments.


10. Author's Addresses

   Patrick Luthi
   PictureTel Corporation
   100 Minuteman Road
   Andover, MA 01810
   USA
   Phone: +1 (978) 292 4354
   Email: luthip@pictel.com

Luthi                    Category - Expiration                 [Page 6]


                         Payload Format G.722.1               June 2000


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
   languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."























Luthi                    Category - Expiration                 [Page 7]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/