RFC 4855: Media Type Registration of RTP Payload Formats | RFC Editor

Skip to content Primary navigationThe RFC SeriesFor AuthorsAbout UsHomeRFC 4855 View as: Plain Text, Compact HTML Info RFC 4855: Media Type Registration of RTP Payload Formatsmedia typesRTP payload formatFebruary 2007. S. CasnerProposed StandardSubscribe9 subscribed Add to Set Read aloud This RFC was updated, see RFC 8851.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 as described in Section 4.8 of [1]. The appropriate encoding considerations MUST be noted. Published specification: A description of the media encoding and a specification of the payload format must be provided, usually by reference to an RTP payload format specification RFC. That RFC may be separate, or the media type registration may be incorporated into the payload format specification RFC. The payload format specification MUST include the RTP timestamp clock rate (or multiple rates for audio encodings with multiple sampling rates). A reference to a further description of the data compression format itself should be provided, if available. Restrictions on usage: The fact that the media type is defined for transfer via RTP MUST be noted, in particular, if the transfer depends on RTP framing and hence the media type is only defined for transfer via RTP. Depending on whether or not the type has already been registered for transfer with a non-RTP protocol (e.g., MIME mail or http), several different cases can occur: a) Not yet registered as a media type A new registration should be constructed using the media type registration template. The registration may specify transfer via other means in addition to RTP if that is feasible and desired. The appropriate encoding considerations must be specified, and the restrictio