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]
datatracker.ietf.org