<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-avtcore-rtp-payload-registry-05" number="9751" category="std" consensus="true" submissionType="IETF" obsoletes="" updates="8088" symRefs="true" sortRefs="true" tocInclude="true" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->

  <front>
    <title abbrev="Close abbrev="Closing the RTP Payload Formats Format Registry">Closing the RTP Payload Format Media Types IANA Registry</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-rtp-payload-registry-05"/> name="RFC" value="9751"/>
    <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
      <organization>Ericsson</organization>
      <address>
        <email>magnus.westerlund@ericsson.com</email>
      </address>
    </author>
    <date year="2024" month="October" day="18"/> year="2025" month="February"/>
    <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>
      <?line 47?>

<t>A number of authors of defining RTP Payload Formats payload formats and the WG Working Group process have
failed to ensure that the media types for RTP payload formats is
registred are
registered in the IANA registry "RTP Payload Formats Format Media Types" registry as
recommended by RFC 8088. To simplify the process and rely only on the
media types registry
"Media Types" registry, this document closes the RTP payload specific payload-specific
registry. In addition addition, it updates the instruction to payload format
authors in RFC 8088 to reflect this change.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document

  </front>
  <middle>
<section anchor="introduction">
      <name>Introduction</name>
<!-- [rfced] For clarity, may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-payload-registry/"/>.
      </t>
      <t>
        Discussion 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 takes place on does not define "other means"?  If yes, perhaps the
        AVTCORE Working Group mailing list (<eref target="mailto:avt@ietf.org"/>),
        which text should indicate this is archived at <eref target="https://mailarchive.ietf.org/arch/browse/avt/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/avt/"/>.
      </t>
      <t>Source out of scope, as I expected this document to update the Media Types registry in some way to account for this draft and an issue tracker can information.

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 found at
        <eref target="https://github.com/gloinul/draft-ietf-avtcore-rtp-payload-registry"/>.</t>
    </note>
  </front>
  <middle>
    <?line 58?>

<section anchor="introduction">
      <name>Introduction</name> addressed through other means.
-->

      <t>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" <xref target="RTP-FORMATS"/> as
recommended by <xref target="RFC8088"/>.  In practice 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. That purpose could be addressed through other means.</t>
      <t>The
<!-- [rfced]  We find this text a bit tough to follow.  Please consider whether the suggested text is more clear.

Original:
   The Media Types registry <xref target="MEDIA-TYPES"/> [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
collisions, and to reference their specifications.</t>
      <t>To

<!-- [rfced] For readability, may we update this text to be a list?   In addition, may we add that this document has been listed as a reference in the registry (see the second bullet)?

Original:
   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 IANA Registry
   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 registry
   is no longer mentioned.</t> mentioned.
</t>
      <t>The origins of the "RTP Payload Formats Format Media Types" registry, as referenced in
<xref target="RTP-FORMATS"/>, are unclear. The registry cites <xref target="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
correspondence via
email correspondence or at the request of an Area Director (AD). Director.
Consequently, there is no known existing specification for this registry that
requires updating upon its closure.</t>
    </section>
    <section anchor="update-to-how-to-write-an-rtp-payload-format">

      <name>Update to How To to Write an RTP Payload Format</name>
      <t>How
<!-- [rfced] What does "without affecting its status as part of an informational RFC" mean?  Also, the second sentence is incomplete.  Please clarify.

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"/> Format" (<xref target="RFC8088" section="7.4" sectionFormat="of"/>) mandates in its section
on IANA Considerations (Section 7.4)
that RTP Payload payload formats shall
register
be registered in RTP the "RTP Payload Format media types. Media Types" registry. This paragraph is changed without affecting its status as part of an informational Informational RFC. Thus
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>"Since
      <blockquote>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)."</t>
      (http://www.iana.org/assignments/rtp-parameters).</blockquote>

      <t>NEW:</t>
      <t>"Since
      <blockquote>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 "Media Types" registry
(https://www.iana.org/assignments/media-types/media-types.xhtml)."</t>
      (<eref target="https://www.iana.org/assignments/media-types/"/>).</blockquote>
    </section>
    <section anchor="IANA-Consideration">
      <name>IANA Considerations</name>
      <t>IANA is requested to add has added the following missing RTP Payload payload types to
the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t>

      <table anchor="iana-entries">
        <name>Payload Types Added to Register in the RTP Payload Format Media Types</name> Types Registry</name>
        <thead>
          <tr>
            <th align="left">Media Type</th>
            <th align="left">Sub Type</th> align="left">Subtype</th>
            <th align="left">Clock Rate (Hz)</th>
            <th align="left">Channels (audio)</th>
            <th align="left">Reference</th>
         </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">application</td>
            <td align="left">flexfec</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC8627</td> align="left">RFC 8627</td>
          </tr>
          <tr>
            <td align="left">audio</td>
            <td align="left">EVRCNW</td>
            <td align="left">16000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC6884</td> align="left">RFC 6884</td>
          </tr>
          <tr>
            <td align="left">audio</td>
            <td align="left">EVRCNW0</td>
            <td align="left">16000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC6884</td> align="left">RFC 6884</td>
          </tr>
          <tr>
            <td align="left">audio</td>
            <td align="left">EVRCNW1</td>
            <td align="left">16000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC6884</td> align="left">RFC 6884</td>
          </tr>
          <tr>
            <td align="left">audio</td>
            <td align="left">aptx</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC7310</td> align="left">RFC 7310</td>
          </tr>
          <tr>
            <td align="left">audio</td>
            <td align="left">opus</td>
            <td align="left">48000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC7587</td> align="left">RFC 7587</td>
          </tr>
          <tr>
            <td align="left">audio</td>
            <td align="left">G711-0</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC7650</td> align="left">RFC 7650</td>
          </tr>
          <tr>
            <td align="left">audio</td>
            <td align="left">flexfec</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC8627</td> align="left">RFC 8627</td>
          </tr>
          <tr>
            <td align="left">text</td>
            <td align="left">flexfec</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC8627</td> align="left">RFC 8627</td>
          </tr>
          <tr>
            <td align="left">text</td>
            <td align="left">ttml+xml</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC8759</td> align="left">RFC 8759</td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">VP8</td>
            <td align="left">90000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC7741</td> align="left">RFC 7741</td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">AV1</td>
            <td align="left">90000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">
              <xref target="AV1-Media-Type"/></td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">HEVC</td>
            <td align="left">90000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC7798</td> align="left">RFC 7798</td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">smpte291</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC8331</td> align="left">RFC 8331</td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">VVC</td>
            <td align="left">90000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC9328</td> align="left">RFC 9328</td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">EVC</td>
            <td align="left">90000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC9584</td> align="left">RFC 9584</td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">flexfec</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC8627</td> align="left">RFC 8627</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is requested to update has updated the following RTP Payload types entries in the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t>
      <table anchor="iana-update-entries">
        <name>Payload Types to update Updated in RTP Payload Format Media Types</name> Types Registry</name>
        <thead>
          <tr>
            <th align="left">Media Type</th>
            <th align="left">Sub Type</th> align="left">Subtype</th>
            <th align="left">Clock Rate (Hz)</th>
            <th align="left">Channels (audio)</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">audio</td>
            <td align="left">MP4A-LATM</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC6416</td> align="left">RFC 6416</td>
          </tr>
          <tr>
            <td align="left">video</td>
            <td align="left">MP4V-ES</td>
            <td align="left">90000</td>
            <td align="left"> </td> align="left"> </td>
            <td align="left">RFC6416</td> align="left">RFC 6416</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is further requested
<!-- [rfced] We have updated the notes slightly.  If they are accepted, we will ask IANA to close update the registry accordingly.

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"/> for to any further
      registrations. IANA
should add added the following to the existing note for the registry:</t> registry note:</t>

      <t>NEW:</t>
      <t>"This
      <blockquote>This registry has been closed as closed; it was considered redundant as
      because all RTP Payload payload formats are part of the Media <eref target="https://www.iana.org/assignments/media-types">[Media Types registry
(https://www.iana.org/assignments/media-types/media-types.xhtml). For registry]</eref>.
      See RFC 9751 for further motivation see (RFC-TBD1)."</t> details.</blockquote>

      <t>In addition, it is requested that IANA updated the existing note of in the "RTP Payload
      Format Media Types" registry <xref target="RTP-FORMATS"/> is changed in the following way:</t>
      <t>OLD:
Registration as
      follows:</t>

      <t>OLD:</t>
      <blockquote>Registration procedures and a registration template can be
      found in <xref target="RFC4855"/>.</t>
      <t>NEW:
It target="RFC4855"/>.</blockquote>

      <t>NEW:</t>
      <blockquote>It was previously stated that registration procedures and a
      registration template can be found in <xref target="RFC4855"/>.  This  As documented in RFC 9751, this is not actually the case as
discussed by [RFC-TBD1].</t>
      <t>RFC-Editor Note: Please replace RFC-TBD1 with the RFC number of this
specification and then remove this note.</t> case.</blockquote>

    </section>
    <section anchor="Security-Considerations">
      <name>Security Considerations</name>
      <t>This document has no security considerations as it defines an administrative rule change.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in
<!-- [rfced] Note that the specification. These words are often capitalized. This document defines these words reference to RFC 2119 has been removed as they should be interpreted it was not cited in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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/rfc8088" 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 practical tips on how to produce an RTP payload format specification quickly and with 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> the capitalized keywords were not used.
-->
<!-- [RFC2119]        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8088.xml"/>

        <reference anchor="RTP-FORMATS" target="https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-2"> target="https://www.iana.org/assignments/rtp-parameters">
          <front>
            <title>IANA's registry for RTP
            <title>RTP Payload Format Media Types</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date year="2023" month="November"/>
          </front>
        </reference>
        <reference anchor="MEDIA-TYPES" target="https://www.iana.org/assignments/media-types/media-types.xhtml"> target="https://www.iana.org/assignments/media-types">
          <front>
            <title>IANA's registry for Media
            <title>Media Types</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date year="2023" month="November"/>
          </front>
        </reference>

        <reference anchor="AV1-Media-Type" target="https://www.iana.org/assignments/media-types/video/AV1">
          <front>
            <title>IANA Media Type Entry for video/AV1</title>
            <title>video/AV1</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date year="2021" month="January"/>
          </front>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC4855" target="https://www.rfc-editor.org/info/rfc4855" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4855.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 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. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4855"/>
          <seriesInfo name="DOI" value="10.17487/RFC4855"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"/>
      </references>
    </references>
    <?line 182?>

<section anchor="acknowledgments"> anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>The author likes to thank Jonathan Lennox, Zaheduzzaman Sarker,
 Bernard Aboba, Elwyn Davies, Wes Hardaker, Gunter thanks <contact fullname="Jonathan Lennox"/>,
      <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Bernard
      Aboba"/>, <contact fullname="Elwyn Davies"/>, <contact fullname="Wes
      Hardaker"/>, <contact fullname="Gunter Van de Velde, Éric
 Vyncke, Mahesh Jethanandani, Velde"/>, <contact
      fullname="Éric Vyncke"/>, <contact fullname="Mahesh Jethanandani"/>, and Hyunsik Yang
      <contact fullname="Hyunsik Yang"/> for review their reviews and editorial fixes.</t>
    </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 payload 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>