summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3555.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3555.txt')
-rw-r--r--doc/rfc/rfc3555.txt2523
1 files changed, 2523 insertions, 0 deletions
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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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 <casner@acm.org>
+
+ 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]
+