GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5577

Network Working Group P. Luthi Request for Comments: 5577 Tandberg Obsoletes: 3047 R. Even Category: Standards Track Gesher Erove Ltd

                                                             July 2009
        RTP Payload Format for ITU-T Recommendation G.722.1

Abstract

 International Telecommunication Union (ITU-T) Recommendation G.722.1
 is a wide-band audio codec.  This document describes the payload
 format for including G.722.1-generated bit streams within an RTP
 packet.  The document also describes the syntax and semantics of the
 Session Description Protocol (SDP) parameters needed to support
 G.722.1 audio codec.

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) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Luthi & Even Standards Track [Page 1] RFC 5577 G7221 July 2009

Table of Contents

 1. Introduction ....................................................2
 2. Terminology .....................................................3
 3. RTP Usage for G.722.1 ...........................................3
    3.1. RTP G.722.1 Header Fields ..................................3
    3.2. RTP Payload Format for G.722.1 .............................3
    3.3. Multiple G.722.1 Frames in an RTP Packet ...................5
    3.4. Computing the Number of G.722.1 Frames .....................6
 4. IANA Considerations .............................................6
    4.1. Media Type Registration ....................................6
         4.1.1. Registration of Media Type audio/G7221 ..............6
 5. SDP Parameters ..................................................8
    5.1. Usage with the SDP Offer/Answer Model ......................8
 6. Security Considerations .........................................8
 7. Changes from RFC 3047 ...........................................9
 8. Acknowledgments .................................................9
 9. References ......................................................9
    9.1. Normative References .......................................9
    9.2. Informative References ....................................10

1. Introduction

 ITU-T G.722.1 [ITU.G7221] is a low-complexity coder; it compresses 50
 Hz - 14 kHz audio signals into one of the following bit rates: 24
 kbit/s, 32 kbit/s, or 48 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
 ITU-T G.722.1 [ITU.G7221] uses 20-ms frames and a sampling rate clock
 of 16 kHz or 32kHz.  The encoding and decoding algorithm can change
 the bit rate at any 20-ms frame boundary, but no bit rate change
 notification is provided in-band with the bit stream.
 For any given bit rate, the number of bits in a frame is a constant.
 Within this fixed frame, G.722.1 uses variable-length coding (e.g.,
 Huffman coding) to represent most of the encoded parameters.  All
 variable-length codes are transmitted in order from the leftmost bit
 (most significant bit -- MSB) to the rightmost bit (least significant
 bit -- LSB), see [ITU.G7221] for more details.

Luthi & Even Standards Track [Page 2] RFC 5577 G7221 July 2009

 The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or
 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s, or 48
 kbit/s at 32 Khz sample rate.  However, the coding algorithm itself
 has the capability to run at any user-specified bit rate (not just
 24, 32, and 48 kbit/s) while maintaining an audio bandwidth of 50 Hz
 to 14 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.

2. Terminology

 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 [RFC2119] and
 indicate requirement levels for compliant RTP implementations.

3. RTP Usage for G.722.1

3.1. RTP G.722.1 Header Fields

 The RTP header is defined in the RTP specification [RFC3550].  This
 section defines how fields in the RTP header are used.
    Payload Type (PT): The assignment of an RTP payload type for this
    packet format is outside the scope of this document; it is
    specified by the RTP profile under which this payload format is
    used, or it is signaled dynamically out-of-band (e.g., using SDP).
    Marker (M) bit: The M bit is set to zero.
    Extension (X) bit: Defined by the RTP profile used.
    Timestamp: A 32-bit word that corresponds to the sampling instant
    for the first frame in the RTP packet.  The sampling frequency can
    be 16 Khz or 32 Khz.  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.

3.2. RTP Payload Format for G.722.1

 The RTP payload for G.722.1 has the format shown in Figure 1.  No
 additional header fields specific to this payload format are
 required.

Luthi & Even Standards Track [Page 3] RFC 5577 G7221 July 2009

    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                               |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |                                                               |
    +                 one or more frames of G.722.1                 |
    |                             ....                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 1: RTP payload for G.722.1.
 Because bit rate is not signaled in-band, a separate out-of-band
 method is REQUIRED to indicate the bit rate (see Section 5 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
 and clock rates from packet to packet by defining different payload
 type values and switching between them.
 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 to
 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.  When operating at 32 kbit/s, 640 bits (80 octets) are
 produced per frame.  When operating at 48 kbit/s, 960 bits (120
 octets) are produced per frame.  Thus, all three 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.

Luthi & Even Standards Track [Page 4] RFC 5577 G7221 July 2009

       first bit                                          last bit
       transmitted                                     transmitted
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                         |
       + sequence of bits (480, 640, or 960) generated by the    |
       |            G.722.1 encoder for transmission             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           |           |                     |           |
       |           |           |     ...             |           |
       |           |           |                     |           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
       |MSB...  LSB|MSB...  LSB|                     |MSB...  LSB|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
         RTP         RTP                               RTP
         octet 1     octet 2                           octet
                                                    60, 80, 120
         Figure 2:  The G.722.1 encoder bit stream is split into
                    a sequence of octets (60, 80, or 120 depending on
                    the bit rate), and each octet is in turn
                    mapped into an RTP octet.
 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 48000 be used.  Non-standard rates MUST
 have a value that is 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 is mapped
 into RTP per Figure 2.

3.3. Multiple G.722.1 Frames in an RTP Packet

 A sender may include more than one consecutive G.722.1 frame in a
 single RTP packet.
 Senders have the following additional restrictions:
 o  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.
 o  All frames contained in a single RTP packet MUST be of the same
    length and sampled at the same clock rate.  They MUST have the
    same bit rate (octets per frame).

Luthi & Even Standards Track [Page 5] RFC 5577 G7221 July 2009

 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, 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.4. 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.  This expected octet-per-
 frame count is derived from the bit rate and is therefore a function
 of the payload type.

4. IANA Considerations

 This document updates the G7221 media type described in RFC 3047.

4.1. Media Type Registration

 This section describes the media types and names associated with this
 payload format.  The section registers the media types, as per RFC
 4288 [RFC4288]

4.1.1. Registration of Media Type audio/G7221

 Media type name: audio
 Media subtype name: G7221
 Required parameters:
    bitrate: the data rate for the audio bit stream.  This parameter
    is mandatory 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 at 16 Khz sample rate, and 24000,
    32000, or 48000 at 32 Khz sample rate.  If using the non-standard
    bit rates, then it is RECOMMENDED that values in the range 16000
    to 48000 be used.  Non-standard rates MUST have a value that is a
    multiple of 400 (this maintains octet alignment and does not then
    require (undefined) padding bits for each frame if not octet
    aligned).

Luthi & Even Standards Track [Page 6] RFC 5577 G7221 July 2009

 Optional parameters:
    rate: RTP timestamp clock rate, which is equal to the sampling
    rate.  If the parameter is not specified, a clock rate of 16 Khz
    is assumed.
    ptime: see RFC 4566.  SHOULD be a multiple of 20 ms.
    maxptime: see RFC 4566.  SHOULD be a multiple of 20 ms.
 Encoding considerations:
    This media type is framed and binary, see Section 4.8 in
    [RFC4288].
 Security considerations: See Section 6
 Interoperability considerations:
    Terminals SHOULD offer a media type at 16 Khz sample rate in order
    to interoperate with terminals that do not support the new 32 Khz
    sample rate.
 Published specification: RFC 5577.
 Applications that use this media type:
    Audio and Video streaming and conferencing applications.
 Additional information: none
 Person and email address to contact for further information :
    Roni Even: ron.even.tlv@gmail.com
 Intended usage: COMMON
 Restrictions on usage:
    This media type depends on RTP framing, and hence is only defined
    for transfer via RTP [RFC3550].  Transport within other framing
    protocols is not defined at this time.
 Author: Roni Even
 Change controller:
    IETF Audio/Video Transport working group delegated from the IESG.

Luthi & Even Standards Track [Page 7] RFC 5577 G7221 July 2009

5. SDP Parameters

 The media types audio/G7221 are mapped to fields in the Session
 Description Protocol (SDP) [RFC4566] as follows:
 o  The media name in the "m=" line of SDP MUST be audio.
 o  The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the
    media subtype).
 o  The parameter "rate" goes in "a=rtpmap" as clock rate parameter.
 o  Only one bitrate SHALL be defined (using the "bitrate=" parameter
    in the a=fmtp line) for each payload type.

5.1. Usage with the SDP Offer/Answer Model

 When offering G.722.1 over RTP using SDP in an Offer/Answer model
 [RFC3264], the following considerations are necessary.
 The combination of the clock rate in the rtpmap and the bitrate
 parameter defines the configuration of each payload type.  Each
 configuration intended to be used MUST be declared.
 There are two sampling clock rates defined for G.722.1 in this
 document.  RFC 3047 [RFC3047] supports only the 16 Khz clock rate.
 Therefore, a system that wants to use G.722.1 SHOULD offer a payload
 type with clock rate of 16000 for backward interoperability.
 An example of an offer that includes a 16000 and 32000 clock rate is:
           m=audio 49000 RTP/AVP 121 122
           a=rtpmap:121 G7221/16000
           a=fmtp:121 bitrate=24000
           a=rtpmap:122 G7221/32000
           a=fmtp:122 bitrate=48000

6. Security Considerations

 RTP packets using the payload format defined in this specification
 are subject to the security considerations discussed in the RTP
 specification [RFC3550] and any appropriate RTP profile.  The main
 security considerations for the RTP packet carrying the RTP payload
 format defined within this memo are confidentiality, integrity, and
 source authenticity.  Confidentiality is achieved by encryption of
 the RTP payload.  Integrity of the RTP packets is achieved through a
 suitable cryptographic integrity-protection mechanism.  Such a
 cryptographic system may also allow the authentication of the source

Luthi & Even Standards Track [Page 8] RFC 5577 G7221 July 2009

 of the payload.  A suitable security mechanism for this RTP payload
 format should provide confidentiality, integrity protection, and at
 least source authentication capable of determining if an RTP packet
 is from a member of the RTP session.
 Note that the appropriate mechanism to provide security to RTP and
 payloads following this memo may vary.  It is dependent on the
 application, the transport, and the signaling protocol employed.
 Therefore, a single mechanism is not sufficient; although, if
 suitable, usage of the Secure Real-time Transport Protocol (SRTP) is
 [RFC3711] recommended.  Another mechanism that may be used is IPsec
 [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP);
 other alternatives may exist.
 This RTP payload format and its media decoder do not exhibit any
 significant non-uniformity in the receiver-side computational
 complexity for packet processing, and thus are unlikely to pose a
 denial-of-service threat due to the receipt of pathological data.
 Nor does the RTP payload format contain any active content.

7. Changes from RFC 3047

 This specification obsoletes RFC 3047, adding the support for the
 Superwideband (14 Khz) audio support defined in annex C of the new
 revision of ITU-T G.722.1.
 Other changes:
 Updated the text to be in line with the current rules for RFCs and
 with media type registration conforming to RFC 4288.

8. Acknowledgments

 The authors would like to thank Tom Taylor for his contribution to
 this work.

9. References

9.1. Normative References

 [ITU.G7221]  International Telecommunications Union, "Low-complexity
              coding at 24 and 32 kbit/s for hands-free operation in
              systems with low frame loss", ITU-T Recommendation
              G.722.1, 2005.
 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Luthi & Even Standards Track [Page 9] RFC 5577 G7221 July 2009

 [RFC3264]    Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.
 [RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.
 [RFC4566]    Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

9.2. Informative References

 [RFC3047]    Luthi, P., "RTP Payload Format for ITU-T Recommendation
              G.722.1", RFC 3047, January 2001.
 [RFC3711]    Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
              K. Norrman, "The Secure Real-time Transport Protocol
              (SRTP)", RFC 3711, March 2004.
 [RFC4288]    Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288,
              December 2005.
 [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.
 [RFC5246]    Dierks, T. and E. Rescorla, "The Transport Layer
              Security (TLS) Protocol Version 1.2", RFC 5246,
              August 2008.

Luthi & Even Standards Track [Page 10] RFC 5577 G7221 July 2009

Authors' Addresses

 Patrick Luthi
 Tandberg
 Philip Pedersens vei 22
 1366 Lysaker
 Norway
 EMail: patrick.luthi@tandberg.no
 Roni Even
 Gesher Erove Ltd
 14 David Hamelech
 Tel Aviv  64953
 Israel
 EMail: ron.even.tlv@gmail.com

Luthi & Even Standards Track [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5577.txt · Last modified: 2009/07/07 16:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki