datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Media Type Registration of RTP Payload Formats
RFC 4855

Document type: RFC - Proposed Standard (February 2007)
Obsoletes RFC 3555
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4855 (Proposed Standard)
Responsible AD: Cullen Jennings
Send notices to: avt-chairs@tools.ietf.org, casner@acm.org

Network Working Group                                          S. Casner
Request for Comments: 4855                                 Packet Design
Obsoletes: 3555                                            February 2007
Category: Standards Track

             Media Type Registration of RTP Payload Formats

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies the procedure to register RTP payload formats
   as audio, video, or other media subtype names.  This is useful in a
   text-based format description or control protocol to identify the
   type of an RTP transmission.

Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
   2. Procedure For Registering Media Types for RTP Payload Types .....2
      2.1. Example Media Type Registration ............................4
      2.2. Restrictions on Sharing a Subtype Name .....................5
   3. Mapping to SDP Parameters .......................................6
   4. Changes from RFC 3555 ...........................................7
   5. Security Considerations .........................................8
   6. IANA Considerations .............................................9
   7. References .....................................................10
      7.1. Normative References ......................................10
      7.2. Informative References ....................................10

Casner                      Standards Track                     [Page 1]
RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007

1.  Introduction

   RFC 4288 [1] defines media type specification and registration
   procedures that use the Internet Assigned Numbers Authority (IANA) as
   a central registry.  That document covers general requirements
   independent of particular application environments and transport
   modes.  This document defines the specific requirements for
   registration of media types for use with the Real-time Transport
   Protocol (RTP), RFC 3550 [2], to identify RTP payload formats.

1.1.  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 [3] and
   indicate requirement levels for implementations compliant with this
   specification.

2.  Procedure For Registering Media Types for RTP Payload Types

   Registering an RTP payload type as a media type follows the same
   procedures as described in RFC 4288 [1] and uses the registration
   template shown in Section 10 of that RFC.  To specify how the
   particular payload format is transported over RTP, some additional
   information is required in the following sections of that template:

     Required parameters:
          If the payload format does not have a fixed RTP timestamp
          clock rate, then a "rate" parameter is required to specify the
          RTP timestamp clock rate.  A particular payload format may
          have additional required parameters.

     Optional parameters:
          Most audio payload formats can have an optional "channels"
          parameter to specify the number of audio channels included in
          the transmission.  The default channel order is as specified
          in RFC 3551 [4].  Any payload format, but most likely audio
          formats, may also include the optional parameters "ptime" to
          specify the recommended length of time in milliseconds
          represented by the media in a packet, and/or "maxptime" to
          specify the maximum amount of media 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) [5].

          A particular payload format may have additional optional
          parameters.  As allowed in Section 4.3 of [1], new parameters
          MAY be added to RTP media types that have been previously

Casner                      Standards Track                     [Page 2]

[include full document text]