From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3555.txt | 2523 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2523 insertions(+) create mode 100644 doc/rfc/rfc3555.txt (limited to 'doc/rfc/rfc3555.txt') diff --git a/doc/rfc/rfc3555.txt b/doc/rfc/rfc3555.txt new file mode 100644 index 0000000..0ecb5d3 --- /dev/null +++ b/doc/rfc/rfc3555.txt @@ -0,0 +1,2523 @@ + + + + + + +Network Working Group S. Casner +Request for Comments: 3555 Packet Design +Category: Standards Track P. Hoschka + W3C/INRIA/MIT + July 2003 + + + MIME Type Registration of RTP Payload Formats + +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 (2003). All Rights Reserved. + +Abstract + + This document defines the procedure to register RTP Payload Formats + as audio, video or other MIME subtype names. This is useful in a + text-based format or control protocol to identify the type of an RTP + transmission. This document also registers all the RTP payload + formats defined in the RTP Profile for Audio and Video Conferences as + MIME subtypes. Some of these may also be used for transfer modes + other than RTP. + +Table of Contents + + 1. Introduction .................................................. 2 + 1.1. IANA Considerations ...................................... 2 + 1.2. Terminology .............................................. 3 + 2. Procedure For Registering MIME Types for RTP Payload Types .... 3 + 3. Mapping to SDP Parameters ..................................... 5 + 4. Registrations for "Audio/Video Profile" ....................... 6 + 4.1. Audio Type Registrations ................................. 6 + 4.2. Video Type Registrations ................................. 30 + 5. Security Considerations ....................................... 42 + 6. Normative References .......................................... 43 + 7. Authors' Addresses ............................................ 44 + 8. Full Copyright Statement ...................................... 45 + + + + + + +Casner & Hoschka Standards Track [Page 1] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +1. Introduction + + The MIME registration procedure described in RFC 2048 [1] was + originally designed for transport of multimedia information via + asynchronous Internet mail, but the MIME namespace now provides + identification for other transport modes as well. This document + defines the procedure to register MIME subtype names for use with the + Real-time Transport Protocol (RTP), RFC 3550 [2], to identify RTP + payload formats. + + This document also registers all the RTP payload formats defined in + the RTP Profile for Audio and Video Conferences, RFC 3551 [3], as + MIME subtypes under the "audio" and "video" MIME types. + +1.1. IANA Considerations + + This document registers the following MIME subtypes: + + audio/DVI4 + audio/G722 + audio/G723 + audio/G726-16 + audio/G726-24 + audio/G726-32 + audio/G726-40 + audio/G728 + audio/G729 + audio/G729D + audio/G729E + audio/GSM + audio/GSM-EFR + audio/L8 + audio/L16 + audio/LPC + audio/MPA + audio/PCMA + audio/PCMU + audio/QCELP + audio/RED + audio/VDVI + video/BT656 + video/CelB + video/JPEG + video/H261 + video/H263 + video/H263-1998 + video/H263-2000 + video/MPV + + + +Casner & Hoschka Standards Track [Page 2] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + + video/MP2T + video/MP1S + video/MP2P + video/BMPEG + video/nv + + MIME subtype audio/L16 has already been registered via RFC 2586 for + transports other than RTP. That registration is incorporated here + and augmented with additional information for RTP transport. + +1.2. 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 [4] and + indicate requirement levels for implementations compliant with this + specification. + +2. Procedure For Registering MIME Types for RTP Payload Types + + Registering an RTP payload type as a MIME type follows the same + procedures as described in RFC 2048 and uses the registration + template shown in Section 2.8 of RFC 2048. Some additional + parameters are required to specify how a particular payload format is + transported over RTP: + + Published specification + A description of the encoding and a specification of the + payload format must be provided, usually by reference to an RTP + payload format specification RFC. That RFC may be separate, or + the MIME subtype registration may be incorporated into the + payload format specification RFC. The payload format + specification MUST include the RTP timestamp clock rate (or + multiple rates for audio encodings with multiple sampling + rates). + + A reference to a further description of the data compression + format itself should be provided, if available. + + Required parameters + If the payload format does not have a fixed RTP timestamp clock + rate, then a "rate" parameter is required to specify the RTP + timestamp clock rate. A particular payload format may have + additional required parameters. + + + + + + + +Casner & Hoschka Standards Track [Page 3] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + + Optional parameters + Most audio payload formats can have an optional "channels" + parameter to specify the number of audio channels included in + the transmission. Any payload format, but most likely audio + formats, may also include the optional parameters "ptime", to + specify the recommended length of time in milliseconds + represented by the media in a packet, and/or "maxptime" to + specify the maximum amount of media which can be encapsulated + in each packet, expressed as time in milliseconds. The "ptime" + and "maxptime" parameters are defined in the Session + Description Protocol (SDP) [5]. + + A particular payload format may have additional optional + parameters. + + Encoding considerations + The fact that the type can be transferred via RTP MUST be + noted. + + Depending on whether the type has already been registered for + transfer with a non-RTP protocol (e.g. MIME mail or http) or not, + several different cases can occur: + + a) Not yet registered as a MIME type + + A new registration should be constructed using the MIME + registration template. The registration may specify transfer + via other means in addition to RTP if that is feasible and + desired. The encoding considerations must specify how the type + is transferred via RTP. + + Optional parameters may be defined as needed, and it must be + clearly stated whether to which mode(s) of transfer the + parameters apply. + + b) MIME type exists for a non-RTP protocol + + The encoding considerations of the existing type should be + changed to indicate that the type can also be transferred via + RTP. + + RTP-specific parameters may be added, and it must be clearly + stated that these are only to be used when the media type is + transmitted via RTP transport. + + + + + + + +Casner & Hoschka Standards Track [Page 4] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + + c) Update an existing MIME type for RTP to be used for a non-RTP + protocol + + The encoding considerations of the existing type should be + changed to indicate that the type can also be transferred via a + non-RTP protocol (e.g. SMTP, HTTP). + + Non-RTP-specific parameters can be added, and it must be + clearly stated that these are only to be used when the media + type is transmitted via a non-RTP transport. + +3. Mapping to SDP Parameters + + The representation of a MIME media type is specified in the syntax of + the Content-Type header field in RFC 2045 [6] as follows: + + type "/" subtype *(";" parameter) + + Parameters may be required for a particular type or subtype or they + may be optional. For media types which represent RTP payload + formats, the parameters "rate", "channels", "ptime", and "maxptime" + have general definitions (given above) that may apply across types + and subtypes. The format for a parameter is specified in RFC 2045 as + + attribute "=" value + + where attribute is the parameter name and the permissible values are + specified for each parameter. The value may need to be a quoted + string if it contains any of the special characters listed in RFC + 2045. + + The information carried in the media type string has a specific + mapping to fields in the Session Description Protocol (SDP) [5], + which is commonly used to describe RTP sessions. The mapping is as + follows: + + o The MIME type (e.g., audio) goes in SDP "m=" as the media name. + + o The MIME subtype (payload format) goes in SDP "a=rtpmap" as the + encoding name. + + o The general (possibly optional) parameters "rate" and + "channels" also go in "a=rtpmap" as clock rate and encoding + parameters, respectively. + + o The general (and optional) parameters "ptime" and "maxptime" go + in the SDP "a=ptime" and "a=maxptime" attributes, respectively. + + + + +Casner & Hoschka Standards Track [Page 5] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + + o Any payload-format-specific parameters go in the SDP "a=fmtp" + attribute. The set of allowed parameters is defined by the RFC + that specifies the payload format and MUST NOT be extended by + the MIME subtype registration without a corresponding revision + of the payload format specification. The format and syntax of + these parameters may also be defined by the payload format + specification, but it is suggested that the parameters be + copied directly from the MIME media type string as a semicolon + separated list of parameter=value pairs. For payload formats + that specify some other syntax for the fmtp parameters, the + registration of that payload format as a MIME subtype must + specify what the parameters are in MIME format and how to map + them to the SDP "a=fmtp" attribute. See Section 4.1.21 for an + example. + + An example mapping is as follows: + + audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15 + + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 L16/48000/2 + a=fmtp:97 emphasis=50-15 + a=ptime:5 + + Note that the payload format (encoding) names defined in the RTP + Profile are commonly shown in upper case. MIME subtypes are commonly + shown in lower case. These names are case-insensitive in both + places. Similarly, parameter names are case-insensitive both in MIME + types and in the default mapping to the SDP a=fmtp attribute. + +4. Registrations for "Audio/Video Profile" + + In the following sections, all RTP payload formats described in the + RTP Profile for Audio and Video Conferences, RFC 3551 [3], are + registered as MIME subtypes. + +4.1. Audio Type Registrations + + The following sections register all of the RTP audio payload types + defined in RFC 3551 as MIME types. + + For most audio payload formats, the RTP timestamp clock rate is equal + to the sampling rate. Some payload formats operate only at one fixed + sampling rate, while others are adjustable. + + + + + + + +Casner & Hoschka Standards Track [Page 6] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.1. Registration of MIME media type audio/DVI4 + + MIME media type name: audio + + MIME subtype name: DVI4 + + Required parameters: rate + The RTP timestamp clock rate, which is equal to the sampling + rate. The typical rate is 8000, but other rates may be + specified. + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 7] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.2. Registration of MIME media type audio/G722 + + MIME media type name: audio + + MIME subtype name: G722 + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 8] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.3. Registration of MIME media type audio/G723 + + MIME media type name: audio + + MIME subtype name: G723 + + Required parameters: None + + Optional parameters: + ptime, maxptime + + bitrate: the data rate in kb/s used or preferred for the audio + bit stream, with permissible values 5.3 or 6.3. If + unspecified, the bitrate may change from frame to frame as + indicated inband. + + annexa: indicates that Annex A, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + +Casner & Hoschka Standards Track [Page 9] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.4. Registration of MIME media type audio/G726-16 + + MIME media type name: audio + + MIME subtype name: G726-16 + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 10] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.5. Registration of MIME media type audio/G726-24 + + MIME media type name: audio + + MIME subtype name: G726-24 + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 11] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.6. Registration of MIME media type audio/G726-32 + + MIME media type name: audio + + MIME subtype name: G726-32 + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 12] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.7. Registration of MIME media type audio/G726-40 + + MIME media type name: audio + + MIME subtype name: G726-40 + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 13] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.8. Registration of MIME media type audio/G728 + + MIME media type name: audio + + MIME subtype name: G728 + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 14] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.9. Registration of MIME media type audio/G729 + + MIME media type name: audio + + MIME subtype name: G729 + + Required parameters: None + + Optional parameters: + ptime, maxptime + + annexb: indicates that Annex B, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 15] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.10. Registration of MIME media type audio/G729D + + MIME media type name: audio + + MIME subtype name: G729D + + Required parameters: None + + Optional parameters: + ptime, maxptime + + annexb: indicates that Annex B, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 16] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.11. Registration of MIME media type audio/G729E + + MIME media type name: audio + + MIME subtype name: G729E + + Required parameters: None + + Optional parameters: + ptime, maxptime + + annexb: indicates that Annex B, voice activity detection, is + used or preferred. Permissible values are "yes" and "no" + (without the quotes); "yes" is implied if this parameter is + omitted. + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 17] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.12. Registration of MIME media type audio/GSM + + MIME media type name: audio + + MIME subtype name: GSM + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 18] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.13. Registration of MIME media type audio/GSM-EFR + + MIME media type name: audio + + MIME subtype name: GSM-EFR + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 19] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.14. Registration of MIME media type audio/L8 + + MIME media type name: audio + + MIME subtype name: L8 + + Required parameters: rate, the RTP timestamp clock rate + + Optional parameters: channels, ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 20] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.15. Registration of MIME media type audio/L16 + + MIME subtype audio/L16 has already been registered via RFC 2586 for + transports other than RTP. That registration is incorporated here + and augmented with additional information for RTP transport. + + MIME media type name: audio + + MIME subtype name: L16 + + Required parameters + rate: number of samples per second -- For non-RTP transport, + the permissible values for rate are 8000, 11025, 16000, 22050, + 24000, 32000, 44100, and 48000 samples per second. For RTP + transport, other values are permissible but the aforementioned + values are RECOMMENDED. For RTP, the rate parameter indicates + the RTP timestamp clock rate, which is equal to the sample + rate. + + Optional parameters + channels: how many audio streams are interleaved -- defaults + to 1; stereo would be 2, etc. Interleaving takes place + between individual two-byte samples. + + emphasis: analog preemphasis applied to the signal before + quantization. The only emphasis value defined here is + emphasis=50-15 to indicate the 50/15 microsecond preemphasis + used with Compact Disks. This parameter MUST be omitted if no + analog preemphasis was applied. + + channel-order: specifies the sample interleaving order for + multiple-channel audio streams (see [7] 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 20-bit + linear encoding in the DV video specification [4]; those are + DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ1Q2. This parameter MUST + be omitted when the AIFF-C channel order convention (see RFC + 3551) is in use. + + For RTP, ptime: RECOMMENDED duration of each packet in + milliseconds. + + For RTP, maxptime: maximum duration of each packet in + milliseconds. + + + + +Casner & Hoschka Standards Track [Page 21] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + + Encoding considerations + Audio data is binary data, and must be encoded for non-binary + transport; the Base64 encoding is suitable for Email. Note + that audio data does not compress easily using lossless + compression. + + This type is also defined for transfer via RTP [RFC 3550]. + + Security considerations + Audio data is believed to offer no security risks. + See Section 5 of RFC 3555. + + Interoperability considerations + This type is compatible with the encoding used in the WAV + (Microsoft Windows RIFF) and Apple AIFF union types, and with + the public domain "sox" and "rateconv" programs. + + Published specification + RFC 2586 for non-RTP transports, RFC 3551 for RTP + + Applications which use this media + The public domain "sox" and "rateconv" programs accept this + type. + + 1. Magic number(s) : None + 2. File extension(s) : WAV L16 + 3. Macintosh file type code : AIFF + + Person to contact for further information + 1. Name : James Salsman + 2. E-mail : jps-L16@bovik.org + + Intended usage + Common + + 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 for non-RTP transports. + Stephen Casner for RTP transport. + + + + + + + + +Casner & Hoschka Standards Track [Page 22] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.16. Registration of MIME media type audio/LPC + + MIME media type name: audio + + MIME subtype name: LPC + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 23] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.17. Registration of MIME media type audio/MPA + + MIME media type name: audio + + MIME subtype name: MPA (MPEG audio) + + Required parameters: None + + Optional parameters: + layer: which layer of MPEG audio encoding; permissible values + are 1, 2, 3. + + samplerate: the rate at which audio is sampled. MPEG-1 audio + supports sampling rates of 32, 44.1, and 48 kHz; MPEG-2 + supports sampling rates of 16, 22.05 and 24 kHz. This parameter + is separate from the RTP timestamp clock rate which is always + 90000 Hz for MPA. + + mode: permissible values are "stereo", "joint_stereo", + "single_channel", "dual_channel". The "channels" parameter + does not apply to MPA. It is undefined to put a number of + channels in the SDP rtpmap attribute for MPA. + + bitrate: the data rate for the audio bit stream. + + ptime: RECOMMENDED duration of each packet in milliseconds. + + maxptime: maximum duration of each packet in milliseconds. + + Parameters which are omitted are left to the encoder to choose + based on the session bandwidth, configuration information, or + other constraints. The selected layer as well as the sampling + rate and mode are indicated in the payload so receivers can + process the data without these parameters being specified + externally. + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + + + +Casner & Hoschka Standards Track [Page 24] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + +4.1.18. Registration of MIME media type audio/PCMA + + MIME media type name: audio + + MIME subtype name: PCMA + + Required parameters: rate + The RTP timestamp clock rate, which is equal to the sampling + rate. The typical rate is 8000, but other rates may be + specified. + + Optional parameters: channels, ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + +Casner & Hoschka Standards Track [Page 25] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.19. Registration of MIME media type audio/PCMU + + MIME media type name: audio + + MIME subtype name: PCMU + + Required parameters: rate + The RTP timestamp clock rate, which is equal to the sampling + rate. The typical rate is 8000, but other rates may be + specified. + + Optional parameters: channels, ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 26] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.20. Registration of MIME media type audio/QCELP + + MIME media type name: audio + + MIME subtype name: QCELP + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2658 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 27] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.1.21. Registration of MIME media type audio/RED + + MIME media type name: audio + + MIME subtype name: RED + + Required parameters: + pt: a comma-separated list of RTP payload types. Because + comma is a special character, the list must be a quoted-string + (enclosed in double quotes). For static payload types, each + list element is simply the type number. For dynamic payload + types, each list element is a mapping of the dynamic payload + type number to an embedded MIME content-type specification for + the payload format corresponding to the dynamic payload type. + The format of the mapping is: + + dynamic-payload-type "=" content-type + + If the content-type string includes a comma, then the + content-type string MUST be a quoted-string. If the content- + type string does not include a comma, it MAY still be quoted. + Since it is part of the list which must itself be a quoted- + string, that means the quotation marks MUST be quoted with + backslash quoting as specified in RFC 2045. If the content- + type string itself contains a quoted-string, then the + requirement for backslash quoting is recursively applied. To + specify the audio/RED payload format in SDP, the pt parameter + is mapped to an a=fmtp attribute by eliminating the parameter + name (pt) and changing the commas to slashes. For example, + 'pt="0,5"' maps to 'a=fmtp:99 0/5'. A more complicated + example, with a dynamic payload type, is: + + pt = "0, 103 = \"audio/G729D;annexb=yes\" " + + m=audio 49170 RTP/AVP 99 0 103 + a=rtpmap:99 RED/8000 + a=fmtp:99 0/103 + a=rtpmap:103 G729D/8000 + a=fmtp:103 annexb=yes + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + + +Casner & Hoschka Standards Track [Page 28] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + + Published specification: RFC 2198 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + +4.1.22. Registration of MIME media type audio/VDVI + + MIME media type name: audio + + MIME subtype name: VDVI + + Required parameters: None + + Optional parameters: ptime, maxptime + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + +Casner & Hoschka Standards Track [Page 29] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2. Video Type Registrations + + For all of the video payload formats registered here, the RTP + timestamp clock rate is always 90000 Hz, so the "rate" parameter is + not applicable. Likewise, the "channel" parameter is not used with + video, and while "ptime" and "maxptime" could be used with video, + they typically are not. + +4.2.1. Registration of MIME media type video/BT656 + + MIME media type name: video + + MIME subtype name: BT656 + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2431 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 30] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.2. Registration of MIME media type video/CelB + + MIME media type name: video + + MIME subtype name: CelB + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2029 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 31] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.3. Registration of MIME media type video/JPEG + + MIME media type name: video + + MIME subtype name: JPEG + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2435 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 32] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.4. Registration of MIME media type video/H261 + + MIME media type name: video + + MIME subtype name: H261 + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2032 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 33] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.5. Registration of MIME media type video/H263 + + MIME media type name: video + + MIME subtype name: H263 + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2190 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 34] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.6. Registration of MIME media type video/H263-1998 + + MIME media type name: video + + MIME subtype name: H263-1998 + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2429 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 35] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.7. Registration of MIME media type video/H263-2000 + + MIME media type name: video + + MIME subtype name: H263-2000 + + Required parameters: None + + Optional parameters: + profile: H.263 profile number, in the range 0 through 10, + specifying the supported H.263 annexes/subparts. + + level: Level of bitstream operation, in the range 0 through + 100, specifying the level of computational complexity of the + decoding process. + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2429 + The specific values for the profile and level parameters and + their meaning are defined in Annex X of ITU-T Recommendation + H.263, "Video coding for low bit rate communication". Note + that the RTP payload format for H263-2000 is the same as for + H263-1998, but additional annexes/subparts are specified along + with the profiles and levels. + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + +Casner & Hoschka Standards Track [Page 36] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.8. Registration of MIME media type video/MPV + + MIME media type name: video + + MIME subtype name: MPV + MPEG-1 or -2 Elementary Streams + + Required parameters: None + + Optional parameters: + type: the type of MPEG video, from the set "mpeg1", + "mpeg2-halfd1", or "mpeg2-fulld1". The default is "mpeg1". + The mapping to a=fmtp is identity. + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2250 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 37] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.9. Registration of MIME media type video/MP2T + + MIME media type name: video + + MIME subtype name: MP2T + MPEG-2 Transport Streams + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2250 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 38] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.10. Registration of MIME media type video/MP1S + + MIME media type name: video + + MIME subtype name: MP1S + MPEG-1 Systems Streams + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2250 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 39] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.11. Registration of MIME media type video/MP2P + + MIME media type name: video + + MIME subtype name: MP2P + MPEG-2 Program Streams + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2250 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 40] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.12. Registration of MIME media type video/BMPEG + + MIME media type name: video + + MIME subtype name: BMPEG + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 2343 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 41] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +4.2.13. Registration of MIME media type video/nv + + MIME media type name: video + + MIME subtype name: nv + + Required parameters: None + + Optional parameters: None + + Encoding considerations: + This type is only defined for transfer via RTP [RFC 3550]. + + Security considerations: See Section 5 of RFC 3555 + + Interoperability considerations: none + + Published specification: RFC 3551 + + Applications which use this media type: + Audio and video streaming and conferencing tools. + + Additional information: none + + Person & email address to contact for further information: + Stephen Casner + + Intended usage: COMMON + + Author/Change controller: + Stephen Casner + +5. Security Considerations + + The MIME subtype registration procedure specified in this memo does + not impose any security considerations on its own. This memo also + contains several MIME type registrations. The registrations + themselves do not impose security risks, but some may state security + considerations specific to the particular registration. + + Several audio and video encodings are perfect for hiding data using + steganography. + + The RTP specification, RFC 3550, provides security considerations for + the transport of audio and video data over RTP, including the use of + encryption where confidentiality is required. + + + + + +Casner & Hoschka Standards Track [Page 42] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +6. Normative References + + [1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail + Extensions (MIME) Part Four: Registration Procedures", BCP 13, + RFC 2048, November 1996. + + [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: + A Transport Protocol for Real-Time Applications", RFC 3550, July + 2003. + + [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video + Conferences with Minimal Control", RFC 3551, July 2003. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", + RFC 2327, April 1998. + + [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [7] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP Payload + Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled + Audio", RFC 3190, January 2002. + + + + + + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 43] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +7. Authors' Addresses + + Stephen L. Casner + Packet Design + 3400 Hillview Avenue, Building 3 + Palo Alto, CA 94304 + United States + + Phone: +1 650 739-1843 + EMail: casner@acm.org + + + Philipp Hoschka + INRIA + Route des Lucioles 2004 + 06904, Sophia-Antipolis Cedex + BP 93, France + + Phone: (+33) 4 92 38 79 84 + Fax: (+33) 4 92 38 77 65 + EMail: ph@w3.org + + W3C + http://www.w3.org/people/hoschka + + + + + + + + + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 44] + +RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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. + + + + + + + + + + + + + + + + + + + +Casner & Hoschka Standards Track [Page 45] + -- cgit v1.2.3