summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2422.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2422.txt')
-rw-r--r--doc/rfc/rfc2422.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2422.txt b/doc/rfc/rfc2422.txt
new file mode 100644
index 0000000..da308b5
--- /dev/null
+++ b/doc/rfc/rfc2422.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+