GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4856

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4856.txt · Last modified: 2007/02/27 01:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki