doc: Add RFC documents

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]
+