home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group G. Vaudreuil
- Request for Comments: 2422 Lucent Technologies
- Obsoletes: 1911 G. Parsons
- Category: Standards Track Northern Telecom
- September 1998
-
-
- Toll Quality Voice - 32 kbit/s ADPCM
- MIME Sub-type Registration
-
- 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 (1998). All Rights Reserved.
-
- Overview
-
- This document describes the registration of the MIME sub-type
- audio/32KADPCM for toll quality audio. This audio encoding is
- defined by the ITU-T in Recommendation G.726.
-
- 1. Abstract
-
- This document describes the registration of the MIME sub-type
- audio/32KADPCM for toll quality audio. This audio encoding is
- defined by the ITU-T in Recommendation G.726. This document refines
- an earlier sub-type registration in RFC 1911.
-
- 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 [REQ].
-
- 2. ITU-T Definition
-
- Recommendation G.726 [G726] defines the characteristics that are
- recommended for the conversion of a 64 kbit/s A-law or m-law pulse
- code modulation (PCM) channel at 8000 samples/second to and from a
- 40, 32, 24 or 16 kbit/s channel. The conversion is applied to the PCM
-
-
-
-
-
-
- Vaudreuil & Parsons Standards Track [Page 1]
-
- RFC 2422 32 kbit/s ADPCM September 1998
-
-
- bit stream using an adaptive differential pulse code modulation
- (ADPCM) transcoding technique. This Recommendation obsoletes G.721
- which only defined the 32 kbit/s characteristics.
-
- Recommendation G.726 was prepared by Study Group 15 of the
- Telecommunications Standardization Sector of the International
- Telecommunication Union (ITU-T) and was approved under the ITU's
- Resolution No. 2 procedure on the 14 of December 1990.
-
- 3. MIME Definition
-
- 3.1 audio/32KADPCM
-
- CCITT Recommendation G.726 [G726] describes the algorithm recommended
- for conversion of a 64 kbit/s A-law or u-law PCM channel to and from
- a 32 kbit/s channel (this is the same algorithm as described in the
- deprecated G.721). The conversion is applied to the PCM stream using
- an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding
- technique.
-
- The MIME sub-type audio/32KADPCM is defined to hold binary audio data
- encoded in 32 kbit/s ADPCM exactly as defined by ITU-T Recommendation
- G.726. No header information shall be included as part of the audio
- data. The content transfer encoding is typically either binary or
- base64.
-
- An additional consideration that this document defines for clarity is
- the choice of little endian ordering of the four bit code words.
- This default ordering is defined in ITU-T Recommendation X.420 [X420]
- for the equivalent X.400 body part, but is also detailed below in the
- IANA Registration.
-
- 3.2 VPIM Usage
-
- The audio/32KADPCM sub-type is a primary component of the VPIM
- specification [VPIM]. In this context, the Content-Description and
- Content-Disposition headers are used to succinctly describe the
- contents of the audio body. As well, only the little endian bit
- ordering is valid. Refer to the VPIM Specifcation for proper usage.
-
-
-
-
-
-
-
-
-
-
-
-
- Vaudreuil & Parsons Standards Track [Page 2]
-
- RFC 2422 32 kbit/s ADPCM September 1998
-
-
- 4. IANA Registration
-
- To: ietf-types@iana.org
- Subject: Registration of MIME media type audio/32KADPCM
-
- MIME media type name: audio
-
- MIME subtype name: 32KADPCM
-
- Required parameters: none
-
- Optional parameters: none
-
- Encoding considerations:
-
- Binary or Base-64 generally preferred
-
- Security considerations:
-
- There are no known security risks with the sending or
- playing of raw audio data Audio data is typically
- interpreted only by an audio codec. Unintended information
- introduced into the data stream will result in noise.
-
-
- Interoperability considerations:
-
- The four bit code word ordering within a byte may differ
- between existing implementations of G.726 codecs. Since
- this content only permits the little endian ordering, codecs
- that support the opposite ordering must reorder the code
- words before storing to or retrieving from this content
- type.
-
-
- Published specification:
-
- ITU-T G.726 with little endian ordering
-
- Applications which use this media type:
-
- primarily voice messaging
-
- Additional information:
-
- Magic number(s): ?
- File extension(s): .726
-
-
-
-
- Vaudreuil & Parsons Standards Track [Page 3]
-
- RFC 2422 32 kbit/s ADPCM September 1998
-
-
- Macintosh File Type Code(s): APCM
-
- Little Endian Ordering:
-
- The 4-bit code words of the G.726 encoding MUST be packed
- into octets/bytes as follows: the first code word (A) is
- placed in the four least significant bits of the first
- octet, with the least significant bit (LSB) of the code word
- (A0) in the least significant bit of the octet; the second
- code word (B) is placed in the four most significant bits of
- the first octet, with the most significant bit (MSB) of the
- code word (B3) in the most significant bit of the octet.
- Subsequent pairs of the code words shall be packed in the
- same way into successive octets, with the first code word of
- each pair placed in the least significant four bits of the
- octet. It is preferred that the voice sample be extended
- with silence such that the encoded value comprises an even
- number of code words. However, if the voice sample
- comprises an odd number of code words, then the last code
- word shall be discarded.
-
-
- +--+--+--+--+--+--+--+--+
- |B3|B2|B1|B0|A3|A2|A1|A0|
- +--+--+--+--+--+--+--+--+
- MSB -> | 7| 6| 5| 4| 3| 2| 1| 0| <- LSB
- +--+--+--+--+--+--+--+--+
-
- 32K ADPCM / Octet Mapping
-
-
- Person & email address to contact for further information:
-
- Glenn W. Parsons
- Glenn.Parsons@Nortel.ca
-
- Gregory M. Vaudreuil
- GregV@Lucent.Com
-
- Intended usage: COMMON
-
- Author/Change controller:
-
- Glenn W. Parsons & Gregory M. Vaudreuil
-
-
-
-
-
-
-
- Vaudreuil & Parsons Standards Track [Page 4]
-
- RFC 2422 32 kbit/s ADPCM September 1998
-
-
- 5. Authors' Addresses
-
- Glenn W. Parsons
- Northern Telecom
- P.O. Box 3511, Station C
- Ottawa, ON K1Y 4H7
- Canada
-
- Phone: +1-613-763-7582
- Fax: +1-613-763-4461
- EMail: Glenn.Parsons@Nortel.ca
-
-
- Gregory M. Vaudreuil
- Lucent Technologies
- 17080 Dallas Parkway
- Dallas, TX 75248-1905
- United States
-
- Phone/Fax: +1-972-733-2722
- EMail:GregV@Lucent.Com
-
- 6. References
-
- [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital
- Transmission Systems, Terminal Equipment - 40, 32, 24,16
- kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).
-
- [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
- Mail Extensions (MIME) Part Four: Registration Procedures",
- RFC 2048, November 1996.
-
- [VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911,
- February 1996.
-
- [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
- Mail - version 2", RFC 2421, September 1998.
-
- [X420] ITU-T Recommendation X.420 (1996) - ISO/IEC 10021-7:1996,
- Message handling systems: Interpersonal messaging.
-
- [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
- Vaudreuil & Parsons Standards Track [Page 5]
-
- RFC 2422 32 kbit/s ADPCM September 1998
-
-
- 7. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). 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 implmentation 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."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Vaudreuil & Parsons Standards Track [Page 6]
-
-