Movatterモバイル変換

Network Working Group                                       G. VaudreuilRequest for Comments: 3802                           Lucent TechnologiesObsoletes:2422                                               G. ParsonsCategory: Standards Track                                Nortel Networks                                                               June 2004Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse CodeModulation (ADPCM) MIME Sub-type RegistrationStatus 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 inRFC 1911.   This document also obsoletesRFC 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 20042.  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 Definition3.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 20044.  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):  APCMVaudreuil, 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. Vaudreuil5.  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 20046.  References6.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",RFC1911, 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 fromRFC 2422   Only editorial and boilerplate changes fromRFC 2422 have been made   to this document.Vaudreuil, et al.           Standards Track                     [Page 5]

RFC 3802                    32 kbit/s ADPCM                    June 20048.  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.comVaudreuil, et al.           Standards Track                     [Page 6]

RFC 3802                    32 kbit/s ADPCM                    June 20049.  Full Copyright Statement   Copyright (C) The Internet Society (2004).  This document is subject   to the rights, licenses and restrictions contained inBCP 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 inBCP 78 andBCP 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 athttp://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]