[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 3555) 00 01 02 RFC 4856

Internet Engineering Task Force      Audio/Video Transport Working Group
INTERNET-DRAFT                                                 S. Casner
draft-ietf-avt-rfc3555bis-part2-02.txt                     Packet Design
Obsoletes: RFC 3555 (if approved)                       October 15, 2006
                                                 Expires: April 15, 2007


           Media Type Registration of Payload Formats in the
              RTP Profile for Audio and Video Conferences

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 15, 2007.

Copyright Notice

Copyright (C) The Internet Society (2006).

                                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.






                           Expires April 2007                 [Page 1]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


Table of Contents

   1. Introduction ..................................................  3
      1.1. IANA Considerations ......................................  3
      1.2. Terminology ..............................................  4
   2. Registrations for "Audio/Video Profile" .......................  4
      2.1. Audio Type Registrations .................................  4
      2.2. Video Type Registrations ................................. 25
   3. Changes from RFC 3555 ......................................... 26
   4. Security Considerations ....................................... 26
   5. References .................................................... 27
   6. Author's Address .............................................. 28
   7. Intellectual Property Statement ............................... 28
   8. Disclaimer of Validity ........................................ 29
   9. Copyright Statement ........................................... 29




































                           Expires April 2007                 [Page 2]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


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 XXXX [3].  This
update makes no technical changes in the registrations.  Together with
RFC XXXX, 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
XXXX, 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.


















                           Expires April 2007                 [Page 3]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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



                           Expires April 2007                 [Page 4]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


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 ZZZZ [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 ZZZZ)

     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 YYYY.

     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

     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




                           Expires April 2007                 [Page 5]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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 ZZZZ)

     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 YYYY.

     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

     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.




                           Expires April 2007                 [Page 6]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


2.1.3.  Registration of Media Type audio/G723

     Type name: audio

     Subtype name: G723

     Required parameters: None

     Optional parameters:
          ptime, maxptime: see RFC ZZZZ

          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 YYYY.

     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

     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.




                           Expires April 2007                 [Page 7]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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 ZZZZ)

     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 YYYY.

     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

     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





                           Expires April 2007                 [Page 8]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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 ZZZZ)

     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 YYYY.

     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

     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.




                           Expires April 2007                 [Page 9]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


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 ZZZZ)

     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 YYYY.

     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

     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.7.  Registration of Media Type audio/G726-40

     Type name: audio




                           Expires April 2007                [Page 10]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     Subtype name: G726-40

     Required parameters: None

     Optional parameters: ptime, maxptime (see RFC ZZZZ)

     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 YYYY.

     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

     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.8.  Registration of Media Type audio/G728

     Type name: audio

     Subtype name: G728

     Required parameters: None




                           Expires April 2007                [Page 11]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     Optional parameters: ptime, maxptime (see RFC ZZZZ)

     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 YYYY.

     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

     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.9.  Registration of Media Type audio/G729

     Type name: audio

     Subtype name: G729

     Required parameters: None

     Optional parameters:
          ptime, maxptime: see RFC ZZZZ





                           Expires April 2007                [Page 12]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


          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 YYYY.

     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

     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.10.  Registration of Media Type audio/G729D

     Type name: audio

     Subtype name: G729D

     Required parameters: None





                           Expires April 2007                [Page 13]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     Optional parameters:
          ptime, maxptime: see RFC ZZZZ

          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 YYYY.

     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

     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.11.  Registration of Media Type audio/G729E

     Type name: audio

     Subtype name: G729E




                           Expires April 2007                [Page 14]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     Required parameters: None

     Optional parameters:
          ptime, maxptime: see RFC ZZZZ

          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 YYYY.

     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

     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




                           Expires April 2007                [Page 15]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     Subtype name: GSM

     Required parameters: None

     Optional parameters: ptime, maxptime (see RFC ZZZZ)

     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 YYYY.

     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

     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.13.  Registration of Media Type audio/GSM-EFR

     Type name: audio

     Subtype name: GSM-EFR

     Required parameters: None




                           Expires April 2007                [Page 16]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     Optional parameters: ptime, maxptime (see RFC ZZZZ)

     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 YYYY.

     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

     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.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



                           Expires April 2007                [Page 17]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


          between individual one-byte samples.  The channel order is as
          specified in RFC 3551.

          ptime, maxptime: see RFC ZZZZ

     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 YYYY.

     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

     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.15.  Registration of Media Type audio/L16

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.

     Type name: audio





                           Expires April 2007                [Page 18]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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 Disks.  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.
          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



                           Expires April 2007                [Page 19]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


          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 YYYY.

     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.

          Magic number(s) : None
          File extension(s) : WAV L16
          Macintosh file type code : AIFF

     Person to contact for further information
          Name : James Salsman
          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."

     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



                           Expires April 2007                [Page 20]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


          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 ZZZZ)

     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 YYYY.

     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

     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.






                           Expires April 2007                [Page 21]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


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 ZZZZ

     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 YYYY.

     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

     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



                           Expires April 2007                [Page 22]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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 ZZZZ

     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 YYYY.

     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

     Restrictions on usage:
          This media type depends on RTP framing, and hence is only
          defined for transfer via RTP (RFC 3550).  Transfer within



                           Expires April 2007                [Page 23]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


          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 ZZZZ)

     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 YYYY.

     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

     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



                           Expires April 2007                [Page 24]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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 YYYY.

     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

     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.




                           Expires April 2007                [Page 25]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


     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 XXXX [3] and this
document.  RFC XXXX 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 XXXX.  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.

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



                           Expires April 2007                [Page 26]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


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.

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",
    draft-ietf-avt-rfc3555bis-02.txt, February 2006.
    (Companion to this document, referenced herein as RFC XXXX).

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
    Levels", BCP 14, RFC 2119, March 1997.

[5] Handley, M., V. Jacobson and C. Perkins, "SDP: Session Description
    Protocol", draft-ietf-mmusic-sdp-new-26.txt, January 2006.
    (Approved for publication as Proposed Standard to obsolete
    RFC 2327, so this reference should be to the RFC when published
    and that number inserted where RFC ZZZZ appears in this document)

[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



                           Expires April 2007                [Page 27]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


    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.

[Note to RFC Editor: References in the media type registrations to RFC
YYYY are to be replaced with the RFC number of this document itself.
The purpose of the self-references is to make the registrations complete
when extracted.]

6.  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

7.  Intellectual Property Statement

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



                           Expires April 2007                [Page 28]

Internet Draft   draft-ietf-avt-rfc3555bis-part2-02.txt October 15, 2006


that may cover technology that may be required to implement this
standard.  Please address the information to the IETF at ietf-
ipr@ietf.org.

8.  Disclaimer of Validity

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 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.

9.  Copyright Statement

Copyright (C) The Internet Society (2006).

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.






























                           Expires April 2007                [Page 29]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/