RTP media types: Closing the RTP Payload Format Media Types Registry
Consolidating where RTP payload format media types are registered.
Westerlund, M., "Closing the RTP Payload Format Media Types Registry", RFC 9751, DOI 10.17487/RFC9751, March 2025, <https://www.rfc-editor.org/info/rfc9751>.
@misc{rfc9751,
series = {Request for Comments},
number = 9751,
howpublished = {RFC 9751},
publisher = {RFC Editor},
doi = {10.17487/RFC9751},
url = {https://www.rfc-editor.org/info/rfc9751},
author = {M. Westerlund},
title = {{Closing the RTP Payload Format Media Types Registry}},
pagetotal = 6,
year = 2025,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 9751 Ericsson
Updates: 8088 March 2025
Category: Standards Track
ISSN: 2070-1721
Closing the RTP Payload Format Media Types Registry
Abstract
The working group process and the authors of RTP payload formats have
sometimes failed to ensure that the media types are registered in the
IANA "RTP Payload Format Media Types" registry as recommended by RFC
8088. To simplify the process and rely only on the "Media Types"
registry, this document closes the RTP payload- specific registry.
In addition, it updates the instruction in RFC 8088 to reflect this
change.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9751.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Update to How to Write an RTP Payload Format
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgments
Author's Address
1. Introduction
Sometimes, authors defining new Real-time Transport Protocol (RTP)
payload formats forgot to specify registration of the format's media
type in the "RTP Payload Format Media Types" registry [RTP-FORMATS]
as recommended by [RFC8088]. In practice, this has no real impact.
This registry is not used for any purpose other than to track which
media types actually have RTP payload formats, which can be done
through other means.
It is required that media types be registered in the "Media Types"
registry [MEDIA-TYPES] to identify the format in various signalling
usages, avoid collisions, and reference the defining specifications.
To resolve this situation, this document:
* updates the "RTP Payload Format Media Types" registry to include
known RTP payload formats at the time of writing,
* closes the "RTP Payload Format Media Types" registry to future
registrations and lists this RFC as a reference, and
* removes from [RFC8088] the instruction to register RTP payload
formats in the "RTP Payload Format Media Types" registry.
The origins of the "RTP Payload Format Media Types" registry, as
referenced in [RTP-FORMATS], are unclear. The registry cites
[RFC4855] as providing the instructions for its maintenance.
However, upon reviewing RFC 4855, no text has been found that defines
the registry's purpose and operational rules. Further attempts to
trace the registry's creation have failed to uncover any references
to its establishment. It is likely that the registry was created
based on email correspondence or at the request of an Area Director.
Consequently, there is no known specification for this registry that
requires updating upon its closure.
2. Update to How to Write an RTP Payload Format
The IANA Considerations section of "How to write an RTP Payload
Format" (Section 7.4 of [RFC8088]) mandates that RTP payload formats
shall be registered in the "RTP Payload Format Media Types" registry.
The following paragraph is updated as shown below, thus removing the
need for media types to be registered in the "RTP Payload Format
Media Types" registry. Note that this update does not impact the
rest of RFC 8088's status as an Informational RFC.
OLD:
| Since all RTP payload formats contain a media type specification,
| they also need an IANA Considerations section. The media type
| name must be registered, and this is done by requesting that IANA
| register that media name. When that registration request is
| written, it shall also be requested that the media type is
| included under the "RTP Payload Format media types" sub-registry
| of the RTP registry (http://www.iana.org/assignments/rtp-
| parameters).
NEW:
| Since all RTP payload formats contain a media type specification,
| they also need an IANA Considerations section. The media type
| name must be registered, and this is done by requesting that IANA
| register that media name in the "Media Types" registry
| (https://www.iana.org/assignments/media-types/).
3. IANA Considerations
IANA has added the following RTP payload types to the "RTP Payload
Format Media Types" registry [RTP-FORMATS].
+=============+==========+===========+==========+==================+
| Media Type | Subtype | Clock | Channels | Reference |
| | | Rate (Hz) | (audio) | |
+=============+==========+===========+==========+==================+
| application | flexfec | | | RFC 8627 |
+-------------+----------+-----------+----------+------------------+
| audio | EVRCNW | 16000 | | RFC 6884 |
+-------------+----------+-----------+----------+------------------+
| audio | EVRCNW0 | 16000 | | RFC 6884 |
+-------------+----------+-----------+----------+------------------+
| audio | EVRCNW1 | 16000 | | RFC 6884 |
+-------------+----------+-----------+----------+------------------+
| audio | aptx | | | RFC 7310 |
+-------------+----------+-----------+----------+------------------+
| audio | opus | 48000 | | RFC 7587 |
+-------------+----------+-----------+----------+------------------+
| audio | G711-0 | | | RFC 7650 |
+-------------+----------+-----------+----------+------------------+
| audio | flexfec | | | RFC 8627 |
+-------------+----------+-----------+----------+------------------+
| text | flexfec | | | RFC 8627 |
+-------------+----------+-----------+----------+------------------+
| text | ttml+xml | | | RFC 8759 |
+-------------+----------+-----------+----------+------------------+
| video | VP8 | 90000 | | RFC 7741 |
+-------------+----------+-----------+----------+------------------+
| video | AV1 | 90000 | | [AV1-Media-Type] |
+-------------+----------+-----------+----------+------------------+
| video | HEVC | 90000 | | RFC 7798 |
+-------------+----------+-----------+----------+------------------+
| video | smpte291 | | | RFC 8331 |
+-------------+----------+-----------+----------+------------------+
| video | VVC | 90000 | | RFC 9328 |
+-------------+----------+-----------+----------+------------------+
| video | EVC | 90000 | | RFC 9584 |
+-------------+----------+-----------+----------+------------------+
| video | flexfec | | | RFC 8627 |
+-------------+----------+-----------+----------+------------------+
Table 1: Payload Types Added to the RTP Payload Format Media
Types Registry
IANA has updated the following entries in the "RTP Payload Format
Media Types" registry [RTP-FORMATS].
+============+===========+=================+==========+===========+
| Media Type | Subtype | Clock Rate (Hz) | Channels | Reference |
| | | | (audio) | |
+============+===========+=================+==========+===========+
| audio | MP4A-LATM | | | RFC 6416 |
+------------+-----------+-----------------+----------+-----------+
| video | MP4V-ES | 90000 | | RFC 6416 |
+------------+-----------+-----------------+----------+-----------+
Table 2: Payload Types Updated in RTP Payload Format Media
Types Registry
IANA has also closed the "RTP Payload Format Media Types" registry
[RTP-FORMATS] to any further registrations. IANA added the following
to the registry note:
NEW:
| This registry has been closed; it was considered redundant because
| all RTP payload formats are part of the [Media Types registry]
| (https://www.iana.org/assignments/media-types). See RFC 9751 for
| further details.
In addition, IANA updated the note in the "RTP Payload Format Media
Types" registry [RTP-FORMATS] as follows:
OLD:
| Registration procedures and a registration template can be found
| in [RFC4855].
NEW:
| It was previously stated that registration procedures and a
| registration template can be found in [RFC4855]. As documented in
| RFC 9751, this is not the case.
4. Security Considerations
This document has no security considerations as it defines an
administrative rule change.
5. References
5.1. Normative References
[AV1-Media-Type]
IANA, "video/AV1",
<https://www.iana.org/assignments/media-types/video/AV1>.
[MEDIA-TYPES]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format",
RFC 8088, DOI 10.17487/RFC8088, May 2017,
<https://www.rfc-editor.org/info/rfc8088>.
[RTP-FORMATS]
IANA, "RTP Payload Format Media Types",
<https://www.iana.org/assignments/rtp-parameters>.
5.2. Informative References
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>.
Acknowledgments
The author thanks Jonathan Lennox, Zaheduzzaman Sarker, Bernard
Aboba, Elwyn Davies, Wes Hardaker, Gunter Van de Velde, Éric Vyncke,
Mahesh Jethanandani, and Hyunsik Yang for their reviews and editorial
fixes.
Author's Address
Magnus Westerlund
Ericsson
Email: magnus.westerlund@ericsson.com
AI ELI5
On this page
§1Introduction
RTP payload formats define how different types of content (audio, video, application data) are encoded and transmitted using the Real-time Transport Protocol. When authors created new payload formats, they were recommended to register them in two places: the general IANA "Media Types" registry and a specialized "RTP Payload Format Media Types" registry.
In practice, authors often skipped the specialized registry. This created an incomplete registry that served no real purpose, since the general Media Types registry already tracked everything needed for signaling and avoiding collisions. The specialized registry was rarely consulted and had no documented purpose beyond duplicating information already recorded elsewhere.
RTP payload formats are recipes for how to send audio, video, or other data over the internet. They needed to be registered in two places, but people kept forgetting one because they were tracking the same thing.
§2Why Close the Registry
The "RTP Payload Format Media Types" registry existed but its origin was unclear. Looking back at RFC 4855, which supposedly described its maintenance, yielded no actual instructions or rules. Further investigation found no specification that had formally established the registry.
Since the registry served only to track which media types had RTP formats—information available through other means and already required in the Media Types registry—closing it eliminated redundancy without loss. All RTP payload formats must already be registered in the Media Types registry for use in signaling protocols and session descriptions.
The old registry had no clear rules and nobody really needed it. Everything important is already in the main list.
§3Origins and Evolution
The registry's creation was never formally documented. Attempts to trace its establishment yielded no RFC text or official record. RFC 4855 is cited as providing maintenance instructions, but review found no such guidance in that document. It appears the registry may have been created through email discussion or an Area Director request, but this context has been lost.
This lack of formal documentation contributed to the registry's neglect. Without clear rules or a documented purpose, maintainers and authors had no reference to consult, making the registry seem optional and leading to incomplete registrations.
Nobody could find where the old list came from or what the rules were supposed to be. It was probably started informally and then forgotten.
§4Update to RFC 8088
RFC 8088 "How to Write an RTP Payload Format" had instructed authors that when registering a media type, they must also request registration in the "RTP Payload Format Media Types" registry. This RFC updates that instruction.
The new text removes the requirement for the specialized registry. Instead, it simply says: when registering a media type for an RTP payload format, request that IANA register it in the "Media Types" registry. This is the only registration step needed.
The old instruction said to register in two places. The new one says just register in one place—the main list.
§5IANA Actions
This RFC directed IANA to perform three actions. First, it populated the "RTP Payload Format Media Types" registry with known RTP payload formats at the time of publication, capturing formats that had been registered or implemented. This included formats like Opus audio, VP8 video, EVRC audio variants, and several others across audio, video, application, and text subtypes.
Second, it formally closed the registry to future registrations and added a note explaining that the registry is now closed and redundant with the Media Types registry. Third, it corrected the registry's note to document that RFC 4855 does not actually define how the registry should work, clarifying the historical confusion about the registry's origins.
IANA added all the known formats that were already being used, then locked the old list so nobody could add to it anymore.