summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3802.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3802.txt')
-rw-r--r--doc/rfc/rfc3802.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3802.txt b/doc/rfc/rfc3802.txt
new file mode 100644
index 0000000..706afcf
--- /dev/null
+++ b/doc/rfc/rfc3802.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 3802 Lucent Technologies
+Obsoletes: 2422 G. Parsons
+Category: Standards Track Nortel Networks
+ June 2004
+
+
+ Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code
+ Modulation (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 (2004).
+
+Abstract
+
+ This document describes the registration of the MIME sub-type
+ audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll
+ quality audio. This audio encoding is defined by the ITU-T in
+ Recommendation G.726.
+
+1. Introduction
+
+ 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
+ obsoletes an earlier sub-type registration contained in RFC 1911.
+ This document also obsoletes RFC 2422.
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al. Standards Track [Page 1]
+
+RFC 3802 32 kbit/s ADPCM June 2004
+
+
+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 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 Specification for proper usage.
+
+
+
+
+
+
+Vaudreuil, et al. Standards Track [Page 2]
+
+RFC 3802 32 kbit/s ADPCM June 2004
+
+
+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 Macintosh File Type
+ Code(s): APCM
+
+
+
+
+
+
+
+Vaudreuil, et al. Standards Track [Page 3]
+
+RFC 3802 32 kbit/s ADPCM June 2004
+
+
+ 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 gparsons@NortelNetworks.com
+
+ Gregory M. Vaudreuil GregV@ieee.org
+
+ Intended usage: COMMON
+
+ Author/Change controller:
+
+ Glenn W. Parsons & Gregory M. Vaudreuil
+
+5. 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.
+
+
+
+
+
+
+
+Vaudreuil, et al. Standards Track [Page 4]
+
+RFC 3802 32 kbit/s ADPCM June 2004
+
+
+6. References
+
+6.1. Normative 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).
+
+ [VPIM2R2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet
+ Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
+
+ [REQ] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+6.2. Informative References
+
+ [RFC 3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
+ Types", RFC 3023, January 2001.
+
+ [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.
+
+7. Changes from RFC 2422
+
+ Only editorial and boilerplate changes from RFC 2422 have been made
+ to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al. Standards Track [Page 5]
+
+RFC 3802 32 kbit/s ADPCM June 2004
+
+
+8. Authors' Addresses
+
+ Gregory M. Vaudreuil
+ Lucent Technologies
+ 7291 Williamson Rd
+ Dallas, TX 75214
+ United States
+
+ EMail: gregv@ieee.org
+
+
+ Glenn W. Parsons
+ Nortel Networks
+ P.O. Box 3511, Station C
+ Ottawa, ON K1Y 4H7
+ Canada
+
+ Phone: +1-613-763-7582
+ Fax: +1-613-763-2697
+ EMail: gparsons@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al. Standards Track [Page 6]
+
+RFC 3802 32 kbit/s ADPCM June 2004
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Vaudreuil, et al. Standards Track [Page 7]
+