Media Type Registration of RTP Payload Formats
RFC 4855
Document | Type |
RFC - Proposed Standard
(February 2007; No errata)
Updated by RFC 8851
Obsoletes RFC 3555
|
|
---|---|---|---|
Author | Stephen Casner | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4855 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Cullen Jennings | ||
Send notices to | (None) |
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] RFC 4855 Media Type Reg. of RTP Payload Formats February 2007 defined, but the new parameters MUST NOT change existing functionality and it MUST be possible for existing implementations to ignore the additional parameters without impairing operation. Encoding considerations: Most RTP payload formats include binary or framed data asShow full document text