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
<draft-ema-vpim-msgsm-00.txt>
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, <draft-ema-VPIMv3-
00.txt>, 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]