rfc3047.txt

最新的RFC


RFC 3047                 Payload Format G.722.1             January 2001


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

   Optional parameters:

         ptime: RECOMMENDED duration of each packet in milliseconds.

   Encoding considerations:
         This type is only defined for transfer via RTP as specified in
         a Work in Progress.

   Security Considerations:
         See Section 6 of RFC 3047.

   Interoperability considerations: none

   Published specification:
         See ITU-T Recommendation G.722.1 [2] 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
         [e-mail]

   Intended usage: COMMON

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








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


5. 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
         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 MUST
   be an integer multiple of 400) at the non-standard rates.

6. Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [3], and any appropriate RTP profile.  This implies
   that confidentiality of the media streams is achieved by encryption.
   Because the data compression used with this payload format is applied
   end-to-end, encryption may be performed after compression so there is
   no conflict between the two operations.

   A potential denial-of-service threat exists for data encodings using
   compression techniques that have non-uniform receiver-end
   computational load.  The attacker can inject pathological datagrams
   into the stream which are complex to decode and cause the receiver to
   be overloaded.  However, this encoding does not exhibit any
   significant non-uniformity.

   As with any IP-based protocol, in some circumstances a receiver may
   be overloaded simply by the receipt of too many packets, either
   desired or undesired.  Network-layer authentication may be used to
   discard packets from undesired sources, but the processing cost of
   the authentication itself may be too high.  In a multicast
   environment, pruning of specific sources may be implemented in future
   versions of IGMP [7] and in multicast routing protocols to allow a
   receiver to select which sources are allowed to reach it.











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


7. 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. Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
      A Transport Protocol for real-time applications", RFC 1889,
      January 1996.  (Updated by a Work in Progress.)

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

   5. Handley, M. 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.

   7. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
      1112, August 1989.

8. 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
   valuable feedback and helpful comments.

9. Author's Address

   Patrick Luthi
   PictureTel Corporation
   100 Minuteman Road
   Andover, MA 01810
   USA

   Phone: [phone]
   EMail: [e-mail]









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


10. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Luthi                       Standards Track                     [Page 8]