diff options
Diffstat (limited to 'doc/rfc/rfc3190.txt')
| -rw-r--r-- | doc/rfc/rfc3190.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3190.txt b/doc/rfc/rfc3190.txt new file mode 100644 index 0000000..628d008 --- /dev/null +++ b/doc/rfc/rfc3190.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group K. Kobayashi +Request for Comments: 3190 Communication Research Laboratory +Category: Standards Track A. Ogawa + Keio University + S. Casner + Packet Design + C. Bormann + Universitaet Bremen TZI + January 2002 + + + RTP Payload Format for + 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio + +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 (2002). All Rights Reserved. + +Abstract + + This document specifies a packetization scheme for encapsulating + 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams + using the Real-time Transport Protocol (RTP). This document also + specifies the format of a Session Description Protocol (SDP) + parameter to indicate when audio data is preemphasized before + sampling. The parameter may be used with other audio payload + formats, in particular L16 (16-bit linear). + +1. Introduction + + This document describes the sampling of audio data in 12-bit + nonlinear, 20-bit linear, and 24-bit linear encodings, and specifies + the encapsulation of the audio data into the Real-time Transport + Protocol (RTP), version 2 [1,2]. DAT (digital audio tape) and DV + (digital video) devices [3,4] use these audio encodings in addition + to 16-bit linear encoding. The packetization scheme for 16-bit + linear audio (L16) is already specified [2,5]. This document + specifies the packetization scheme for the other encodings following + that for L16; in particular, when used with the RTP profile [2], + these payload formats follow the encoding-independent rules for + + + +Kobayashi, et al. Standards Track [Page 1] + +RFC 3190 RTP Payload Format January 2002 + + + sample ordering and channel interleaving specified in [2] plus + extensions specified here. This document also specifies out-of-band + negotiation methods for the extended channel interleaving rules and + for use when an analog preemphasis technique is applied to the audio + data. + +1.1 Terminology + + 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 RFC 2119 [6] + +2. The need for RTP encapsulation of 12-, 20- and 24-bit audio + + Many high-quality digital audio and visual systems, such as DAT and + DV, adopt sample-based audio encodings. Different audio formats are + used in various situations. To transport the audio data using RTP, + an encapsulation needs to be defined for each specific format. Only + 16-bit linear audio encapsulation (L16) has thus far been defined. + Other encoding formats have already appeared, such as the 12-bit + nonlinear, 20-bit linear and 24-bit linear encodings used in the DAT + and DV video world. This specification defines the RTP payload + encapsulation format in order to use the new encodings in the RTP + environment. + +3. 12-bit nonlinear audio encapsulation + + IEC 61119 [3] specifies the 12-bit nonlinear audio format in DAT and + DV, called LP (Long Play) audio. It would be easy to convert 12-bit + nonlinear audio into 16-bit linear form at the RTP sender and + transmit it using the L16 audio format already defined. However, + this would consume 33% more network bandwidth than necessary. This + payload format is specified as a more efficient alternative. + + The 12-bit nonlinear encoding is the same as for 16-bit linear audio + except for the packing of each sampled data element. Each sample of + 12-bit nonlinear audio is derived from a single sample of 16-bit + linear audio by a nonlinear compression. Table 1 shows the details + of the conversion from 16 to 12 bits. The result is a 12-bit signed + value ranging from -2048 to 2047 and it is represented in two's + complement notation. The 12-bit samples are packed contiguously into + payload octets starting with the most significant bit. When the + payload contains an odd number of samples, the four LSBs of the last + octet are unused. Parameters other than quantization, e.g., sampling + frequency and audio channel assignment, are the same as in the L16 + payload format. In particular, samples are packed into the packet in + time sequence beginning with the oldest sample. + + + + +Kobayashi, et al. Standards Track [Page 2] + +RFC 3190 RTP Payload Format January 2002 + + + ------------------------------------------------------------ + 32,767 (7FFFh) Y = INT(X/64) + (600h) 2,047 (7FFh) + 16,384 (4000h) 1,792 (700h) + ------------------------------------------------------------ + 16,383 (3FFFh) Y = INT(X/32) + (500h) 1,791 (6FFh) + 8,192 (2000h) 1,536 (600h) + ------------------------------------------------------------ + 8,191 (1FFFh) Y = INT(X/16) + (400h) 1,535 (5FFh) + 4,096 (1000h) 1,280 (500h) + ------------------------------------------------------------ + 4,095 (0FFFh) Y = INT(X/8) + (300h) 1,279 (4FFh) + 2,048 (0800h) 1,024 (400h) + ------------------------------------------------------------ + 2,047 (07FFh) Y = INT(X/4) + (200h) 1,023 (3FFh) + 1,024 (0400h) 768 (300h) + ------------------------------------------------------------ + 1,023 (03FFh) Y = INT(X/2) + (100h) 767 (2FFh) + 512 (0200h) 512 (200h) + ------------------------------------------------------------ + 511 (01FFh) Y = X 511 (1FFh) + 0 (0000h) 0 (000h) + ------------------------------------------------------------ + -1 (FFFFh) Y = X -1 (FFFh) + -512 (FE00h) -512 (E00h) + ------------------------------------------------------------ + -513 (FFFFh) Y = INT((X + 1)/2) - (101h) -513 (DFFh) + -1,024 (FE00h) -768 (D00h) + ------------------------------------------------------------ + -1,025 (FBFFh) Y = INT((X + 1)/4) - (201h) -769 (CFFh) + -2,048 (F800h) -1,024 (C00h) + ------------------------------------------------------------ + -2,049 (F7FFh) Y = INT((X + 1)/8) - (301h) -1,025 (BFFh) + -4,096 (F000h) -1,280 (B00h) + ------------------------------------------------------------ + -4,097 (EFFFh) Y = INT((X + 1)/16) - (401h) -1,281 (AFFh) + -8,192 (E000h) -1,536 (A00h) + ------------------------------------------------------------ + -8,193 (DFFFh) Y = INT((X + 1)/32) - (501h) -1,537 (9FFh) + -16,384 (C000h) -1,792 (900h) + ------------------------------------------------------------ + -16,385 (BFFFh) Y = INT((X + 1)/64) - (601h) -1,793 (8FFh) + -32,768 (8000h) -2,048 (800h) + ------------------------------------------------------------ + + Table 1. Conversion from 16-bit linear values (X) to 12-bit + nonlinear values (Y) [3] + + + + + +Kobayashi, et al. Standards Track [Page 3] + +RFC 3190 RTP Payload Format January 2002 + + + When conveying encoding information in an SDP [7] session + description, the 12-bit nonlinear audio payload format specified here + is given the encoding name "DAT12". Thus, the media format + representation might be: + + m=audio 49230 RTP/AVP 97 98 + a=rtpmap:97 DAT12/32000/2 + a=rtpmap:98 L16/48000/2 + +4. 20- and 24-bit linear audio encapsulation + + The 20- and 24-bit linear audio encodings are simply an extension of + the L16 linear audio encoding [2]. The 20- or 24-bit uncompressed + audio data samples are represented as signed values in two's + complement notation. The samples are packed contiguously into + payload octets starting with the most significant bit. For the + 20-bit encoding, when the payload contains an odd number of samples, + the four LSBs of the last octet are unused. Samples are packed into + the packet in time sequence beginning with the oldest sample. + + When conveying encoding information in an SDP session description, + the 20- and 24-bit linear audio payload formats specified here are + given the encoding names "L20" and "L24", respectively. An example + SDP audio media description would be: + + m=audio 49230 RTP/AVP 99 100 + a=rtpmap:99 L20/48000/2 + a=rtpmap:100 L24/48000 + +5. Preemphasized audio data + + In order to improve the higher frequency characteristics of audio + signals, analog preemphasis is often applied to the signal before + quantization. If analog preemphasis was applied before the payload + data was sampled, the type of the preemphasis SHOULD be conveyed with + out-of-band signaling. An "emphasis" parameter is defined for this + purpose and may be conveyed either as a MIME optional parameter or + using the SDP format-specific attribute (a=fmtp line) as below: + + a=fmtp:<payload type> emphasis=<emphasis type> + + Only one <emphasis type> value is defined for the parameter at this + point: + + 50-15 <50/15 microsecond CD-type emphasis> + + + + + + +Kobayashi, et al. Standards Track [Page 4] + +RFC 3190 RTP Payload Format January 2002 + + + The emphasis attribute MUST NOT be included in the SDP record if + preemphasis was not applied. This rule allows the emphasis attribute + to be used with other audio formats, in particular L16 [2], while + retaining backward compatibility with existing implementations so + long as preemphasis is not applied. If an existing application that + does not implement preemphasis accepts a session description with an + emphasis attribute but ignores that attribute, the only penalty is + that the sound will be too "bright" when receiving or "dull" when + sending. + + A sample SDP record showing preemphasis applied only to payload type + 99 might be as follows: + + m=audio 49230 RTP/AVP 99 100 + a=rtpmap:99 L20/48000/2 + a=fmtp:99 emphasis=50-15 + a=rtpmap:100 L24/48000 + +6. Translation of DV audio error code + + The DV video specification IEC 61834-4 [4] defines the negative full- + scale audio sample value to be an audio error code indicating that no + valid audio sample is available for that sample period. Such an + error might occur due to a failure while reading audio data from + magnetic tape. The audio error code values for each of the DV audio + encodings are (in hexadecimal): + + 12-bit nonlinear: 800h + 16-bit linear: 8000h + 20-bit linear: 80000h + + For the payload formats defined in this document, as well as for the + L16 payload format defined in [2], no such error code is defined. + That is, all possible sample values are valid. When an RTP sender + accepts audio samples from a DV video system and encapsulates those + samples according to one of these payload formats, the RTP sender + SHOULD perform some error concealment algorithm which may depend upon + whether a single sample error or multiple sample errors have + occurred. The error concealment algorithm is not specified here and + is left to the implementation. The RTP sender MAY treat the error + code as if it were a valid audio sample, but this is likely to cause + undesirable audio output. + + Conversely, an RTP receiver that accepts audio packets in one of + these payload formats and delivers the audio samples to a DV video + system SHOULD translate the audio samples that would be interpreted + as error codes into the next smaller negative audio value. Such + audio samples may be present because the audio packets may have come + + + +Kobayashi, et al. Standards Track [Page 5] + +RFC 3190 RTP Payload Format January 2002 + + + from a source other than a DV video system. The DV video + specification [4] gives the following translations for the defined + audio encodings: + + 12-bit nonlinear: 800h -> 801h + 16-bit linear: 8000h -> 8001h + 20-bit linear: 80000h - 8000Fh -> 80010h + + For the 20-bit linear encoding, note that multiple audio sample + values are translated in order to allow a 16-bit system to play 20- + bit audio data by ignoring the least significant four bits. Note + also that no translation is specified for 24-bit linear audio because + that encoding is not included in the DV video specification. + +7. Channel interleaving and non-AIFF-C audio channel convention + + When multiple channels of audio, such as in a stereo program, are + multiplexed into a single RTP stream, the audio samples from each + channel are interleaved according to the rules specified in [2] to be + consistent with the L16 payload format. That is, samples from + different channels taken at the same sampling instant are packed into + consecutive octets. For example, for a two-channel encoding, the + sample sequence is (left channel, first sample), (right channel, + first sample), (left channel, second sample), (right channel, second + sample). Samples for all channels belonging to a single sampling + instant MUST be contained in the same packet. + + This sample order differs from the packing of samples into blocks in + a native DV audio stream. Therefore, applications transmitting DV + audio using the payload formats defined in this document MUST + reshuffle the samples into the order specified here. This + requirement is intended to enable interworking between DV systems and + other digital audio systems. Applications choosing to send bundled + DV audio/video streams using the native DV block structure may use + the payload format defined in [8] instead. + + Most of the existing RTP audio payload formats follow the AIFF-C + convention for channel ordering as specified in [2] when sending more + than two audio channels within a single RTP stream. However, this + convention does not cover some applications. For example, some DV + audio formats define a "woofer" channel, but AIFF-C does not include + this frequency-dependent channel. Thus, it is necessary to specify + the audio channel allocation information explicitly when the contents + of the audio stream are beyond the scope of AIFF-C. + + For DV audio streams of 4 or more channels, the channel order MUST be + specified out-of-band. This applies both to the payload formats + defined in this document and to the L16 payload format. A "channel- + + + +Kobayashi, et al. Standards Track [Page 6] + +RFC 3190 RTP Payload Format January 2002 + + + order" parameter is defined here for this purpose and may be conveyed + either as a MIME optional parameter or with the SDP a=fmtp attribute + using the following syntax: + + a=fmtp:<payload type> channel-order=<convention>.<order> + + The first component of the value, <convention>, specifies the type of + channel assignment convention used. This allows for conventions + other than AIFF-C and DV to be defined in the future. This document + defines only one convention for use in the channel-order parameter: + + DV + + The second component of the value, <order>, indicates the arrangement + of channels within the stream. The DV video specification [4] + defines the types of audio channels that may be present and in what + order. The symbols used to denote the channel types are reproduced + in the Appendix at the end of this document. For the DV convention, + the following values, which were formed from the concatenation of the + individual channel symbols in the allowed channel orders, are defined + for the <order> component: + + 4 channels: LRLsRs, LRCS, LRCWo + 5 channels: LRLsRsC + 6 channels: LRLsRsCS, LmixRmixTWoQ1Q2 + 8 channels: LRCWoLsRsLmixRmix, LRCWoLs1Rs1Ls2Rs2, LRCWoLsRsLcRc + + The <convention> and <order> symbols are case-insensitive, but are + shown here in mixed case to make the individual channel symbols more + apparent. These concatenated symbols were deliberately constructed + without separators to make clear the fact that the channels MUST NOT + be assembled in other, arbitrary orders. + + For interworking with DV video systems, some of the audio encodings + are defined only for a subset of the channel combinations listed + above. The DV video specification lists the channel combinations + that are allowed for each encoding. + + The channel-order parameter MUST be consistent with the number of + channels specified in the MIME optional parameter "channels" or in + the a=rtpmap attribute of SDP. For RTP audio streams of 1, 2 or 3 + channels, the AIFF-C channel order is used and is implicit in the + number of audio channels specified. To allow backward compatibility, + the channel-order parameter MUST NOT be included in this case. + + Note that for the DV convention with 5 channels only one channel + order is allowed, but for consistency the channel-order parameter + MUST be included nonetheless. + + + +Kobayashi, et al. Standards Track [Page 7] + +RFC 3190 RTP Payload Format January 2002 + + + An example of an SDP session description using the channel-order + parameter is: + + v=0 + o=ikob 2890844526 2890842807 IN IP4 126.16.64.4 + s=POI (Audio only) + i=A Seminar on making Presentations on the Internet + u=http://www.koganei.wide.ad.jp/~ikob/POI/index.html + e=ikob@koganei.wide.ad.jp (Katsushi Kobayashi) + c=IN IP4 224.2.17.12/127 + t=2873397496 2873404696 + m=audio 49170 RTP/AVP 112 113 + a=rtpmap:112 L16/48000/2 + a=rtpmap:113 DAT12/32000/4 + a=fmtp:113 emphasis=50-15; channel-order=DV.LRCWO + + This session description shows the audio medium being transmitted in + two formats, L16 and DAT12, using payload type numbers 112 and 113, + respectively. For the L16 format, the audio data contains 2-channel + stereo following the implicit, default AIFF-C convention for left + channel first and right channel second. For the DAT12 format, the + audio data contains 4 channels following the DV audio convention for + the channels left, right, center, and woofer. + + This example also shows how multiple MIME optional parameters + ("emphasis" and "channel-order") for these payload formats are mapped + to a single a=fmtp attribute as a semicolon separated list of + parameter=value pairs. + + The channel-order parameter described here provides a generic out-of- + band mechanism to define alternatives to the AIFF-C channel order. + However, if multi-channel audio data could be sent following the + AIFF-C channel convention after simple processing, such as a data + shuffling on the sender side, the alternative channel order SHOULD + NOT be defined and instead the AIFF-C order SHOULD be employed to + maximize interoperability. + + Moreover, multiple channels of audio data should only be multiplexed + within a single RTP stream when all of the audio channels are + intended to be reproduced together, such as the left and right + channels in a stereo program. Independent audio channels, such as + multiple language translations, SHOULD be sent in separate RTP + sessions. This reduces bandwidth requirements by allowing receivers + to tune in to only those channels which are desired. + + + + + + + +Kobayashi, et al. Standards Track [Page 8] + +RFC 3190 RTP Payload Format January 2002 + + +8. MIME registration + + This document defines some new RTP payload format names which are + also registered as MIME subtypes: DAT12, L20 and L24. The + registration forms for these MIME subtypes are provided in the next + sections. + +8.1 MIME registration form for audio/DAT12 + + MIME media type name: audio + + MIME subtype name: DAT12 + + Required parameters: + rate: number of samples per second -- RECOMMENDED values for rate + are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 + samples per second. Other values are permissible. + + Optional parameters: + channels: how many audio streams are interleaved -- defaults to 1; + stereo would be 2, etc. Interleaving takes place between + individual 12-bit samples. + + emphasis: analog preemphasis applied to the data before + quantization. The only emphasis value defined here is + emphasis=50-15 to indicate 50/15 microsecond preemphasis. This + parameter MUST be omitted if no analog preemphasis was applied. + + channel-order: specifies the sample interleaving order for + multiple-channel audio streams (see RFC 3190 Section 7). + Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, + DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, + DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. + For interoperation with DV video systems, only a subset of + these channel combinations is specified for use with 12-bit + nonlinear encoding in the DV video specification [4]; that + subset is all of the above except DV.LmixRmixTWoQ1Q2. This + parameter MUST be omitted when the AIFF-C channel order + convention is in use. + + Encoding considerations: + DAT12 audio can be transmitted with RTP as specified in RFC 3190. + + Security considerations: See Section 9. + + Interoperability considerations: NONE + + + + + +Kobayashi, et al. Standards Track [Page 9] + +RFC 3190 RTP Payload Format January 2002 + + + Published specification: + IEC 61119 Standard [4] and RFC 3190. + + Applications which use this media type: + Audio communication. + + Additional information: + Magic number(s): None + File extension(s): None + Macintosh File Type Code(s): None + + Person & email address to contact for further information: + Katsushi Kobayashi + e-mail: ikob@koganei.wide.ad.jp + + Intended usage: COMMON + + Author/Change controller: + Katsushi Kobayashi + e-mail: ikob@koganei.wide.ad.jp + +8.2 MIME registration form for audio/L20 + + MIME media type name: audio + + MIME subtype name: L20 + + Required parameters: + rate: number of samples per second -- RECOMMENDED values for rate + are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 + samples per second. Other values are permissible. + + Optional parameters: + channels: how many audio streams are interleaved -- defaults to 1; + stereo would be 2, etc. Interleaving takes place between + individual 20-bit samples. + + emphasis: analog preemphasis applied to the data before + quantization. The only emphasis value defined here is + emphasis=50-15 to indicate 50/15 microsecond preemphasis. This + parameter MUST be omitted if no analog preemphasis was applied. + + channel-order: specifies the sample interleaving order for + multiple-channel audio streams (see RFC 3190 Section 7). + Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, + DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, + DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. + For interoperation with DV video systems, none of these channel + + + +Kobayashi, et al. Standards Track [Page 10] + +RFC 3190 RTP Payload Format January 2002 + + + combinations is specified for use with 20-bit linear encoding + in the DV video specification [4]; only mono and stereo are + allowed. This parameter MUST be omitted when the AIFF-C + channel order convention is in use. + + Encoding considerations: + L20 audio can be transmitted with RTP as specified in RFC 3190. + + Security considerations: See Section 9. + + Interoperability considerations: NONE + + Published specification: + RFC 3190. + + Applications which use this media type: + Audio communication. + + Additional information: + Magic number(s): None + File extension(s): None + Macintosh File Type Code(s): None + + Person & email address to contact for further information: + Katsushi Kobayashi + e-mail: ikob@koganei.wide.ad.jp + + Intended usage: COMMON + + Author/Change controller: + Katsushi Kobayashi + e-mail: ikob@koganei.wide.ad.jp + +8.3 MIME registration form for audio/L24 + + MIME media type name: audio + + MIME subtype name: L24 + + Required parameters: + rate: number of samples per second -- RECOMMENDED values for rate + are 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 + samples per second. Other values are permissible. + + Optional parameters: + channels: how many audio streams are interleaved -- defaults to 1; + stereo would be 2, etc. Interleaving takes place between + individual 24-bit samples. + + + +Kobayashi, et al. Standards Track [Page 11] + +RFC 3190 RTP Payload Format January 2002 + + + emphasis: analog preemphasis applied to the data before + quantization. The only emphasis value defined here is + emphasis=50-15 to indicate 50/15 microsecond preemphasis. This + parameter MUST be omitted if no analog preemphasis was applied. + + channel-order: specifies the sample interleaving order for + multiple-channel audio streams (see Section 7). Permissible + values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, + DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, + DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. This parameter MUST be + omitted when the AIFF-C channel order convention is in use. + + Encoding considerations: + L24 audio can be transmitted with RTP as specified in RFC 3190. + + Security considerations: See Section 9. + + Interoperability considerations: NONE + + Published specification: + RFC 3190. + + Applications which use this media type: + Audio communication. + + Additional information: + Magic number(s): None + File extension(s): None + Macintosh File Type Code(s): None + + Person & email address to contact for further information: + Katsushi Kobayashi + e-mail: ikob@koganei.wide.ad.jp + + Intended usage: COMMON + + Author/Change controller: + Katsushi Kobayashi + e-mail: ikob@koganei.wide.ad.jp + + + + + + + + + + + + +Kobayashi, et al. Standards Track [Page 12] + +RFC 3190 RTP Payload Format January 2002 + + +9. Security Considerations + + RTP packets using the payload format defined in this specification + are subject to the security considerations discussed in the RTP + specification [1], and any appropriate RTP profile [2]. This implies + that confidentiality of the media streams is achieved by encryption. + Because the data compression used along with this payload format is + applied end-to-end, encryption may be performed after compression so + there is no conflict between the two operations. + + A potential denial-of-service threat exists for data encodings using + compression techniques that have non-uniform receiver-end + computational load. The attacker can inject pathological datagrams + into the stream which are complex to decode and cause the receiver to + be overloaded. However, this encoding does not exhibit any + significant non-uniformity. + + As with any IP-based protocol, in some circumstances a receiver may + be overloaded simply by the receipt of too many packets, either + desired or undesired. Network-layer authentication may be used to + discard packets from undesired sources, but the processing cost of + the authentication itself may be too high. In a multicast + environment, pruning of specific sources may be implemented in future + versions of IGMP [9] and in multicast routing protocols to allow a + receiver to select which sources are allowed to reach it. + +10. IANA Considerations + + This document defines two new MIME subtype-specific optional + parameters "emphasis" and "channel-order", which are specified with + the sets of permissible values for those parameters in Sections 5 and + 7, respectively. Section 8 includes registrations for three new MIME + subtypes that use those optional parameters. These registrations + define the subset of the optional parameter values allowed for each + subtype. It is expected that the number of additional values that + will need to be defined for these optional parameters is small. + Therefore, anyone wishing to define new values is required to produce + a revision of this document to be vetted through the normal Internet + Standards process. + + + + + + + + + + + + +Kobayashi, et al. Standards Track [Page 13] + +RFC 3190 RTP Payload Format January 2002 + + +11. References + + [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: + A Transport Protocol for real-time applications," RFC 1889, + January 1996. + + [2] H. Schulzrinne, "RTP profile for audio and video conferences with + minimal control", RFC 1890, January 1996. + + [3] IEC 61119, Digital audio tape cassette system (DAT), November + 1992. + + [4] IEC 61834, Helical-scan digital video cassette recording system + using 6,35 mm magnetic tape for consumer use (525-60, 625-50, + 1125-60 and 1250-50 systems), August 1998. + + [5] Salsman, J., "The Audio/L16 MIME content type", RFC 2586, May + 1999. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", + RFC 2327, April 1998. + + [8] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP Payload + Format for DV (IEC 61834) Video", RFC 3189, January 2002. + + [9] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC + 1112, August 1989. + + + + + + + + + + + + + + + + + + + + + +Kobayashi, et al. Standards Track [Page 14] + +RFC 3190 RTP Payload Format January 2002 + + +Appendix + + The DV audio channel symbols are specified in Table 2. These symbols + are taken from the notation used in the DV video specification IEC + 61834-4 [4], chapter 8.1. For the exact meaning of each symbol, the + original DV video specification should be consulted. + + L: Left channel of stereo + R: Right channel of stereo + M: Monaural signal + C: Center channel of 3,4,6 or 8 channel audio + S: Surround channel of 4 channel audio + Ls, Ls1, Ls2: Left surround channel + Rs, Rs1, Rs2: Right surround channel + Lc: Left center channel of 8 channel audio + Rc: Right center channel of 8 channel audio + Wo: Woofer channel + Lmix: L + 0.7071C + 0.7071LS + Rmix: R + 0.7071C + 0.7071RS + T: 0.7071C + Q1: 0.7071LS + 0.7071RS + Q2: 0.7071LS - 0.7071RS + + Table 2. Channel symbols for audio channels in DV video [4] + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kobayashi, et al. Standards Track [Page 15] + +RFC 3190 RTP Payload Format January 2002 + + +Authors' Addresses + + Katsushi Kobayashi + Communication Research Laboratory + 4-2-1 Nukii-kita machi, Koganei + Tokyo 184-8795 JAPAN + + Phone: +81 42 327 6174 + EMail: ikob@koganei.wide.ad.jp + + + Akimichi Ogawa + Keio University + 5322 Endo, Fujisawa + Kanagawa 252 JAPAN + + EMail: akimichi@sfc.wide.ad.jp + + + Stephen L. Casner + Packet Design + 2465 Latham Street + Mountain View, CA 94040 + United States + + Phone: +1 650-943-1843 + EMail: casner@acm.org + + + Carsten Bormann + Universitaet Bremen TZI + Postfach 330440 + D-28334 Bremen, Germany + + Phone: +49 421 218 7024 + Fax: +49 421 218 7000 + EMail: cabo@tzi.org + + + + + + + + + + + + + + +Kobayashi, et al. Standards Track [Page 16] + +RFC 3190 RTP Payload Format January 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kobayashi, et al. Standards Track [Page 17] + |