INTERNET-DRAFT Laile L. Di Silvestro (Microsoft) Expires in 6 months Erik Hedberg (Microsoft) Greg Baribault (Microsoft) Microsoft Corporation April 1, 1999 Toll Quality Voice - Microsoft GSM MIME Sub-type Registration Status of this memo: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft is being discussed by the Electronic Messaging Association VPIM work group. To subscribe to the mailing list, send a message to EMA Listserv Requests [listserv@listmail.ema.org] with the line "subscribe VPIM-L" in the body of the message. Di Silvestro, Hedberg, Baribault Expires 10/1/99 [Page 1] Internet Draft audio/ms-gsm 4/1/99 Abstract This document describes the registration of the MIME sub-type audio/ms-gsm for toll quality audio. This audio encoding is defined by the European Telecommunications Standards Institute (ETSI) in ETS 300 961. 1. Introduction The MIME subtype "ms-gsm" is being defined primarily for use in multimedia and voice messaging standards. The Voice Profile for Internet Messaging, version 3 [VPIM3] working draft specifies that all VPIM version 3 compliant implementations MAY generate audio/ms-gsm bodyparts and MUST receive audio/ms-gsm bodyparts. 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. ETSI Definition ETS 300 961 (GSM 06.10 version 5.1.1) [GSM] was prepared by European Telecommunications Standards Institute (ETSI) in May 1998. It is a reproduction of recommendation T/L/03/11 "13kbit/s Regular Pulse Excitation - Long Term Prediction - Linear Predictive Coder for use in the digital cellular telecommunications system." ETS 300 961 describes the detailed mapping between input blocks of 160 speech samples in 13 bit uniform PCM format to encoded blocks of 260 bits, and from encoded blocks of 260 bits to output blocks of 160 reconstructed speech samples. The sampling rate is 8000 sample/s leading to an average bit rate for the encoded bit stream of 13 kbit/s. The coding scheme is the so-called Regular Pulse Excitation - Long Term prediction - Linear Predictive Coder, here-after referred to as RPE-LTP. 2.1 Parameter storage ETS 300 961 provides a detailed description of the mapping of blocks of 160 speech samples in 13 bit uniform PCM format to 76 encoder parameters, and the mapping from those encoder parameters back to 160 reconstructed speech samples. The 76 encoder parameters vary in width from 2 to 7 bits, so they all fit in 260 bits. ETS 300 961 does not define the correct way to store these 76 parameters in a computer file, however. To promote interoperability, this document describes the MS-GSM version of GSM 06.10 which is to be used to encode audio/ms-gsm data. Di Silvestro, Hedberg, Baribault Expires 10/1/99 [Page 2] Internet Draft audio/ms-gsm 4/1/99 Audio/ms-gsm implementations MUST pack two sets of encoder output parameters into 65 bytes and MUST right justify the parameters in a byte. Since each set of encoder output parameters occupies 32.5 bytes, the two sets will be offset by a nibble (4 bits). In this illustration, as in ETS 300 961, arrays are 1-based and the least significant bit is numbered 1. The first eight encoder parameters are named LAR1 through LAR8, and they vary from 6 to 3 bits in width. The notation LAR1[6-3] indicates the 4 high order bits of LAR1, and LAR5[2-1] indicates the 2 low-order bits of LAR5. The remaining 68 parameters are packed similarly. MSB LSB Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR2[2-1] | LAR1[6-1] | +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR3[4-1] | LAR2[6-3] | +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR5[2-1] | LAR4[5-1] |LAR3[5]| +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR7[2-1] | LAR6[4-1] | LAR5[4-3] | +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR8[3-1] |LAR7[3]| +-------+-------+-------+-------+ 3. MIME Definition 3.1 audio/ms-gsm European Telecommunications Standards Institute (ETSI) ETS 300 961 [GSM] describes the algorithm recommended for conversion of blocks of 160 speech samples in 13 bit uniform PCM format to encoded blocks of 260 bits, and the mapping back from those 260 bit blocks to output blocks of 160 reconstructed speech samples. The MIME sub-type audio/ms-gsm is defined to hold binary audio data encoded exactly as defined by ETS 300 961 (GSM 06.10) No header information shall be included as part of the audio data. The content transfer encoding is typically either binary or base64. To enable interoperability, the audio data MUST conform to the parameter storage definition provided in the section above and in the IANA registration below. Di Silvestro, Hedberg, Baribault Expires 10/1/99 [Page 3] Internet Draft audio/ms-gsm 4/1/99 3.2 VPIM Usage The audio/ms-gsm sub-type is a component of the proposed VPIM version 3 specification [VPIM3]. In this context, the Content-Description headers is used to succinctly describe the contents of the audio body. All VPIM Version 3 systems MUST be capable of receiving audio encoded in the MS-GSM version of GSM 06.10. Sending systems MAY choose to send audio data encoded in MS-GSM. All receiving systems MUST be able to process MS-GSM audio data. Refer to the VPIM Specification for proper usage. 4. IANA Registration To: ietf-types@iana.org Subject: Registration of MIME media type audio/ms-gsm MIME media type name: audio MIME subtype name: ms-gsm 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: MS-GSM is not compatible with other GSM 06.10 implementations. To be interoperable, Audio/ms-gsm implementations MUST pack two encoder parameter blocks into 65 bytes and MUST right justify the parameters in a byte. Di Silvestro, Hedberg, Baribault Expires 10/1/99 [Page 4] Internet Draft audio/ms-gsm 4/1/99 In this illustration, as in ETS 300 961, arrays are 1-based and the least significant bit is numbered 1. The first 8 encoder parameters are named LAR1 through LAR8, and they vary from 6 to 3 bits in width. The notation LAR1[6-3] indicates the 4 high order bits of LAR1, and LAR5[2-1] indicates the 2 low-order bits of LAR5. The remaining 68 parameters are packed similarly. MSB LSB Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR2[2-1] | LAR1[6-1] | +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR3[4-1] | LAR2[6-3] | +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR5[2-1] | LAR4[5-1] |LAR3[5]| +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR7[2-1] | LAR6[4-1] | LAR5[4-3] | +-------+-------+-------+-------+-------+-------+-------+-------+ | LAR8[3-1] |LAR7[3]| +-------+-------+-------+-------+ Published specification: ETS 300 961 (May 1998), "Digital cellular telecommunications system (Phase 2+); Full rate speech; Transcoding (GSM 06.10 version 5.1.1)". Applications which use this media type: Voice messaging applications Additional information: Magic number(s): ? File extension(s): .gsm Macintosh File Type Code(s): 'gsm ' Person & email address to contact for further information: Laile L. Di Silvestro lailed@microsoft.com Greg Baribault gregbari@microsoft.com Intended usage: COMMON Author/Change controller: Laile L. Di Silvestro Greg Baribault Di Silvestro, Hedberg, Baribault Expires 10/1/99 [Page 5] Internet Draft audio/ms-gsm 4/1/99 5. Authors' Addresses Laile L. Di Silvestro Microsoft Corporation One Microsoft Way Redmond, WA 98052 lailed@microsoft.com Erik Hedberg Microsoft Corporation One Microsoft Way Redmond, WA 98052 erikhe@microsoft.com Greg Baribault Microsoft Corporation One Microsoft Way Redmond, WA 98052 gregbari@microsoft.com 6. References [GSM] ETS 300 961 (May 1998), "Digital cellular telecommunications system (Phase 2+); Full rate speech; Transcoding (GSM 06.10 version 5.1.1)". [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. [VPIM3] Vaudreuil, Greg, "Voice Profile for Internet Mail, Version 2", Work In Progress, , December 1998. [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Di Silvestro, Hedberg, Baribault Expires 10/1/99 [Page 6] Internet Draft audio/ms-gsm 4/1/99 7. Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Microsoft hereby grants to the IETF, a perpetual, nonexclusive, non-sublicensable, non assignable, royalty-free, world-wide right and license under any Microsoft copyrights in this contribution to copy, publish and distribute the contribution, as well as a right and license of the same scope to any derivative works prepared by the IETF and based on, or incorporating all or part of the contribution. Microsoft further agrees that, upon adoption of this contribution as an Internet Standard, Microsoft will grant to any party a royalty-free license on other reasonable and non-discriminatory terms under applicable Microsoft intellectual property rights to implement and use the technology proposed in this contribution for the purpose of supporting the Internet Standard . Microsoft expressly reserves all other rights it may have in the material and subject matter of this contribution. Microsoft expressly disclaims any and all warranties regarding this contribution including any warranty that (a) this contribution does not violate the rights of others, (b) the owners, if any, of other rights in this contribution have been informed of the rights and permissions granted to IETF herein, and (c) any required authorizations from such owners have been obtained. This document and the information contained herein is provided on an "AS IS" basis and MICROSOFT 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. IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. Di Silvestro, Hedberg, Baribault Expires 10/1/99 [Page 7]