rfc9751.original.xml   rfc9751.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3. -ietf-avtcore-rtp-payload-registry-05" number="9751" category="std" consensus="t
3) --> rue" submissionType="IETF" obsoletes="" updates="8088" symRefs="true" sortRefs="
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft true" tocInclude="true" xml:lang="en" version="3">
-ietf-avtcore-rtp-payload-registry-05" category="std" consensus="true" submissio
nType="IETF" updates="8088" version="3">
<!-- xml2rfc v2v3 conversion 3.23.2 -->
<front> <front>
<title abbrev="Close RTP Payload Formats Registry">Closing the RTP Payload F <title abbrev="Closing the RTP Payload Format Registry">Closing the RTP Payl
ormat Media Types IANA Registry</title> oad Format Media Types Registry</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-rtp-payload-regi <seriesInfo name="RFC" value="9751"/>
stry-05"/>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlund"> <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>magnus.westerlund@ericsson.com</email> <email>magnus.westerlund@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2024" month="October" day="18"/> <date year="2025" month="February"/>
<area>WIT</area> <area>WIT</area>
<workgroup>AVTCORE</workgroup> <workgroup>avtcore</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<?line 47?>
<t>A number of authors of RTP Payload Formats and the WG process have <t>A number of authors defining RTP payload formats and the Working Group proces
failed to ensure that the media types for RTP payload formats is s have
registred in the IANA registry "RTP Payload Formats Media Types" as 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 recommended by RFC 8088. To simplify the process and rely only on the
media types registry this document closes the RTP payload specific "Media Types" registry, this document closes the RTP payload-specific
registry. In addition it updates the instruction to payload format registry. In addition, it updates the instruction in RFC 8088 to reflect this ch
authors in RFC 8088 to reflect this change.</t> ange.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-payload-registry/"/>.
</t>
<t>
Discussion of this document takes place on the
AVTCORE Working Group mailing list (<eref target="mailto:avt@ietf.org"/>
),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/avt/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/avt/"/>
.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/gloinul/draft-ietf-avtcore-rtp-payload-
registry"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 58?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<!-- [rfced] For clarity, may we update the text as follows?
Original:
It has been observed that specifications of new Real-time Transport
Protocol (RTP) payload formats often forget to specify registration
of the format's media type in the IANA registry "RTP Payload Formats
Media Types" [RTP-FORMATS] as recommended by [RFC8088].
Perhaps:
Often times, authors defining new Real-time Transport
Protocol (RTP) payload formats forget to specify registration
of the format's media type in the "RTP Payload Format
Media Types" registry [RTP-FORMATS] as recommended by [RFC8088].
-->
<!-- [rfced] Is it correct that this document does not define "other means"? If
yes, perhaps the text should indicate this is out of scope, as I expected this
document to update the Media Types registry in some way to account for this info
rmation.
Original (prior sentence included for context):
This registry is not used for any purpose
other than to track which media types actually have RTP payload
formats. That purpose could be addressed through other means.
-->
<t>It has been observed that specifications of new Real-time Transport Pro tocol <t>It has been observed that specifications of new Real-time Transport Pro tocol
(RTP) payload formats often forget to specify registration of the format's media (RTP) payload formats often forget to specify registration of the format's media
type in the IANA registry "RTP Payload Formats Media Types" <xref target="RTP-FO RMATS"/> as type in the IANA registry "RTP Payload Formats Media Types" <xref target="RTP-FO RMATS"/> as
recommended by <xref target="RFC8088"/>. In practice this has no real impact. T his registry recommended by <xref target="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 is not used for any purpose other than to track which media types actually have
RTP payload formats. That purpose could be addressed through other means.</t> RTP payload formats. That purpose could be addressed through other means.</t>
<t>The Media Types registry <xref target="MEDIA-TYPES"/> is the crucial <!-- [rfced] We find this text a bit tough to follow. Please consider whether
registry to register any Media Type to establish the media type used the suggested text is more clear.
Original:
The Media Types registry [MEDIA-TYPES] is the crucial registry to
register any Media Type to establish the media type used to identify
the format in various signalling usages, to avoid collisions, and to
reference their specifications.
Perhaps:
It is crucial to register media types in the "Media Types" registry
[MEDIA-TYPES] to identify the format in various signalling usages,
avoid collisions, and reference the defining specifications.
-->
<t>The "Media Types" registry <xref target="MEDIA-TYPES"/> is the crucial
registry to register any media type to establish the media type used
to identify the format in various signalling usages, to avoid to identify the format in various signalling usages, to avoid
collisions, and to reference their specifications.</t> collisions, and to reference their specifications.</t>
<t>To resolve this situation, this document performs the following actions
. First, <!-- [rfced] For readability, may we update this text to be a list? In additio
it updates the registry to include known RTP payload formats at the n, may we add that this document has been listed as a reference in the registry
time of writing. Then, it closes the IANA Registry for RTP Payload Formats (see the second bullet)?
Media Types for future registration. Beyond instructing IANA to close
this registry, the instructions to authors in <xref target="RFC8088"/> are updat Original:
ed so that To resolve this situation, this document performs the following
registration in the closed registry is no longer mentioned.</t> actions. First, it updates the registry to include known RTP payload
<t>The origins of the "RTP Payload Formats Media Types" registry, as refer formats at the time of writing. Then, it closes the IANA Registry
enced in for RTP Payload Formats Media Types for future registration. Beyond
instructing IANA to close this registry, the instructions to authors
in [RFC8088] are updated so that registration in the closed registry
is no longer mentioned.
Perhaps:
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.
* removes from [RFC8088] the instruction to register RTP payload
formats in the "RTP Payload Format Media Types" registry.
-->
<t>To resolve this situation, this document performs the following
actions. First, it updates the registry to include known RTP payload
formats at the time of writing. Then, it closes the
"RTP Payload Format Media Types" registry to future registrations. Beyond
instructing IANA to close this registry, the instructions to authors
in <xref target="RFC8088"/> are updated so that registration in the closed re
gistry
is no longer mentioned.
</t>
<t>The origins of the "RTP Payload Format Media Types" registry, as refere
nced in
<xref target="RTP-FORMATS"/>, are unclear. The registry cites <xref target="RFC4 855"/> as providing the <xref target="RTP-FORMATS"/>, are unclear. The registry cites <xref target="RFC4 855"/> as providing the
instructions for its maintenance. However, upon reviewing RFC 4855, no text has instructions for its maintenance. However, upon reviewing RFC 4855, no text has
been found that defines the registry's purpose and operational rules. Further 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 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 to its establishment. It is likely that the registry was created based on
correspondence via email or at the request of an Area Director (AD). email correspondence or at the request of an Area Director.
Consequently, there is no known existing specification for this registry that Consequently, there is no known specification for this registry that
requires updating upon its closure.</t> requires updating upon its closure.</t>
</section> </section>
<section anchor="update-to-how-to-write-an-rtp-payload-format"> <section anchor="update-to-how-to-write-an-rtp-payload-format">
<name>Update to How To Write an RTP Payload Format</name>
<t>How to write an RTP Payload format <xref target="RFC8088"/> mandates in <name>Update to How to Write an RTP Payload Format</name>
its section <!-- [rfced] What does "without affecting its status as part of an informational
on IANA Considerations (Section 7.4) that RTP Payload formats shall RFC" mean? Also, the second sentence is incomplete. Please clarify.
register in RTP Payload Format media types. This paragraph is changed
without affecting its status as part of an informational RFC. Thus Original:
This paragraph is
changed without affecting its status as part of an informational RFC.
Thus removing the need to register in the "RTP Payload Format media
types".
Perhaps:
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.
-->
<t>The IANA Considerations section of "How to write an RTP Payload Format"
(<xref target="RFC8088" section="7.4" sectionFormat="of"/>) mandates
that RTP payload formats shall
be registered in the "RTP Payload Format Media Types" registry. This paragraph i
s changed without affecting its status as part of an Informational RFC. Thus
removing the need to register in the "RTP Payload Format media types".</t> removing the need to register in the "RTP Payload Format media types".</t>
<!-- DNE: OLD text from RFC 8088 is correct. -->
<t>OLD:</t> <t>OLD:</t>
<t>"Since all RTP payload formats contain a media type specification, <blockquote>Since all RTP payload formats contain a media type
they also need an IANA Considerations section. The media type name specification, they also need an IANA Considerations section. The media
must be registered, and this is done by requesting that IANA register type name must be registered, and this is done by requesting that IANA
that media name. When that registration request is written, it shall register that media name. When that registration request is written, it
also be requested that the media type is included under the "RTP shall also be requested that the media type is included under the "RTP
Payload Format media types" sub-registry of the RTP registry Payload Format media types" sub-registry of the RTP registry
(http://www.iana.org/assignments/rtp-parameters)."</t> (http://www.iana.org/assignments/rtp-parameters).</blockquote>
<t>NEW:</t> <t>NEW:</t>
<t>"Since all RTP payload formats contain a media type specification, <blockquote>Since all RTP payload formats contain a media type
they also need an IANA Considerations section. The media type name specification, they also need an IANA Considerations section. The media
must be registered, and this is done by requesting that IANA register type name must be registered, and this is done by requesting that IANA
that media name in the Media Types registry register that media name in the "Media Types" registry
(https://www.iana.org/assignments/media-types/media-types.xhtml)."</t> (<eref target="https://www.iana.org/assignments/media-types/"/>).</blockqu
ote>
</section> </section>
<section anchor="IANA-Consideration"> <section anchor="IANA-Consideration">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to add the following missing RTP Payload types to <t>IANA has added the following RTP payload types to
the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t> the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t>
<table anchor="iana-entries"> <table anchor="iana-entries">
<name>Payload Types to Register in RTP Payload Format Media Types</name> <name>Payload Types Added to the RTP Payload Format Media Types Registry </name>
<thead> <thead>
<tr> <tr>
<th align="left">Media Type</th> <th align="left">Media Type</th>
<th align="left">Sub Type</th> <th align="left">Subtype</th>
<th align="left">Clock Rate (Hz)</th> <th align="left">Clock Rate (Hz)</th>
<th align="left">Channels (audio)</th> <th align="left">Channels (audio)</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">application</td> <td align="left">application</td>
<td align="left">flexfec</td> <td align="left">flexfec</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC8627</td> <td align="left">RFC 8627</td>
</tr> </tr>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">EVRCNW</td> <td align="left">EVRCNW</td>
<td align="left">16000</td> <td align="left">16000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC6884</td> <td align="left">RFC 6884</td>
</tr> </tr>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">EVRCNW0</td> <td align="left">EVRCNW0</td>
<td align="left">16000</td> <td align="left">16000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC6884</td> <td align="left">RFC 6884</td>
</tr> </tr>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">EVRCNW1</td> <td align="left">EVRCNW1</td>
<td align="left">16000</td> <td align="left">16000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC6884</td> <td align="left">RFC 6884</td>
</tr> </tr>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">aptx</td> <td align="left">aptx</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC7310</td> <td align="left">RFC 7310</td>
</tr> </tr>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">opus</td> <td align="left">opus</td>
<td align="left">48000</td> <td align="left">48000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC7587</td> <td align="left">RFC 7587</td>
</tr> </tr>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">G711-0</td> <td align="left">G711-0</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC7650</td> <td align="left">RFC 7650</td>
</tr> </tr>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">flexfec</td> <td align="left">flexfec</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC8627</td> <td align="left">RFC 8627</td>
</tr> </tr>
<tr> <tr>
<td align="left">text</td> <td align="left">text</td>
<td align="left">flexfec</td> <td align="left">flexfec</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC8627</td> <td align="left">RFC 8627</td>
</tr> </tr>
<tr> <tr>
<td align="left">text</td> <td align="left">text</td>
<td align="left">ttml+xml</td> <td align="left">ttml+xml</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC8759</td> <td align="left">RFC 8759</td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">VP8</td> <td align="left">VP8</td>
<td align="left">90000</td> <td align="left">90000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC7741</td> <td align="left">RFC 7741</td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">AV1</td> <td align="left">AV1</td>
<td align="left">90000</td> <td align="left">90000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> <td align="left">
<xref target="AV1-Media-Type"/></td> <xref target="AV1-Media-Type"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">HEVC</td> <td align="left">HEVC</td>
<td align="left">90000</td> <td align="left">90000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC7798</td> <td align="left">RFC 7798</td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">smpte291</td> <td align="left">smpte291</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC8331</td> <td align="left">RFC 8331</td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">VVC</td> <td align="left">VVC</td>
<td align="left">90000</td> <td align="left">90000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC9328</td> <td align="left">RFC 9328</td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">EVC</td> <td align="left">EVC</td>
<td align="left">90000</td> <td align="left">90000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC9584</td> <td align="left">RFC 9584</td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">flexfec</td> <td align="left">flexfec</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC8627</td> <td align="left">RFC 8627</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>IANA is requested to update the following RTP Payload types in the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t> <t>IANA has updated the following entries in the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t>
<table anchor="iana-update-entries"> <table anchor="iana-update-entries">
<name>Payload Types to update in RTP Payload Format Media Types</name> <name>Payload Types Updated in RTP Payload Format Media Types Registry</ name>
<thead> <thead>
<tr> <tr>
<th align="left">Media Type</th> <th align="left">Media Type</th>
<th align="left">Sub Type</th> <th align="left">Subtype</th>
<th align="left">Clock Rate (Hz)</th> <th align="left">Clock Rate (Hz)</th>
<th align="left">Channels (audio)</th> <th align="left">Channels (audio)</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">audio</td> <td align="left">audio</td>
<td align="left">MP4A-LATM</td> <td align="left">MP4A-LATM</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC6416</td> <td align="left">RFC 6416</td>
</tr> </tr>
<tr> <tr>
<td align="left">video</td> <td align="left">video</td>
<td align="left">MP4V-ES</td> <td align="left">MP4V-ES</td>
<td align="left">90000</td> <td align="left">90000</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">RFC6416</td> <td align="left">RFC 6416</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>IANA is further requested to close the "RTP Payload Format Media <!-- [rfced] We have updated the notes slightly. If they are accepted, we will
Types" registry <xref target="RTP-FORMATS"/> for any further registrations. IANA ask IANA to update the registry accordingly.
should add the following to the existing note for the registry:</t>
Original:
NEW:
"This registry has been closed as it was considered redundant as all
RTP Payload formats are part of the Media Types registry
(https://www.iana.org/assignments/media-types/media-types.xhtml).
For further motivation see (RFC-TBD1)."
Current:
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.
Original:
NEW: It was previously stated that registration procedures and a
registration template can be found in [RFC4855]. This is not
actually the case as discussed by [RFC-TBD1].
Current:
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.
-->
<t>IANA has also closed the "RTP Payload Format Media
Types" registry <xref target="RTP-FORMATS"/> to any further
registrations. IANA added the following to the registry note:</t>
<t>NEW:</t> <t>NEW:</t>
<t>"This registry has been closed as it was considered redundant as all <blockquote>This registry has been closed; it was considered redundant
RTP Payload formats are part of the Media Types registry because all RTP payload formats are part of the <eref target="https://www.
(https://www.iana.org/assignments/media-types/media-types.xhtml). For iana.org/assignments/media-types">[Media Types registry]</eref>.
further motivation see (RFC-TBD1)."</t> See RFC 9751 for further details.</blockquote>
<t>In addition, it is requested that the existing note of "RTP Payload For
mat Media <t>In addition, IANA updated the note in the "RTP Payload
Types" registry <xref target="RTP-FORMATS"/> is changed in the following way:</t Format Media Types" registry <xref target="RTP-FORMATS"/> as
> follows:</t>
<t>OLD:
Registration procedures and a registration template can be found in <xref target <t>OLD:</t>
="RFC4855"/>.</t> <blockquote>Registration procedures and a registration template can be
<t>NEW: found in <xref target="RFC4855"/>.</blockquote>
It was previously stated that registration procedures and a registration
template can be found in <xref target="RFC4855"/>. This is not actually the cas <t>NEW:</t>
e as <blockquote>It was previously stated that registration procedures and a
discussed by [RFC-TBD1].</t> registration template can be found in <xref target="RFC4855"/>. As docume
<t>RFC-Editor Note: Please replace RFC-TBD1 with the RFC number of this nted in RFC 9751, this is not the case.</blockquote>
specification and then remove this note.</t>
</section> </section>
<section anchor="Security-Considerations"> <section anchor="Security-Considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document has no security considerations as it defines an administr ative rule change.</t> <t>This document has no security considerations as it defines an administr ative rule change.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <!-- [rfced] Note that the reference to RFC 2119 has been removed as it was not
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> cited in the document and the capitalized keywords were not used.
<front> -->
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <!-- [RFC2119] <xi:include href="https://bib.ietf.org/public/rfc/bibxml/r
le> eference.RFC.2119.xml"/> -->
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="March" year="1997"/> 088.xml"/>
<abstract>
<t>In many standards track documents several words are used to sig <reference anchor="RTP-FORMATS" target="https://www.iana.org/assignments
nify the requirements in the specification. These words are often capitalized. T /rtp-parameters">
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8088" target="https://www.rfc-editor.org/info/rfc8
088" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8088.xml">
<front>
<title>How to Write an RTP Payload Format</title>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<date month="May" year="2017"/>
<abstract>
<t>This document contains information on how best to write an RTP
payload format specification. It provides reading tips, design practices, and pr
actical tips on how to produce an RTP payload format specification quickly and w
ith good results. A template is also included with instructions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8088"/>
<seriesInfo name="DOI" value="10.17487/RFC8088"/>
</reference>
<reference anchor="RTP-FORMATS" target="https://www.iana.org/assignments
/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-2">
<front> <front>
<title>IANA's registry for RTP Payload Format Media Types</title> <title>RTP Payload Format Media Types</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date year="2023" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="MEDIA-TYPES" target="https://www.iana.org/assignments /media-types/media-types.xhtml"> <reference anchor="MEDIA-TYPES" target="https://www.iana.org/assignments /media-types">
<front> <front>
<title>IANA's registry for Media Types</title> <title>Media Types</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date year="2023" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="AV1-Media-Type" target="https://www.iana.org/assignme nts/media-types/video/AV1"> <reference anchor="AV1-Media-Type" target="https://www.iana.org/assignme nts/media-types/video/AV1">
<front> <front>
<title>IANA Media Type Entry for video/AV1</title> <title>video/AV1</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date year="2021" month="January"/>
</front> </front>
</reference> </reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4855" target="https://www.rfc-editor.org/info/rfc4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
855" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"> 855.xml"/>
<front>
<title>Media Type Registration of RTP Payload Formats</title>
<author fullname="S. Casner" initials="S." surname="Casner"/>
<date month="February" year="2007"/>
<abstract>
<t>This document specifies the procedure to register RTP payload f
ormats as audio, video, or other media subtype names. This is useful in a text-b
ased format description or control protocol to identify the type of an RTP trans
mission. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4855"/>
<seriesInfo name="DOI" value="10.17487/RFC4855"/>
</reference>
</references> </references>
</references> </references>
<?line 182?>
<section anchor="acknowledgments"> <section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The author likes to thank Jonathan Lennox, Zaheduzzaman Sarker, <t>The author thanks <contact fullname="Jonathan Lennox"/>,
Bernard Aboba, Elwyn Davies, Wes Hardaker, Gunter Van de Velde, Éric <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Bernard
Vyncke, Mahesh Jethanandani, and Hyunsik Yang for review and editorial fixes.</ Aboba"/>, <contact fullname="Elwyn Davies"/>, <contact fullname="Wes
t> Hardaker"/>, <contact fullname="Gunter Van de Velde"/>, <contact
fullname="Éric Vyncke"/>, <contact fullname="Mahesh Jethanandani"/>, and
<contact fullname="Hyunsik Yang"/> for their reviews and editorial fixes.<
/t>
</section> </section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA91Y224bORJ951cU5IdNMGpZcuKbgAFGsZXEQZwYttbG7GAf
qG5KItwiNSRbsuLkA/a79se2imS3umXlslksFlgMkJG7q4t1PXWKSZKwTKeK
z0UfMsMnLpHCTRK+dKk2IjFukSz4Otc8S4yYSuvMOukeMiddjl+c5dpKNQU3
E3A9uoKrIAqvtZlzB5cikxxG64WwcDH4MIDrqILx8diIZVCw61O7ES0WGXfC
9uGke3LCUu76YF3G5ML0wZnCuoNu97R7wFbTPgxuR2cfr4eMG8H7cHcxYrYY
z6W1UiuHZvThYjh6DbAHPLe6Dy2pMrEQ+I9yrTa0Lgav8H/a4K/r0esWY0uh
CtFnAFOji8XmAIA5l3kfME6/UcA62kxJSrpZMe7DNNdSFfn+D0aUMV64mTZ9
lqASkAq9hcsO3AnrhMkLldHjkKRLPlWF3XqFp/dhaGRqrVb0QATz5l64s6qE
fxNRqJPqOWNSTXy45dI7ef367OXJ4WGfMaa2nh/0eqfxJ+UBRYDSlrz+eH05
GN3QKwDHzVRgfloz5xa2v7+/Wq06kitO4dnnmIapmmOo7X6IgkGP0LDtPzsP
MzfP95oPk4NWOCNUXovq6S8WyhACOvKdEgzfUzH14YNewkH34AW5cTk8vxgk
o9+vhv+2G3PSnlBlNX4HB75v7w8YN7jtJV4sIbH/xL6lzITeR31P7aoZAkNV
Wrf1QbDtHVdkW4+xJEmAj9EXnjrGBqCK+VgY0BMIxWzp567O5irzgHH3BhZG
p8JamPGlYBMsWYGvNAhlCyNQCBNIkt4N8G5UeY49BJOoVVoWY4s6pPLfed+q
iLd2GVNPAXDSgY0xJ0TIYLymcve404GRBivni1xO1l53aTp5Y0S+Bq38P/SS
1Q2uznczaQHBtqDcQErIZyvkLN2xC5HKiUxLZ9YduFDAs0w6xDCQDiIe+i8R
KRACU/8K49aMCSvzgNEo/SApIya5SF2wJ51xNRUdFvI5l1mWC8b28FBndBZV
P+7J2p9fGLtwmDILYyEU6LEVZkmJo3SV9nOS9CWgxArBnOeJk3MBI8OVXWjj
4Mpop1Ods2fo//Mn+dQTh8rxLyx1sjooXpfh9PpJPYUhfIPd5ePOKO4/WwKP
jzVU+/JlR0mgRMDAL186QMlZUAfIVISAUlwUBZnngPWCr7B26EUF9pIEMI9W
eG+xgtawKMyCJqFGmw1F0ueTeuseVjOZzho9gEoLnmO5+b7Z0Q10JCaj1Jrq
IkfbBdWRwaL1ycKBNp3FA+cCs4JFMMKI1Yd2FbjHxxpKYlhkqL8Ui0/ynG1q
XMdvRPCrBizU19bxcS7tbKurfSwYCkgaxGWHBV8okUtupMahR8CGfhPjKCyf
CtsmrXypZcawklAzFV07IIwvdGGE8pkR0mzVJrlLMlbny5g7KzGu9LK91awL
YcgaG+3Kc70iI3gaNMFraaxrs63urEdFqjQvMgH3Sq/UTgALWMd8l2Bdrwx2
vJpSJgXaIxuI0SBTXxl9ltUzSTKTwhGs1juoA6/EWqtsgyTolteONvsDmasX
b3sbdqzPwAZoat0ByMJiPBDXtMcH1mjf2KP+nGwTLt8gkGsEJipNRbIii+Wp
jZzKgCz07fc7emM6t5uSII/ZVrO3g8WYKcGND/zGplRSVr13RJE8MtAMwCEZ
CTBrRIXiLdEU5GEKgYzjkR14q1diKUwbo4LeIwGWwtcRoTNpbZPfTjx4dGUe
XSe6UBFaMzGRaqu0EPPKJqei11ioPrQIPqbIBZVmYajFGXdOzBfOlrgitvWk
CFk+KwQqsBnGGA+9jO1chc/6bkVtVUtTnnBWOcpeLu9pIlbzu4riisdzCEo5
JR3pKtJi7EKMSOZ7dYmp8/SVeHil4M8CT/LkQsEANcC5RFx2KPJscP68w84w
6CSkXB6KFDMZ6ih0nHhACyjWDRDwaWoUeFmlfxao34by9Xiz8NPX+mLFLqKJ
uQd/9dVNUcLUEkW4w66lVOzoR8ZIBkVXu2Qi2NXbZ44Z9Vgiw8lW+NpiaIjv
UHIZAdPEUfvsJryH487L5yH2Tw9ALTNEUFaBtNxlan3YxOlFRHxq+GIGFWnI
2ArXHV044JOJCNDh7XTcIVhz/1GZs2rT8LWJTpLegobrHHsorpBKiKwxQiJA
7GjyuoktSsbH9+e4lLRuJNUQurgTY1NcA7EhgdeHT6Mi2oh3Yu3Xw2AO3x3t
mAxkAKPmKKMtjc1xLaV5WzoisjiUKJR+sChBXCLWdfAfnaqxFWxZ/yioJq14
1h3OgiDZwNGyPVAzFZeLAyOk2rsyrnqoJGpbE5jsCiMqw47PPAkJgWffCDzg
el1tsSUkU+ArsvOMdpQf3wSfd3Dp/jC8+z9PZVnYu7hWCNnPr50+hMTgd7j6
uEdPk8ZTovMk6kGwKhFNXHGL7viLFBpXtW4MhNRp9rU+3TmLt2k2NvDnOlf8
DDfFuPx5lmtkwdcEtM/efnpOTxB/lMgR83iRSU2Priuu9xlV8QUuahHiPwOu
Ow8IUPiL/iOAPTo4DnL0OT4b3l6ffbjDH72jbreL/w9yRycnL3fIdX9UsPd9
Qb5wD+FtEDh+0es2BPQCsfQz0oO6muPDk6YDb457vaTr/YsSR4dNPfUgbEXB
M45vhSkKOKyuXx7meU3i+PDUS/i7Anx2e3WC/552g7HBkuOXvYbM4LbXkHl8
bF5y4Oiri78d3p491Xl60hCySG3EwWkvOBdse/Giee7tUz2nLw6aenacdXoY
U1bKbOK0FajHPuxRvybYpEZSW9Ady6+tsiNGsVcic//q9G20DO419tdWDvG/
1tfatYhUpNGxTzv1GxP1f9OpsTwvr14OkveD0WUtrEcve0eNyKPQbTK82c5Q
lKvCH0Lx3SzEiP1cDqokTAK/bibDbzTfDjT7TqCrq4HNAZuJj6yMzmd25jf7
p1BNJB8fVKxXaSci2d3Q8X41ahsXFJurnbiY4Z/IJjx3j4PDb2sZ8gSOyzE+
J56xi2zSPlWSwP/evKO4sjJMc+3kMiC/FViHWB/J6NV5z4/F2lWaZ0jNJipp
UTNqaPrPJ3FDlsvO2+RoxSkDnrde19mcv1nMClo/iGjwJtejLS6nuk2RzoxF
XBBR+R9xNf17J6b1IuRsQXumLiwuZMTMS0fNDx/JfuBICFtCvNqq7qf8ds9p
ObUskzYt/N0TsqU/yrSQtfR7iFnB8vyg6ZL5ChdwS3WKxyJOlLJA+0agmLgw
b+6biYqx5l4X75iJGuN+Ea93KJ0doka4KRXIk9dP6VH5pkmR7Be6e6hfCMVb
PlsqSpuKQseUCzunqptLFSOK5tBuvrl6pZvXMU/vybRBSvsqrt5TX/qMeVIa
Llj8Xh0WePz0Ht7hLuWvCt8LpfRDG/7GZ5jFT584ro5ww829MG0Gr4RR3GQw
GOsxb8MwX60VnPOlpPuzO1T4Ft9ykoU3haKxdIufZwJuRZ6JNvzzH0amDG7X
Kr3HPy/xEDuDd4KOphVVycCI364LDMI9/I5ueawJFxz+nfDplbj6TeQDdi77
F56kmHB5HAAA
<!-- [rfced] We have used "payload format" (lowercase) when not referring to the registry name. We believe this matches the use in other RFCs defining RTP payl oad formats. Please let us know if any changes are needed.
--> -->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back>
</rfc> </rfc>
 End of changes. 67 change blocks. 
280 lines changed or deleted 293 lines changed or added

This html diff was produced by rfcdiff 1.48.