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):
- name and description of encoding, in particular the RTP timestamp clock rate; the names defined here are 3 or 4 characters long to allow a compact representation if needed;
- indication of who has change control over the encoding (for example, ISO, ITU, other international standardization bodies, a consortium or a particular company or group of companies);
- any operating parameters or profiles;
- a reference to a further description, if available, for example (in order of preference) an RFC, a published paper, a patent filing, a technical report, documented source code or a computer manual; Note that this is not required, but very helpful.
- for proprietary encodings, contact information (postal and email address);
- the static payload type value for this profile, if necessary (see below).
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 encoding is of interest to the Internet community at large.
- It offers benefits compared to existing encodings and/or is required for interoperation with existing, widely deployed conferencing or multimedia systems.
- The description is sufficient to build a decoder. (This does not mean that the decoder is free of licensing or patent constraints. For example, G.723.1 has a static payload type.)
Practically speaking, for fairness, only codecs recognized by ISO (MPEG), the ITU-T (G.xxx, H.261, H.263) or other standards bodies such as the IMTC (in the case of DVI) are likely to be issued a static payload type at this time, as no other reasonable algorithm for assigning the limited static PT space seems possible.
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.