Registering RTP Payload Types

There are two registrations that are commonly confused, namely payload type registration and assigning payload type numbers (the PT field in the RTP header).

There will be no additional static payload type numbers for RTP, beyond those listed in RFC 1890. This decision was made by the AVT working group and documented in the pending revision for RFC 1890, draft-ietf-avt-profile-new:

This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in this document. Establishing this policy avoids the problem of trying to create a set of criteria for accepting static assignments and encourages the implementation and deployment of the dynamic payload type mechanisms.

From Section 3. of RFC 1890, with some practical additions in italics:

This profile defines a set of standard encodings and their payload types when used within RTP. Other encodings and their payload types are to be registered with the Internet Assigned Numbers Authority (IANA). When registering a new encoding/payload type, the following information should be provided to Henning Schulzrinne and Steve Casner (who will provide informal feedback):

Note that not all encodings to be used by RTP need to be assigned a static payload type. Non-RTP means beyond the scope of this memo (such as directory services (such as SDP) or signaling protocols (such as RTSP and H.245) may be used to establish a dynamic mapping between a payload type drawn from the range 96-127 and an encoding. For implementor convenience, this profile contains descriptions of encodings which do not currently have a static payload type assigned to them.

The available payload type space is relatively small. Thus, new static payload types are assigned only if the following conditions are met:

The persons listed above will then pass on the description to IANA, which will make the formal registration. At the current time, the information will also be included in the revised RTP profile, to be issued late 1997. Note that this process is not meant as a gatekeeper (dynamic payload types are freely available), but simply to ensure maximum usefulness and consistency of the description, as IANA does not have the technical resources to evaluate RTP payload type registrations.

Last modified: 1997-10-13 by Henning Schulzrinne