<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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> <titleabbrev="Closeabbrev="Closing the RTP PayloadFormatsFormat Registry">Closing the RTP Payload Format Media TypesIANARegistry</title> <seriesInfoname="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> <dateyear="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 authorsofdefining RTPPayload Formatspayload formats and theWGWorking Group process have failed to ensure that the media typesfor RTP payload formats is registredare registered in the IANAregistry"RTP PayloadFormatsFormat Media Types" registry as recommended by RFC 8088. To simplify the process and rely only on themedia types registry"Media Types" registry, this document closes the RTPpayload specificpayload-specific registry. Inadditionaddition, it updates the instructionto payload format authorsin 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, maybe found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-payload-registry/"/>. </t> <t> Discussionwe 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 documenttakes place ondoes not define "other means"? If yes, perhaps theAVTCORE Working Group mailing list (<eref target="mailto:avt@ietf.org"/>), whichtext should indicate this isarchived at <eref target="https://mailarchive.ietf.org/arch/browse/avt/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/avt/"/>. </t> <t>Sourceout of scope, as I expected this document to update the Media Types registry in some way to account for thisdraft and an issue tracker caninformation. 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 befound 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"/>. Inpracticepractice, 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 longermentioned.</t>mentioned. </t> <t>The origins of the "RTP PayloadFormatsFormat 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 oncorrespondence viaemail correspondence or at the request of an AreaDirector (AD).Director. Consequently, there is no knownexistingspecification 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 HowToto 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 Payloadformat <xref target="RFC8088"/>Format" (<xref target="RFC8088" section="7.4" sectionFormat="of"/>) mandatesin its section on IANA Considerations (Section 7.4)that RTPPayloadpayload formats shallregisterbe registered inRTPthe "RTP Payload Formatmedia types.Media Types" registry. This paragraph is changed without affecting its status as part of aninformationalInformational 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 theMedia 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>IANAis requested to addhas added the followingmissingRTPPayloadpayload types to the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t> <table anchor="iana-entries"> <name>Payload Types Added toRegister inthe RTP Payload Format MediaTypes</name>Types Registry</name> <thead> <tr> <th align="left">Media Type</th> <thalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC6884</td>align="left">RFC 6884</td> </tr> <tr> <td align="left">audio</td> <td align="left">aptx</td> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC7587</td>align="left">RFC 7587</td> </tr> <tr> <td align="left">audio</td> <td align="left">G711-0</td> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC7650</td>align="left">RFC 7650</td> </tr> <tr> <td align="left">audio</td> <td align="left">flexfec</td> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC8627</td>align="left">RFC 8627</td> </tr> <tr> <td align="left">text</td> <td align="left">flexfec</td> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC8627</td>align="left">RFC 8627</td> </tr> <tr> <td align="left">text</td> <td align="left">ttml+xml</td> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC7798</td>align="left">RFC 7798</td> </tr> <tr> <td align="left">video</td> <td align="left">smpte291</td> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC9584</td>align="left">RFC 9584</td> </tr> <tr> <td align="left">video</td> <td align="left">flexfec</td> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="left">RFC8627</td>align="left">RFC 8627</td> </tr> </tbody> </table> <t>IANAis requested to updatehas updated the followingRTP Payload typesentries in the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>.</t> <table anchor="iana-update-entries"> <name>Payload Typesto updateUpdated in RTP Payload Format MediaTypes</name>Types Registry</name> <thead> <tr> <th align="left">Media Type</th> <thalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="left"> </td>align="left"> </td> <tdalign="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> <tdalign="left"> </td>align="left"> </td> <tdalign="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 tocloseupdate 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"/>forto any further registrations. IANAshould addadded the following to theexisting note for the registry:</t>registry note:</t> <t>NEW:</t><t>"This<blockquote>This registry has beenclosed asclosed; it was considered redundantasbecause all RTPPayloadpayload formats are part of theMedia<eref target="https://www.iana.org/assignments/media-types">[Media Typesregistry (https://www.iana.org/assignments/media-types/media-types.xhtml). Forregistry]</eref>. See RFC 9751 for furthermotivation see (RFC-TBD1)."</t>details.</blockquote> <t>In addition,it is requested thatIANA updated theexistingnoteofin the "RTP Payload Format Media Types" registry <xref target="RTP-FORMATS"/>is changed in the following way:</t> <t>OLD: Registrationas follows:</t> <t>OLD:</t> <blockquote>Registration procedures and a registration template can be found in <xreftarget="RFC4855"/>.</t> <t>NEW: Ittarget="RFC4855"/>.</blockquote> <t>NEW:</t> <blockquote>It was previously stated that registration procedures and a registration template can be found in <xref target="RFC4855"/>.ThisAs documented in RFC 9751, this is notactuallythecase 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 thespecification. These words are often capitalized. This document defines these wordsreference to RFC 2119 has been removed asthey should be interpretedit was not cited inIETF documents. This document specifies an Internet Best Current Practices fortheInternet 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>Thisdocumentcontains 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 quicklyandwith 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?><sectionanchor="acknowledgments">anchor="acknowledgments" numbered="false"> <name>Acknowledgments</name> <t>The authorlikes to thank Jonathan Lennox, Zaheduzzaman Sarker, Bernard Aboba, Elwyn Davies, Wes Hardaker, Gunterthanks <contact fullname="Jonathan Lennox"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Bernard Aboba"/>, <contact fullname="Elwyn Davies"/>, <contact fullname="Wes Hardaker"/>, <contact fullname="Gunter Van deVelde, Éric Vyncke, Mahesh Jethanandani,Velde"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Mahesh Jethanandani"/>, andHyunsik Yang<contact fullname="Hyunsik Yang"/> forreviewtheir 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>