Network Working Group J. Salsman Request for Comments: 2586 H. Alvestrand Category: Informational UNINETT May 1999 The Audio/L16 MIME content type Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. RFC 1867 file uploading) which use MIME typing, higher standards are required. This type repairs that lack by registering a very simple MIME type that allows higher rate, linear-encoded audio with multiple channels. This is an IESG approved MIME type, and its definition is therefore published as an RFC.
Please note that there are many other Audio types described in RFC 1890  which IANA may wish to formally register; this one, of all of them, seems to be most immediately needed. This document may also serve as a template for further registrations of these audio types. RFC 1890 section 4.4.8 for use with RTP transport. L16 denotes uncompressed audio data, using 16-bit signed representation in twos- complement notation and network byte order. (From section 4.4.8 of RFC 1890) It may be parametrized by varying the sample rate and the number of channels; the parameters are given on the MIME type header. In order to promote interoperability, only a few rate values are standardized here. Other values may NOT be used except by bilateral agreement. If multiple audio channels are used, channels are numbered left-to- right, starting at one. Samples are put into the data stream from each channel in succession; information from lower-numbered channels precedes that from higher-numbered channels. For more than two channels, the convention followed by the AIFF-C audio interchange format should be followed , using the following notation: l left r right c center S surround F front R rear channels description channel 1 2 3 4 5 6 ___________________________________________________________ 2 stereo l r 3 l r c 4 quadrophonic Fl Fr Rl Rr 4 l c r S 5 Fl Fr Fc Sl Sr 6 l lc c r rc S (From RFC 1890 section 4.1)
It is expected that many audio and speech applications will use this type. Already the most popular platforms provide this type with the rate=11025 parameter referred to as "radio quality speech." Author/Change controller James Salsman RFC 1890 permits an application to choose to play a single channel from a multichannel tranmission; an attacker who knows that two different users will pick different channels could concievably construct some confusing messages; this, however, is ridiculous. This type is perfect for hiding data using steganography.  Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.