doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc4856.txt b/doc/rfc/rfc4856.txt
new file mode 100644
index 0000000..5d6229c
--- /dev/null
+++ b/doc/rfc/rfc4856.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                          S. Casner
+Request for Comments: 4856                                 Packet Design
+Obsoletes: 3555                                               March 2007
+Category: Standards Track
+
+
+           Media Type Registration of Payload Formats in the
+              RTP Profile for Audio and Video Conferences
+
+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 IETF Trust (2007).
+
+Abstract
+
+   This document specifies media type registrations for the RTP payload
+   formats defined in the RTP Profile for Audio and Video Conferences.
+   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. Registrations for "Audio/Video Profile" .........................3
+      2.1. Audio Type Registrations ...................................3
+      2.2. Video Type Registrations ..................................24
+   3. Changes from RFC 3555 ..........................................25
+   4. Security Considerations ........................................26
+   5. References .....................................................27
+      5.1. Normative References ......................................27
+      5.2. Informative References ....................................27
+
+
+
+
+
+
+
+
+
+
+
+
+Casner                      Standards Track                     [Page 1]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+1.  Introduction
+
+   This document updates the media type registrations initially
+   specified in RFC 3555 for the Real-time Transport Protocol (RTP)
+   payload formats defined in the RTP Profile for Audio and Video
+   Conferences, RFC 3551 [1], as subtypes under the "audio" and "video"
+   media types.  This document does not include media type registrations
+   for the RTP payload formats that are referenced in RFC 3551 but
+   defined in other RFCs.  The media type registrations for those
+   payload formats are intended to be updated by including them in
+   revisions of the individual RFCs defining the payload formats.
+
+   The media type registrations specified here conform to the updated
+   template format and procedures in RFC 4288 [2] and RFC 4855 [3].
+   This update makes no technical changes in the registrations.
+   Together with RFC 4855, this document obsoletes RFC 3555.
+
+1.1.  IANA Considerations
+
+   As a consequence of the generalized applicability of the media types
+   registry as specified in RFC 4288, some changes in nomenclature are
+   needed in the RTP Payload Format section of the registry.  In the
+   registry title "RTP Payload Format MIME types" and the introductory
+   text, "MIME" should be changed to "media". "MIME" should be deleted
+   from the table headings, leaving just "media type" and "subtype".
+
+   This document updates the media type registrations listed below to
+   conform to the revised registration format specified in RFC 4288 and
+   RFC 4855, so the reference for these media types should be changed
+   from RFC 3555 to this document.  Some media type registrations
+   contained in RFC 3555 are omitted from this document; the existing
+   registrations for those types continue to be valid until updated by
+   other RFCs.  There are no new registrations contained here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner                      Standards Track                     [Page 2]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+      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/PCMA
+      audio/PCMU
+      audio/VDVI
+      video/nv
+
+   Media type audio/L16 was initially 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.  Registrations for "Audio/Video Profile"
+
+   In the following sections, the RTP payload formats defined in the RTP
+   Profile for Audio and Video Conferences, RFC 3551 [1], are registered
+   as media types.
+
+2.1.  Audio Type Registrations
+
+   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.
+
+   These audio formats also include the optional parameters "ptime" to
+   specify the recommended length of time in milliseconds represented by
+
+
+
+
+Casner                      Standards Track                     [Page 3]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   the media in a packet, and "maxptime" to specify the maximum amount
+   of media that can be encapsulated in each packet, expressed as time
+   in milliseconds.  The "ptime" and "maxptime" parameters are defined
+   in the Session Description Protocol (SDP), RFC 4566 [5].
+
+2.1.1.  Registration of Media Type audio/DVI4
+
+   Type name: audio
+
+   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 (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550 [6]).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+
+
+
+Casner                      Standards Track                     [Page 4]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.2.  Registration of Media Type audio/G722
+
+   Type name: audio
+
+   Subtype name: G722
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+
+
+
+Casner                      Standards Track                     [Page 5]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+2.1.3.  Registration of Media Type audio/G723
+
+   Type name: audio
+
+   Subtype name: G723
+
+   Required parameters: none
+
+   Optional parameters:
+        ptime, maxptime: see RFC 4566
+
+        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 media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+
+
+
+Casner                      Standards Track                     [Page 6]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.4.  Registration of Media Type audio/G726-16
+
+   Type name: audio
+
+   Subtype name: G726-16
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+
+
+
+
+Casner                      Standards Track                     [Page 7]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.5.  Registration of Media Type audio/G726-24
+
+   Type name: audio
+
+   Subtype name: G726-24
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+
+
+
+Casner                      Standards Track                     [Page 8]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+2.1.6.  Registration of Media Type audio/G726-32
+
+   Type name: audio
+
+   Subtype name: G726-32
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+
+
+
+
+
+
+
+Casner                      Standards Track                     [Page 9]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+2.1.7.  Registration of Media Type audio/G726-40
+
+   Type name: audio
+
+   Subtype name: G726-40
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 10]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+2.1.8.  Registration of Media Type audio/G728
+
+   Type name: audio
+
+   Subtype name: G728
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 11]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+2.1.9.  Registration of Media Type audio/G729
+
+   Type name: audio
+
+   Subtype name: G729
+
+   Required parameters: none
+
+   Optional parameters:
+        ptime, maxptime: see RFC 4566
+
+        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 media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 12]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.10.  Registration of Media Type audio/G729D
+
+   Type name: audio
+
+   Subtype name: G729D
+
+   Required parameters: none
+
+   Optional parameters:
+        ptime, maxptime: see RFC 4566
+
+        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 media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+
+
+
+
+Casner                      Standards Track                    [Page 13]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.11.  Registration of Media Type audio/G729E
+
+   Type name: audio
+
+   Subtype name: G729E
+
+   Required parameters: none
+
+   Optional parameters:
+        ptime, maxptime: see RFC 4566
+
+        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 media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 14]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.12.  Registration of Media Type audio/GSM
+
+   Type name: audio
+
+   Subtype name: GSM
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+
+
+Casner                      Standards Track                    [Page 15]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.13.  Registration of Media Type audio/GSM-EFR
+
+   Type name: audio
+
+   Subtype name: GSM-EFR
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+
+
+
+
+Casner                      Standards Track                    [Page 16]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.14.  Registration of Media Type audio/L8
+
+   Type name: audio
+
+   Subtype name: L8
+
+   Required parameters:
+        rate: the RTP timestamp clock rate
+
+   Optional parameters:
+        channels: how many audio streams are interleaved -- defaults
+        to 1; stereo would be 2, etc.  Interleaving takes place
+        between individual one-byte samples.  The channel order is as
+        specified in RFC 3551.
+
+        ptime, maxptime: see RFC 4566
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+
+
+
+Casner                      Standards Track                    [Page 17]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.15.  Registration of Media Type audio/L16
+
+   Media type audio/L16 was initially registered via RFC 2586 [10] for
+   transports other than RTP.  That registration is incorporated here
+   and augmented with additional information for RTP transport.
+
+   Type name: audio
+
+   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.  The channel order is as
+        specified in RFC 3551 unless a channel-order parameter is also
+        present.
+
+        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 Discs.  This parameter MUST be omitted if no
+        analog preemphasis was applied.  Note that this is a stream
+        property parameter, not a receiver configuration parameter.
+        Thus, if parameters are negotiated, it may not be possible for
+        the sender to comply with a receiver request for a particular
+        setting.
+
+        channel-order: specifies the sample interleaving order for
+        multiple-channel audio streams (see RFC 3190 [7], Section 7).
+        Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo,
+        DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2,
+        DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.
+
+
+
+Casner                      Standards Track                    [Page 18]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+        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 [9]; 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.
+
+   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.
+
+   Security considerations:
+        Audio/L16 data is believed to offer no security risks.  This
+        media type does not carry active content.  The encoding is not
+        compressed.  See Section 4 of RFC 4856.
+
+   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 that use this media type:
+        The public domain "sox" and "rateconv" programs accept this
+        type.
+
+   Additional information:
+        Magic number(s): none
+        File extension(s): WAV L16
+        Macintosh file type code: AIFF
+
+   Person to contact for further information:
+        James Salsman <jps-L16@bovik.org>
+
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 19]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   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".
+
+   Restrictions on usage:
+        In addition to file-based transfer methods, this type is also
+        defined for transfer via RTP (RFC 3550).
+
+   Author:
+        James Salsman for non-RTP transports.
+        Stephen Casner for RTP transport.
+
+   Change controller:
+        James Salsman for non-RTP transports.
+        For RTP transport, IETF Audio/Video Transport working group
+        delegated from the IESG.
+
+2.1.16.  Registration of Media Type audio/LPC
+
+   Type name: audio
+
+   Subtype name: LPC
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that use this media type:
+        Audio and video streaming and conferencing tools.
+
+   Additional information: none
+
+
+
+
+Casner                      Standards Track                    [Page 20]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Person & email address to contact for further information:
+        Stephen Casner <casner@acm.org>
+
+   Intended usage: COMMON
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.17.  Registration of Media Type audio/PCMA
+
+   Type name: audio
+
+   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: how many audio streams are interleaved -- defaults
+        to 1; stereo would be 2, etc.  Interleaving takes place
+        between individual one-byte samples.  The channel order is as
+        specified in RFC 3551.
+
+        ptime, maxptime: see RFC 4566
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+
+
+
+Casner                      Standards Track                    [Page 21]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.18.  Registration of Media Type audio/PCMU
+
+   Type name: audio
+
+   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: how many audio streams are interleaved -- defaults
+        to 1; stereo would be 2, etc.  Interleaving takes place
+        between individual one-byte samples.  The channel order is as
+        specified in RFC 3551.
+
+        ptime, maxptime: see RFC 4566
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+
+
+Casner                      Standards Track                    [Page 22]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.1.19.  Registration of Media Type audio/VDVI
+
+   Type name: audio
+
+   Subtype name: VDVI
+
+   Required parameters: none
+
+   Optional parameters: ptime, maxptime (see RFC 4566)
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+
+
+
+Casner                      Standards Track                    [Page 23]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+2.2.  Video Type Registrations
+
+   For most video payload formats, including the one 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, while "ptime" and "maxptime" could be but
+   typically are not.
+
+2.2.1.  Registration of Media Type video/nv
+
+   Type name: video
+
+   Subtype name: nv
+
+   Required parameters: none
+
+   Optional parameters: none
+
+   Encoding considerations:
+        This media type is framed binary data (see Section 4.8 in RFC
+        4288).
+
+   Security considerations:
+        This media type does not carry active content.  It does
+        transfer compressed data.  See Section 4 of RFC 4856.
+
+
+
+
+Casner                      Standards Track                    [Page 24]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+   Interoperability considerations: none
+
+   Published specification: RFC 3551
+
+   Applications that 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
+
+   Restrictions on usage:
+        This media type depends on RTP framing, and hence is only
+        defined for transfer via RTP (RFC 3550).  Transfer within
+        other framing protocols is not defined at this time.
+
+   Author:
+        Stephen Casner
+
+   Change controller:
+        IETF Audio/Video Transport working group delegated from the
+        IESG.
+
+3.  Changes from RFC 3555
+
+   RFC 3555 is obsoleted by the combination of RFC 4855 [3] and this
+   document.  RFC 4855 retains the specification of procedures and
+   requirements from RFC 3555, while the media type registrations from
+   RFC 3555 were extracted into this document.  The media type
+   registrations for the RTP payload formats that are referenced in RFC
+   3551 [1], but defined in other RFCs, have been elided from this
+   document because those registrations are intended to be updated by
+   including them in revisions of the individual RFCs defining the
+   payload formats.
+
+   The media type registrations in this document have been updated to
+   conform to the revised media type registration procedures in RFC 4288
+   [2] and RFC 4855.  Whereas RFC 3555 required the encoding
+   considerations to specify transfer via RTP, that is now specified
+   under restrictions on usage.  The encoding considerations now warn
+   that these types are framed binary data.  The change controller is
+   also now identified according to current conventions.  The optional
+   parameter "channels" was clarified for audio subtypes L8, PCMA, and
+   PCMU.  Finally, reference [9], which was missing from RFC 3555, has
+   been corrected.
+
+
+
+Casner                      Standards Track                    [Page 25]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+4.  Security Considerations
+
+   This memo specifies media type registrations for the transfer of
+   several compressed audio and video data encodings via RTP, so
+   implementations using these media types are subject to the security
+   considerations discussed in the RTP specification [8].
+
+   None of these media types carry "active content" that could impose
+   malicious side-effects upon the receiver.  The content consists
+   solely of compressed audio or video data to be decoded and presented
+   as sound or images.  However, several audio and video encodings are
+   perfect for hiding data using steganography.
+
+   A potential denial-of-service threat exists for data encodings using
+   compression techniques that have non-uniform receiver-end
+   computational load.  The attacker can inject pathological datagrams
+   into the stream, which are complex to decode and cause the receiver
+   to be overloaded.  However, none of the encodings registered here has
+   an expansion factor greater than about 20, and all are considered
+   relatively simple by modern standards (some are implemented on
+   handheld devices and most were implemented on general-purpose
+   computers ten years ago).
+
+   As with any IP-based protocol, in some circumstances a receiver may
+   be overloaded simply by the receipt of too many packets, either
+   desired or undesired.  Network-layer authentication MAY be used to
+   discard packets from undesired sources, but the processing cost of
+   the authentication itself may be too high.
+
+   RTP may be sent via IP multicast, which provides no direct means for
+   a sender to know all the receivers of the data sent and therefore no
+   measure of privacy.  Rightly or not, users may be more sensitive to
+   privacy concerns with audio and video communication than they have
+   been with more traditional forms of network communication.
+   Therefore, the use of security mechanisms with RTP to provide
+   confidentiality and integrity of the data is important.  Because the
+   data compression used with these media types is applied end-to-end,
+   encryption may be performed after compression so there is no conflict
+   between the two operations.
+
+
+
+
+
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 26]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+5.  References
+
+5.1.  Normative References
+
+   [1]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+        Conferences with Minimal Control", RFC 3551, July 2003.
+
+   [2]  Freed, N. and J. Klensin, "Media Type Specifications and
+        Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+   [3]  Casner, S., "Media Type Registration of RTP Payload Types", RFC
+        4855, January 2007.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+        Description Protocol", RFC 4566, July 2006.
+
+   [6]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+        "RTP:  A Transport Protocol for Real-Time Applications", RFC
+        3550, July 2003.
+
+   [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.
+
+   [8]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+        "RTP:  A Transport Protocol for Real-Time Applications", RFC
+        3550, July 2003.
+
+5.2.  Informative References
+
+   [9]  IEC 61834, Helical-scan digital video cassette recording system
+        using 6,35 mm magnetic tape for consumer use (525-60, 625-50,
+        1125-60, and 1250-50 systems), August 1998.
+
+   [10] Salsman, J. and H. Alvestrand, "The Audio/L16 MIME content
+        type", RFC 2586, May 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 27]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+Author's Address
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 28]
+
+RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 29]
+