<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" docName="draft-ietf-payload-vp9-16" number="9628" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" prepTime="2025-03-27T17:04:31" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-payload-vp9-16" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9628" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="RTP Payload Format for VP9">RTP Payload Format for VP9 Video</title>
    <seriesInfo name="RFC" value="9628" stream="IETF"/>
    <author fullname="Justin Uberti" initials="J." surname="Uberti">
      <organization showOnFrontPage="true">OpenAI</organization>
      <address>
        <postal>
          <street>1455 3rd St</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94158</code>
          <country>United States of America</country>
        </postal>
        <email>justin@uberti.name</email>
      </address>
    </author>
    <author fullname="Stefan Holmer" initials="S." surname="Holmer">
      <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization>
      <address>
        <postal>
          <street>Kungsbron 2</street>
          <code>111 22</code>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <email>holmer@google.com</email>
      </address>
    </author>
    <author fullname="Magnus Flodman" initials="M." surname="Flodman">
      <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization>
      <address>
        <postal>
          <street>Kungsbron 2</street>
          <code>111 22</code>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <email>mflodman@google.com</email>
      </address>
    </author>
    <author fullname="Danny Hong" initials="D." surname="Hong">
      <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization>
      <address>
        <postal>
          <street>315 Hudson St.</street>
          <city>New York</city>
          <region>NY</region>
          <code>10013</code>
          <country>United States of America</country>
        </postal>
        <email>dannyhong@google.com</email>
      </address>
    </author>
    <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
      <organization abbrev="8x8 / Jitsi" showOnFrontPage="true">8x8, Inc. / Jitsi</organization>
      <address>
        <postal>
          <street/>
          <city>Jersey City</city>
          <region>NJ</region>
          <code>07302</code>
          <country>United States of America</country>
        </postal>
        <email>jonathan.lennox@8x8.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RAI</area>
    <workgroup>AVTCore Working Group</workgroup>
    <keyword>RTP</keyword>
    <keyword>VP9</keyword>
    <keyword>WebM</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This specification describes an RTP payload format for the VP9 video codec.
      The payload format has wide applicability as it supports applications
      from low bitrate peer-to-peer usage to high bitrate video
      conferences.  It includes provisions for temporal and spatial scalability.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9628" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions">Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-format-description">Media Format Description</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-payload-format">Payload Format</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-header-usage">RTP Header Usage</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vp9-payload-descriptor">VP9 Payload Descriptor</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scalability-structure-ss">Scalability Structure (SS)</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-frame-fragmentation">Frame Fragmentation</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scalable-encoding-considera">Scalable Encoding Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-of-a-vp9-rtp-stream">Example of a VP9 RTP Stream</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2">
                  <li pn="section-toc.1-1.4.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reference-picture-use-for-s">Reference Picture Use for Scalable Structure</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feedback-messages-and-heade">Feedback Messages and Header Extensions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reference-picture-selection">Reference Picture Selection Indication (RPSI)</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-full-intra-request-fir">Full Intra Request (FIR)</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-layer-refresh-request-lrr">Layer Refresh Request (LRR)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-payload-format-parameters">Payload Format Parameters</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-parameters">SDP Parameters</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2">
                  <li pn="section-toc.1-1.6.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mapping-of-media-subtype-pa">Mapping of Media Subtype Parameters to SDP</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.2.1"><xref derivedContent="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-offer-answer-considerations">Offer/Answer Considerations</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-definition">Media Type Definition</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-congestion-control">Congestion Control</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document describes an <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref> payload specification applicable to the
      transmission of video streams encoded using the VP9 video codec <xref target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/>. The format described in this
      document can be used both in peer-to-peer and video conferencing
      applications.</t>
      <t indent="0" pn="section-1-2">The VP9 video codec was developed by Google and is the successor to
      its earlier <xref target="RFC6386" format="default" sectionFormat="of" derivedContent="RFC6386">VP8</xref> codec.
      Above the compression improvements and other general enhancements to
      VP8, VP9 is also designed in a way that allows spatially scalable video
      encoding.</t>
    </section>
    <section anchor="conventions" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions">Conventions</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
    </section>
    <section anchor="mediaFormatDescription" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-media-format-description">Media Format Description</name>
      <t indent="0" pn="section-3-1">The VP9 codec can maintain up to eight reference frames, of
      which up to three can be referenced by any new frame.</t>
      <t indent="0" pn="section-3-2">VP9 also allows a frame to use another frame of a different
      resolution as a reference frame.  (Specifically, a frame may use
      any references whose width and height are between 1/16th that of
      the current frame and twice that of the current frame,
      inclusive.)  This allows internal resolution changes without
      requiring the use of keyframes.</t>
      <t indent="0" pn="section-3-3">These features together enable an encoder to
      implement various forms of coarse-grained scalability,
      including temporal, spatial, and quality scalability modes, as
      well as combinations of these, without the need for explicit
      scalable coding tools.</t>
      <t indent="0" pn="section-3-4">Temporal layers define different frame rates of video;
      spatial and quality layers define different and possibly dependent
      representations of a single input frame.  Spatial layers allow
      a frame to be encoded at different resolutions, whereas
      quality layers allow a frame to be encoded at the same
      resolution but at different qualities (and, thus, with different
      amounts of coding error).  VP9 supports quality layers as
      spatial layers without any resolution changes; hereinafter,
      the term "spatial layer" is used to represent both spatial and
      quality layers.</t>
      <t indent="0" pn="section-3-5">This payload format specification defines how such
      temporal and spatial scalability layers can be described and 
      communicated.</t>
      <t indent="0" pn="section-3-6">Temporal and spatial scalability layers are associated with
	  non-negative integer IDs. The lowest layer of either type has an
	  ID of zero and is sometimes referred to as the "base" temporal or
	  spatial layer.</t>
      <t indent="0" pn="section-3-7">Layers are designed, and <bcp14>MUST</bcp14> be encoded, such that if
      any layer, and all higher layers, are removed from the bitstream
      along either the spatial or temporal dimension, the remaining bitstream is
      still correctly decodable.</t>
      <t indent="0" pn="section-3-8">For terminology, this document uses the term "frame" to refer to a
      single encoded VP9 frame for a particular resolution and/or quality, and
      "picture" to refer to all the representations (frames) at a single
      instant in time.  Thus, a picture consists of one or more frames,
      encoding different spatial layers.</t>
      <t indent="0" pn="section-3-9">Within a picture, a frame with
      spatial-layer ID equal to S, where S &gt; 0, can depend on a frame
      of the same picture with a lower spatial-layer ID.  This "inter-layer"
      dependency can result in additional coding gain compared to the case
      where only "inter-picture" dependency is used, where a frame
      depends on a previously coded frame in time.  For simplicity, this
      payload format assumes that, within a picture and if inter-layer
      dependency is used, a spatial-layer S frame can depend only on the
      immediately previous spatial-layer S-1 frame, when S &gt; 0.
      Additionally, if inter-picture dependency is used, a spatial-layer S
      frame is assumed to only depend on a previously coded spatial-layer S
      frame.</t>
      <t indent="0" pn="section-3-10">Given the above simplifications for inter-layer and inter-picture
      dependencies, a flag (the D bit described below) is used to indicate
      whether a spatial-layer SID frame depends on the spatial-layer SID-1
      frame.  Given the D bit, a receiver only needs to additionally know the
      inter-picture dependency structure for a given spatial-layer frame in
      order to determine its decodability.  Two modes of describing the
      inter-picture dependency structure are possible: "flexible mode" and
      "non-flexible mode".  An encoder can only switch between the two on the
      first packet of a keyframe with a temporal-layer ID equal to zero.</t>
      <t indent="0" pn="section-3-11">In flexible mode, each packet can contain up to three reference indices,
      which identify all frames referenced by the frame transmitted in the
      current packet for inter-picture prediction.  This (along with the D
      bit) enables a receiver to identify if a frame is decodable or not and
      helps it understand the temporal-layer structure.  Since this is
      signaled in each packet, it makes it possible to have very flexible
      temporal-layer hierarchies and scalability structures, which are
      changing dynamically.</t>
      <t indent="0" pn="section-3-12">In non-flexible mode, frames are encoded using a fixed, recurring pattern of dependencies;
      the set of pictures that recur in this pattern is known as a "Picture Group" (or "PG").
      In this mode, the inter-picture dependencies (the reference
      indices) of the PG <bcp14>MUST</bcp14> be pre-specified as part of the 
      Scalability Structure (SS) data.
      Each 
      packet has an index to refer to one of the described pictures
      in the PG from which the pictures referenced by the picture transmitted in the current packet 
      for inter-picture prediction can be identified.</t>
      <aside pn="section-3-13">
        <t indent="0" pn="section-3-13.1">Note: A "Picture Group" or "PG", as used in this document,
	  is not the same thing as the term "Group of Pictures" as
	  it is commonly used in video coding, i.e., to mean an
	  independently decodable run of pictures beginning with a
	  keyframe.</t>
      </aside>
      <t indent="0" pn="section-3-14">The SS data can also be used to specify the resolution of each
      spatial layer present in the VP9 stream for both flexible and non-flexible modes.</t>
    </section>
    <section anchor="payloadFormat" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-payload-format">Payload Format</name>
      <t indent="0" pn="section-4-1">This section describes how the encoded VP9 bitstream is encapsulated
      in RTP. To handle network losses, usage of RTP/AVPF <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/> is <bcp14>RECOMMENDED</bcp14>. All integer fields in this
      specification are encoded as unsigned integers in network octet
      order.</t>
      <section anchor="RTPHeaderUsage" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-rtp-header-usage">RTP Header Usage</name>
        <t keepWithNext="true" indent="0" pn="section-4.1-1">The general RTP payload format for VP9 is depicted
        below.</t>
        <figure anchor="figureRTPHeader" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-general-rtp-payload-format-">General RTP Payload Format for VP9</name>
          <artwork type="" align="left" alt="" pn="section-4.1-2.1">
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V=2|P|X|  CC   |M|     PT      |       sequence number         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           timestamp                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           synchronization source (SSRC) identifier            |
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  |            contributing source (CSRC) identifiers             |
  |                             ....                              |
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  |            VP9 payload descriptor (integer #octets)           |
  :                                                               :
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  +                                                               |
  :                          VP9 payload                          :
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               :    OPTIONAL RTP padding       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t keepWithPrevious="true" indent="0" pn="section-4.1-3">See <xref target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/> for more information on the VP9 payload descriptor;
        the VP9 payload is described in <xref target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/>.  <bcp14>OPTIONAL</bcp14> RTP padding <bcp14>MUST NOT</bcp14> be included unless the P bit is set.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-4.1-4">
          <dt pn="section-4.1-4.1">Marker bit (M):</dt>
          <dd pn="section-4.1-4.2">This bit <bcp14>MUST</bcp14> be set to one for the final packet
            of the highest spatial-layer frame (the final packet of the picture); otherwise, it is zero.  Unless spatial scalability is in use for this picture,
            this bit will have the same value as the E bit described in <xref target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/>.  Note this bit
            <bcp14>MUST</bcp14> be set to one for the target spatial-layer frame 
            if a stream is being rewritten to remove higher spatial layers.</dd>
          <dt pn="section-4.1-4.3">Payload Type (PT):</dt>
          <dd pn="section-4.1-4.4">In line with the policy in <xref target="RFC3551" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3551#section-3" derivedContent="RFC3551"/>, applications using
          the VP9 RTP payload profile <bcp14>MUST</bcp14> assign a dynamic
          payload type number to be used in each RTP session and provide a
          mechanism to indicate the mapping.  See <xref target="SDPParameters" format="default" sectionFormat="of" derivedContent="Section 6.1"/> for the mechanism to be used with the <xref target="RFC8866" format="default" sectionFormat="of" derivedContent="RFC8866">Session Description Protocol
          (SDP)</xref>.</dd>
          <dt pn="section-4.1-4.5">Timestamp:</dt>
          <dd pn="section-4.1-4.6">The <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP timestamp</xref> indicates the time when
            the input frame was sampled, at a clock rate of 90 kHz.  If the
            input picture is encoded with multiple frames, all of the
            frames of the picture <bcp14>MUST</bcp14> have the same timestamp.</dd>
          <dt pn="section-4.1-4.7"/>
          <dd pn="section-4.1-4.8">If a frame has the VP9 show_frame field set to zero (i.e., it is
          meant only to populate a reference buffer without being output), its
          timestamp <bcp14>MAY</bcp14> alternatively be set to be the same as
          the subsequent frame with show_frame equal to one.  (This will be
          convenient for playing out pre-encoded content packaged with VP9
          "superframes", which typically bundle show_frame==0 frames with a
          subsequent show_frame==1 frame.)  Every picture containing a frame with show_frame==1,
          however, <bcp14>MUST</bcp14> have a unique timestamp modulo the 2<sup>32</sup>
          wrap of the field.</dd>
        </dl>
        <t indent="0" pn="section-4.1-5">The remaining RTP Fixed Header Fields (V, P, X, CC, sequence
        number, SSRC, and CSRC identifiers) are used as specified in <xref target="RFC3550" sectionFormat="of" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-5.1" derivedContent="RFC3550"/>.</t>
      </section>
      <section anchor="VP9payloadDescriptor" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-vp9-payload-descriptor">VP9 Payload Descriptor</name>
        <t keepWithNext="true" indent="0" pn="section-4.2-1">In flexible mode (with the F bit below set to one), the first octets 
          after the RTP header are the VP9 payload descriptor, with the following 
          structure.</t>
        <figure anchor="figureVP9payloadDescriptor" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-flexible-mode-format-for-vp">Flexible Mode Format for VP9 Payload Descriptor</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.2-2.1">
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |I|P|L|F|B|E|V|Z| (REQUIRED)
     +-+-+-+-+-+-+-+-+
I:   |M| PICTURE ID  | (REQUIRED)
     +-+-+-+-+-+-+-+-+
M:   | EXTENDED PID  | (RECOMMENDED)
     +-+-+-+-+-+-+-+-+
L:   | TID |U| SID |D| (Conditionally RECOMMENDED)
     +-+-+-+-+-+-+-+-+                             -\
P,F: | P_DIFF      |N| (Conditionally REQUIRED)    - up to 3 times
     +-+-+-+-+-+-+-+-+                             -/
V:   | SS            |
     | ..            |
     +-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t keepWithNext="true" indent="0" pn="section-4.2-3">In non-flexible mode (with the F bit below set to zero), the first octets 
          after the RTP header are the VP9 payload descriptor, with the following 
          structure.</t>
        <figure anchor="figureVP9payloadDescriptorNonFlexible" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-non-flexible-mode-format-fo">Non-Flexible Mode Format for VP9 Payload Descriptor</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.2-4.1">
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |I|P|L|F|B|E|V|Z| (REQUIRED)
     +-+-+-+-+-+-+-+-+
I:   |M| PICTURE ID  | (RECOMMENDED)
     +-+-+-+-+-+-+-+-+
M:   | EXTENDED PID  | (RECOMMENDED)
     +-+-+-+-+-+-+-+-+
L:   | TID |U| SID |D| (Conditionally RECOMMENDED)
     +-+-+-+-+-+-+-+-+
     |   TL0PICIDX   | (Conditionally REQUIRED)
     +-+-+-+-+-+-+-+-+
V:   | SS            |
     | ..            |
     +-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t indent="0" pn="section-4.2-5">Except as noted, the following field descriptions apply to the payload descriptor formats in both Figures <xref target="figureVP9payloadDescriptor" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="figureVP9payloadDescriptorNonFlexible" format="counter" sectionFormat="of" derivedContent="3"/>.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-4.2-6">
          <dt pn="section-4.2-6.1">I:</dt>
          <dd pn="section-4.2-6.2">Picture ID (PID) present. When set to one, the
          <bcp14>OPTIONAL</bcp14> PID <bcp14>MUST</bcp14> be present after the
          mandatory first octet and specified as below. Otherwise, PID
          <bcp14>MUST NOT</bcp14> be present.  If the V bit was set in the
          stream's most recent start of a keyframe (i.e., the SS field was
          present) and the F bit is set to zero (i.e., non-flexible scalability
          mode is in use), then this bit <bcp14>MUST</bcp14> be set on every
          packet.</dd>
          <dt pn="section-4.2-6.3">P:</dt>
          <dd pn="section-4.2-6.4">Inter-picture predicted frame.  When set to zero, the frame does
          not utilize inter-picture prediction.  In this case, up-switching to
          a current spatial layer's frame is possible from a directly lower
          spatial-layer frame.  P <bcp14>SHOULD</bcp14> also be set to zero when
          encoding a layer synchronization frame in response to a <xref target="RFC9627" format="default" sectionFormat="of" derivedContent="RFC9627">Layer Refresh Request (LRR)</xref>
          message (see <xref target="LRR" format="default" sectionFormat="of" derivedContent="Section 5.3"/>).  When P is set
          to zero, the Temporal-layer ID (TID) field (described below) <bcp14>MUST</bcp14> also be
          set to zero (if present).  Note that the P bit does not forbid
          intra-picture, inter-layer prediction from earlier frames of the
          same picture, if any.</dd>
          <dt pn="section-4.2-6.5">L:</dt>
          <dd pn="section-4.2-6.6">Layer indices present.  When set to one, the one or two octets
          following the mandatory first octet and the PID (if present) is as
          described by "Layer indices" below.  If the F bit (described below)
          is set to one (indicating flexible mode), then only one octet is
          present for the layer indices. Otherwise, if the F bit is set to zero
          (indicating non-flexible mode), then two octets are present for the
          layer indices.</dd>
          <dt pn="section-4.2-6.7">F:</dt>
          <dd pn="section-4.2-6.8">Flexible mode.  When set to one, this indicates flexible mode; if the
          P bit is also set to one, then the octets following the mandatory
          first octet, the PID, and layer indices (if present) are as
          described by "reference indices" below.  This bit <bcp14>MUST</bcp14>
          only be set to one if the I bit is also set to one; if the I bit is
          set to zero, then this bit <bcp14>MUST</bcp14> also be set to zero and
          ignored by receivers. (Flexible mode's reference indices are defined
          as offsets from the Picture ID field, so they would have no meaning
          if I were not set.)  The value of the F bit <bcp14>MUST</bcp14>
          only change on the first packet of a key picture.  A "key picture" is
          a picture whose base spatial-layer frame is a keyframe, and thus one which
          completely resets the encoder state.  This packet will have its
          P bit equal to zero, SID or L bit (described below) equal to zero,
          and B bit (described below) equal to one.</dd>
          <dt pn="section-4.2-6.9">B:</dt>
          <dd pn="section-4.2-6.10">Start of Frame. This bit <bcp14>MUST</bcp14> be set to one if
          the first payload octet of the RTP packet is the beginning of a
          new VP9 frame; otherwise, it <bcp14>MUST NOT</bcp14> be one. Note that this
          frame might not be the first frame of a picture.</dd>
          <dt pn="section-4.2-6.11">E:</dt>
          <dd pn="section-4.2-6.12">End of Frame.  This bit <bcp14>MUST</bcp14> be set to one for the final
          RTP packet of a VP9 frame; otherwise, it is zero.  This enables a
          decoder to finish decoding the frame, where it otherwise may need to
          wait for the next packet to explicitly know that the frame is complete.
          Note that, if spatial scalability is in use, more frames from the
          same picture may follow; see the description of the B bit above.</dd>
          <dt pn="section-4.2-6.13">V:</dt>
          <dd pn="section-4.2-6.14">Scalability Structure (SS) data present. When set
          to one, the <bcp14>OPTIONAL</bcp14> SS data <bcp14>MUST</bcp14> be present in the payload descriptor.
          Otherwise, the SS data <bcp14>MUST NOT</bcp14> be present.</dd>
          <dt pn="section-4.2-6.15">Z:</dt>
          <dd pn="section-4.2-6.16">Not a reference frame for upper spatial layers. If set to one,
          indicates that frames with higher spatial layers SID+1 and greater
          of the current and following pictures do not depend on the current
          spatial-layer SID frame.  This enables a decoder that is targeting a
          higher spatial layer to know that it can safely discard this
          packet's frame without processing it, without having to wait for the
          D bit in the higher-layer frame (see below).</dd>
        </dl>
        <t indent="0" pn="section-4.2-7">The mandatory first octet is followed by the extension data fields that
        are enabled:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-4.2-8">
          <dt pn="section-4.2-8.1">M:</dt>
          <dd pn="section-4.2-8.2">The most significant bit of the first octet is an extension
          flag. The field <bcp14>MUST</bcp14> be present if the I bit is equal
          to one. If M is set, the PID field <bcp14>MUST</bcp14> contain 15
          bits; otherwise, it <bcp14>MUST</bcp14> contain 7 bits. See PID
          below.</dd>
          <dt pn="section-4.2-8.3">Picture ID (PID):</dt>
          <dd pn="section-4.2-8.4">Picture ID represented in 7 or 15 bits, depending on the M
          bit. This is a running index of the pictures, where the sender
          increments the value by one for each picture it sends.  (Note,
          however, that because a middlebox can discard pictures where
          permitted by the SS, Picture IDs as received by a
          receiver might not be contiguous.)  This field <bcp14>MUST</bcp14>
          be present if the I bit is equal to one. If M is set to zero, 7 bits
          carry the PID; else, if M is set to one, 15 bits carry the PID in
          network byte order.  The sender may choose between a 7- or 15-bit
          index. The PID <bcp14>SHOULD</bcp14> start on a random number and
          <bcp14>MUST</bcp14> wrap after reaching the maximum ID (0x7f or
          0x7fff depending on the index size chosen). The receiver <bcp14>MUST NOT</bcp14> assume that the number of bits in the PID stays the same
          through the session.  If this field transitions from 7 bits to 15
          bits, the value is zero-extended (i.e., the value after 0x6e is
          0x006f); if the field transitions from 15 bits to 7 bits, it is
          truncated (i.e., the value after 0x1bbe is 0x3f).
          </dd>
          <dt pn="section-4.2-8.5"/>
          <dd pn="section-4.2-8.6">In the non-flexible mode (when the F bit is set to zero), this PID
          is used as an index to the PG specified in the SS
          data below.  In this mode, the PID of the keyframe corresponds to
          the first specified frame in the PG.  Then subsequent PIDs are
          mapped to subsequently specified frames in the PG (modulo N_G,
          specified in the SS data below), respectively.</dd>
          <dt pn="section-4.2-8.7"/>
          <dd pn="section-4.2-8.8">All frames of the same picture <bcp14>MUST</bcp14> have the same
          PID value.</dd>
          <dt pn="section-4.2-8.9"/>
          <dd pn="section-4.2-8.10">Frames (and their corresponding pictures) with the VP9
          show_frame field equal to zero <bcp14>MUST</bcp14> have distinct PID
          values from subsequent pictures with show_frame equal to one.  Thus, a
          picture (as defined in this specification) is different than a VP9
          superframe.</dd>
          <dt pn="section-4.2-8.11"/>
          <dd pn="section-4.2-8.12">All frames of the same picture <bcp14>MUST</bcp14> have the same
          value for show_frame.</dd>
          <dt pn="section-4.2-8.13">Layer indices:</dt>
          <dd pn="section-4.2-8.14">This field is optional but <bcp14>RECOMMENDED</bcp14>
          whenever encoding with layers.  For both flexible and non-flexible
          modes, one octet is used to specify a layer frame's Temporal-layer
          ID (TID) and Spatial-layer ID (SID) as shown both in Figures <xref target="figureVP9payloadDescriptor" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="figureVP9payloadDescriptorNonFlexible" format="counter" sectionFormat="of" derivedContent="3"/>.
          Additionally, a bit (U) is used to indicate that the current frame
          is a "switching up point" frame.  Another bit (D) is used to
          indicate whether inter-layer prediction is used for the current
          frame.</dd>
          <dt pn="section-4.2-8.15"/>
          <dd pn="section-4.2-8.16">In the non-flexible mode (when the F bit is set to zero), another
          octet is used to represent the Temporal Layer 0 Picture Index (8 bits) (TL0PICIDX), as
          depicted in <xref target="figureVP9payloadDescriptorNonFlexible" format="default" sectionFormat="of" derivedContent="Figure 3"/>.  The TL0PICIDX is present so that all minimally
          required frames (the base temporal-layer frames) can be
          tracked.</dd>
          <dt pn="section-4.2-8.17"/>
          <dd pn="section-4.2-8.18">
            <t indent="0" pn="section-4.2-8.18.1">The TID and SID fields indicate the temporal and spatial layers
            and can help middleboxes and endpoints quickly identify which
            layer a packet belongs to.

            </t>
            <dl newline="false" spacing="normal" indent="3" pn="section-4.2-8.18.2">
              <dt pn="section-4.2-8.18.2.1">TID:</dt>
              <dd pn="section-4.2-8.18.2.2">The temporal-layer ID of the current frame.  In the case of
              non-flexible mode, if a PID is mapped to a picture in a specified
              PG, then the value of the TID <bcp14>MUST</bcp14> match the
              corresponding TID value of the mapped picture in the PG.</dd>
              <dt pn="section-4.2-8.18.2.3">U:</dt>
              <dd pn="section-4.2-8.18.2.4">Switching up point.  When this bit is set to one, if the current picture has a temporal-layer ID equal to value T, then subsequent pictures with temporal-layer ID values higher than T will not depend on any picture before
              the current picture (in decode order) with a temporal-layer ID
              value greater than T.</dd>
              <dt pn="section-4.2-8.18.2.5">SID:</dt>
              <dd pn="section-4.2-8.18.2.6">The spatial-layer ID of the current frame.  Note that frames
              with spatial-layer SID &gt; 0 may be dependent on decoded
              spatial-layer SID-1 frame within the same picture.  Different
              frames of the same picture <bcp14>MUST</bcp14> have distinct
              spatial-layer IDs, and frames' spatial layers
              <bcp14>MUST</bcp14> appear in increasing order within the
              frame.</dd>
              <dt pn="section-4.2-8.18.2.7">D:</dt>
              <dd pn="section-4.2-8.18.2.8">Inter-layer dependency is used. D <bcp14>MUST</bcp14> be
              set to one if and only if the current spatial-layer SID frame
              depends on spatial-layer SID-1 frame of the same picture;
              otherwise, it <bcp14>MUST</bcp14> be set to zero.  For the
              base-layer frame (with SID equal to zero), the D bit
              <bcp14>MUST</bcp14> be set to zero.</dd>
              <dt pn="section-4.2-8.18.2.9">TL0PICIDX:</dt>
              <dd pn="section-4.2-8.18.2.10">Temporal Layer 0 Picture Index (8 bits). TL0PICIDX is only present
              in the non-flexible mode (F = 0).  This is a running index for
              the temporal base-layer pictures, i.e., the pictures with a TID
              set to zero.  If the TID is larger than zero, TL0PICIDX indicates which
              temporal base-layer picture the current picture depends on.
              TL0PICIDX <bcp14>MUST</bcp14> be incremented by one when the TID is
              equal to zero.  The index <bcp14>SHOULD</bcp14> start on a random
              number and <bcp14>MUST</bcp14> restart at zero after reaching the
              maximum number 255.</dd>
            </dl>
          </dd>
          <dt pn="section-4.2-8.19">Reference indices:</dt>
          <dd pn="section-4.2-8.20">
            <t indent="0" pn="section-4.2-8.20.1">When P and F are both set to one, indicating a non-keyframe in
            flexible mode, then at least one reference index
            <bcp14>MUST</bcp14> be specified as below.  Additional reference
            indices (a total of up to three reference indices are allowed) may be
            specified using the N bit below.  When either P or F is set to zero,
            then no reference index is specified.
            </t>
            <dl newline="false" spacing="normal" indent="3" pn="section-4.2-8.20.2">
              <dt pn="section-4.2-8.20.2.1">P_DIFF:</dt>
              <dd pn="section-4.2-8.20.2.2">The reference index (in 7 bits) specified as the relative
              PID from the current picture.  For example, when P_DIFF=3 on a
              packet containing the picture with PID 112 means that the
              picture refers back to the picture with PID 109. This
              calculation is done modulo the size of the PID field, i.e.,
              either 7 or 15 bits.  A P_DIFF value of zero is invalid.</dd>
              <dt pn="section-4.2-8.20.2.3">N:</dt>
              <dd pn="section-4.2-8.20.2.4">1 if there is additional P_DIFF following the current P_DIFF.</dd>
            </dl>
          </dd>
        </dl>
        <section anchor="VP9payloadDescriptorSS" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-scalability-structure-ss">Scalability Structure (SS)</name>
          <t indent="0" pn="section-4.2.1-1">The SS data describes the resolution of
          each frame within a picture as well as the inter-picture
          dependencies for a PG.  If the VP9 payload
          descriptor's V bit is set, the SS data is present in the position
          indicated in Figures <xref format="counter" target="figureVP9payloadDescriptor" sectionFormat="of" derivedContent="2"/> and <xref target="figureVP9payloadDescriptorNonFlexible" format="counter" sectionFormat="of" derivedContent="3"/>.</t>
          <figure anchor="figureVP9ScalabilityStructure" align="left" suppress-title="false" pn="figure-4">
            <name slugifiedName="name-vp9-scalability-structure">VP9 Scalability Structure</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.2.1-2.1">
     +-+-+-+-+-+-+-+-+
V:   | N_S |Y|G|-|-|-|
     +-+-+-+-+-+-+-+-+              -\
Y:   |     WIDTH     | (OPTIONAL)    .
     +               +               .
     |               | (OPTIONAL)    .
     +-+-+-+-+-+-+-+-+               . - N_S + 1 times
     |     HEIGHT    | (OPTIONAL)    .
     +               +               .
     |               | (OPTIONAL)    .
     +-+-+-+-+-+-+-+-+              -/
G:   |      N_G      | (OPTIONAL)
     +-+-+-+-+-+-+-+-+                            -\
N_G: | TID |U| R |-|-| (OPTIONAL)                 .
     +-+-+-+-+-+-+-+-+              -\            . - N_G times
     |    P_DIFF     | (OPTIONAL)    . - R times  .
     +-+-+-+-+-+-+-+-+              -/            -/
</artwork>
          </figure>
          <dl newline="false" spacing="normal" indent="3" pn="section-4.2.1-3">
            <dt pn="section-4.2.1-3.1">N_S:</dt>
            <dd pn="section-4.2.1-3.2">Number of Spatial Layers Minus 1.  N_S + 1 indicates the number of spatial
          layers present in the VP9 stream.</dd>
            <dt pn="section-4.2.1-3.3">Y:</dt>
            <dd pn="section-4.2.1-3.4">Each spatial layer's frame resolution is present.
          When set to one, the <bcp14>OPTIONAL</bcp14> WIDTH (2 octets) and HEIGHT
          (2 octets) <bcp14>MUST</bcp14> be present for each layer frame.  Otherwise, the
          resolution <bcp14>MUST NOT</bcp14> be present.</dd>
            <dt pn="section-4.2.1-3.5">G:</dt>
            <dd pn="section-4.2.1-3.6">The PG description present flag.</dd>
            <dt pn="section-4.2.1-3.7">-:</dt>
            <dd pn="section-4.2.1-3.8">A bit reserved for future use. It <bcp14>MUST</bcp14> be set
            to zero and <bcp14>MUST</bcp14> be ignored by the receiver.</dd>
            <dt pn="section-4.2.1-3.9">N_G:</dt>
            <dd pn="section-4.2.1-3.10">N_G indicates the number of pictures in a PG.
            If N_G is greater than zero, then the SS data allows the
            inter-picture dependency structure of the VP9 stream to be
            pre-declared, rather than indicating it on the fly with every
            packet.  If N_G is greater than zero, then for N_G pictures in the
            PG, each picture's Temporal-layer ID (TID), switch up point (U),
            and reference indices (P_DIFFs) are specified.</dd>
            <dt pn="section-4.2.1-3.11"/>
            <dd pn="section-4.2.1-3.12">The first picture specified in the PG <bcp14>MUST</bcp14> have a TID set to zero.</dd>
            <dt pn="section-4.2.1-3.13"/>
            <dd pn="section-4.2.1-3.14">G set to zero or N_G set to zero indicates that either there is only
            one temporal layer (for non-flexible mode) or no fixed
            inter-picture dependency information is present (for flexible
            mode) going forward in the bitstream.</dd>
            <dt pn="section-4.2.1-3.15"/>
            <dd pn="section-4.2.1-3.16">Note that for a given picture, all frames follow the same
            inter-picture dependency structure.  However, the frame rate of
            each spatial layer can be different from each other; this can
            be described with the use of the D bit described above.  The
            specified dependency structure in the SS data <bcp14>MUST</bcp14>
            be for the highest frame rate layer.</dd>
            <dt pn="section-4.2.1-3.17">R:</dt>
            <dd pn="section-4.2.1-3.18">The number of P_DIFF fields that are present.</dd>
          </dl>
          <t indent="0" pn="section-4.2.1-4">In a scalable stream sent with a fixed pattern, the SS data
          <bcp14>SHOULD</bcp14> be included in the first packet of every key
          frame. This is a packet with the P bit equal to zero, SID or L bit equal
          to zero, and B bit equal to one.  The SS data <bcp14>MUST</bcp14> only
          be changed on the picture that corresponds to the first picture
          specified in the previous SS data's PG (if the previous SS data's
          N_G was greater than zero).</t>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-frame-fragmentation">Frame Fragmentation</name>
        <t indent="0" pn="section-4.3-1">VP9 frames are fragmented into packets in RTP sequence number
        order: beginning with a packet with the B bit set and ending with a
        packet with the E bit set.  There is no mechanism for finer-grained
        access to parts of a VP9 frame.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-scalable-encoding-considera">Scalable Encoding Considerations</name>
        <t indent="0" pn="section-4.4-1">In addition to the use of reference frames, VP9 has several
		additional forms of inter-frame dependencies, largely
		involving probability tables for the entropy and tree
		encoders.  In VP9 syntax, the syntax element
		"error_resilient_mode" resets this additional inter-frame
		data, allowing a frame's syntax to be decoded
		independently.</t>
        <t indent="0" pn="section-4.4-2">Due to the requirements of scalable streams, a VP9 encoder
		producing a scalable stream needs to ensure that a frame does
		not depend on a previous frame (of the same or a previous
		picture) that can legitimately be removed from the stream.
		Thus, a frame that follows a frame that might be removed (in full decode
		order) <bcp14>MUST</bcp14> be encoded with "error_resilient_mode" set to
		true.</t>
        <t indent="0" pn="section-4.4-3">For spatially scalable streams, this means that
		"error_resilient_mode" needs to be turned on for the base
		spatial layer; however, it can be turned off for higher spatial
		layers, assuming they are sent with inter-layer dependency
		(i.e., with the D bit set).  For streams that are only
		temporally scalable without spatial scalability,
		"error_resilient_mode" can additionally be turned off for any
		picture that immediately follows a temporal-layer 0 frame.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-example-of-a-vp9-rtp-stream">Example of a VP9 RTP Stream</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5.1">
          <name slugifiedName="name-reference-picture-use-for-s">Reference Picture Use for Scalable Structure</name>
          <t indent="0" pn="section-4.5.1-1">As discussed in <xref target="mediaFormatDescription" format="default" sectionFormat="of" derivedContent="Section 3"/>, the
			VP9 codec can maintain up to eight reference frames, of
			which up to three can be referenced or updated by any new
			frame.  This section illustrates one way that a scalable
			structure (with three spatial layers and three temporal
			layers) can be constructed using these reference
			frames.</t>
          <table align="center" pn="table-1">
            <name slugifiedName="name-example-scalability-structu">Example Scalability Structure</name>
            <thead>
              <tr>
                <th align="center" colspan="1" rowspan="1">Temporal</th>
                <th align="center" colspan="1" rowspan="1">Spatial</th>
                <th align="center" colspan="1" rowspan="1">References</th>
                <th align="center" colspan="1" rowspan="1">Updates</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">0</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="center" colspan="1" rowspan="1">0,1</td>
                <td align="center" colspan="1" rowspan="1">1</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">1,2</td>
                <td align="center" colspan="1" rowspan="1">2</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">6</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="center" colspan="1" rowspan="1">1,6</td>
                <td align="center" colspan="1" rowspan="1">7</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">2,7</td>
                <td align="center" colspan="1" rowspan="1">-</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">3</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="center" colspan="1" rowspan="1">1,3</td>
                <td align="center" colspan="1" rowspan="1">4</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">2,4</td>
                <td align="center" colspan="1" rowspan="1">5</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="center" colspan="1" rowspan="1">3</td>
                <td align="center" colspan="1" rowspan="1">6</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">1</td>
                <td align="center" colspan="1" rowspan="1">4,6</td>
                <td align="center" colspan="1" rowspan="1">7</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">2</td>
                <td align="center" colspan="1" rowspan="1">5,7</td>
                <td align="center" colspan="1" rowspan="1">-</td>
              </tr>
            </tbody>
          </table>
          <t indent="0" pn="section-4.5.1-3">This structure is constructed such that the U bit can
		  always be set.</t>
        </section>
      </section>
    </section>
    <section anchor="Feedback" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-feedback-messages-and-heade">Feedback Messages and Header Extensions</name>
      <section anchor="RPSI" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-reference-picture-selection">Reference Picture Selection Indication (RPSI)</name>
        <t indent="0" pn="section-5.1-1">The RPSI is a payload-specific
        feedback message defined within the RTCP-based feedback format. The
        RPSI message is generated by a receiver and can be used in two ways:
        either it can signal a preferred reference picture when a loss has
        been detected by the decoder (preferably a reference that the decoder
        knows is perfect) or it can be used as positive feedback information
        to acknowledge correct decoding of certain reference pictures. The
        positive feedback method is useful for VP9 used for point-to-point
        (unicast) communication. The use of RPSI for VP9 is preferably
        combined with a special update pattern of the codec's two special
        reference frames -- the golden frame and the altref frame -- in which they
        are updated in an alternating leapfrog fashion. When a receiver has
        received and correctly decoded a golden or altref frame, and that
        frame had a Picture ID in the payload descriptor, the receiver can
        acknowledge this simply by sending an RPSI message back to the
        sender. The message body (i.e., the "native RPSI bit string" in <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>) is simply the (7- or 15-bit)
        Picture ID of the received frame.</t>
        <aside pn="section-5.1-2">
          <t indent="0" pn="section-5.1-2.1">Note: because all frames of the same picture must have the
		same inter-picture reference structure, there is no need for a
		message to specify which frame is being selected.</t>
        </aside>
      </section>
      <section anchor="FIR" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-full-intra-request-fir">Full Intra Request (FIR)</name>
        <t indent="0" pn="section-5.2-1">The <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">Full Intra Request (FIR)</xref>
		RTCP feedback message allows a receiver to request a full state refresh of an encoded stream.</t>
        <t indent="0" pn="section-5.2-2">Upon receipt of a FIR request, a VP9 sender <bcp14>MUST</bcp14>
        send a picture with a keyframe for its spatial-layer 0 layer frame and
        then send frames without inter-picture prediction (P=0) for any
        higher-layer frames.</t>
      </section>
      <section anchor="LRR" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-layer-refresh-request-lrr">Layer Refresh Request (LRR)</name>
        <t indent="0" pn="section-5.3-1">The <xref target="RFC9627" format="default" sectionFormat="of" derivedContent="RFC9627">Layer Refresh Request
        (LRR)</xref> allows a receiver to request a single layer of a
        spatially or temporally encoded stream to be refreshed without
        necessarily affecting the stream's other layers.</t>
        <figure anchor="figureLRRIndexFormat" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-lrr-index-format">LRR Index Format</name>
          <artwork name="" type="" align="left" alt="" pn="section-5.3-2.1">
            +---------------+---------------+
            |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
            +---------------+---------+-----+
            |   RES   | TID | RES     | SID |
            +---------------+---------+-----+
</artwork>
        </figure>
        <t indent="0" pn="section-5.3-3"><xref target="figureLRRIndexFormat" format="default" sectionFormat="of" derivedContent="Figure 5"/> shows the format
		of an LRR's layer index fields for VP9 streams.  The two "RES" 
		fields <bcp14>MUST</bcp14> be set to zero on transmission and ignored on
		reception.  See <xref target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/> for
		details on the TID and SID fields.</t>
        <t indent="0" pn="section-5.3-4">Identification of a layer refresh frame can be derived from
		the reference IDs of each frame by backtracking the dependency
		chain until reaching a point where only decodable frames are
		being referenced. Therefore, it's recommended for both the
		flexible and the non-flexible mode that, when switching up
		points are being encoded in response to an LRR, those packets
		contain layer indices and the reference field or fields so
		that the decoder or <xref target="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667">selective forwarding middleboxes</xref> can
		make this derivation.</t>
        <t indent="0" pn="section-5.3-5">Example:</t>
        <t indent="0" pn="section-5.3-6">LRR {1,0}, {2,1} is sent by a Multipoint Control
   Unit (MCU) when it is currently
	  relaying {1,0} to a receiver that wants to upgrade to
	  {2,1}. In response, the encoder should encode the next frames
	  in layers {1,1} and {2,1} by only referring to frames in
	  {1,0} or {0,0}.</t>
        <t indent="0" pn="section-5.3-7">In the non-flexible mode, periodic upgrade frames can be defined by
        the layer structure of the SS; thus, periodic upgrade frames can be
        automatically identified by the Picture ID.</t>
      </section>
    </section>
    <section anchor="payloadFormatParameters" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-payload-format-parameters">Payload Format Parameters</name>
      <t indent="0" pn="section-6-1">This payload format has three optional parameters: max-fr,
      max-fs, and profile-id.</t>
      <t indent="0" pn="section-6-2">The max-fr and max-fs parameters are used to signal the capabilities
      of a receiver implementation. If the implementation is willing to
      receive media, both parameters <bcp14>MUST</bcp14> be provided. These
      parameters <bcp14>MUST NOT</bcp14> be used for any other purpose.  A
      media sender <bcp14>SHOULD NOT</bcp14> send media with a frame rate or
      frame size exceeding the max-fr and max-fs values signaled.  (There may
      be scenarios, such as pre-encoded media or <xref target="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667">selective forwarding middleboxes</xref>, where a media
      sender does not have media available that fits within a receiver's
      max-fs and max-fr values; in such scenarios, a sender <bcp14>MAY</bcp14>
      exceed the signaled values.)
      </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-6-3">
        <dt pn="section-6-3.1">max-fr:</dt>
        <dd pn="section-6-3.2">The value of max-fr is an integer
                indicating the maximum frame rate in units of frames per
                second that the decoder is capable of decoding.</dd>
        <dt pn="section-6-3.3">max-fs:</dt>
        <dd pn="section-6-3.4">The value of max-fs is an integer
                indicating the maximum frame size in units of macroblocks that
                the decoder is capable of decoding.</dd>
        <dt pn="section-6-3.5"/>
        <dd pn="section-6-3.6">The decoder is capable of decoding this frame size as long
                as the width and height of the frame in macroblocks are each less
                than int(sqrt(max-fs * 8)); for instance, a max-fs of 1200
                (capable of supporting 640x480 resolution) will support widths
                and heights up to 1552 pixels (97 macroblocks).</dd>
        <dt pn="section-6-3.7">profile-id:</dt>
        <dd pn="section-6-3.8">The value of profile-id is an integer indicating the default
        coding profile (the subset of coding tools that may have been used to
        generate the stream or that the receiver supports). <xref target="TableOfProfileIds" format="default" sectionFormat="of" derivedContent="Table 2"/> lists all of the
        profiles defined in Section 7.2 of <xref target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/> and the corresponding integer values to be
        used.</dd>
        <dt pn="section-6-3.9"/>
        <dd pn="section-6-3.10">If no profile-id is present, Profile 0 <bcp14>MUST</bcp14> be inferred.  (The
                profile-id parameter was added relatively late in the development of this
                specification, so some existing implementations may not send it.)
                </dd>
        <dt pn="section-6-3.11"/>
        <dd pn="section-6-3.12">Informative note: See <xref target="TableOfProfiles" format="default" sectionFormat="of" derivedContent="Table 3"/> for capabilities of coding profiles defined in Section 7.2 of
        <xref target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/>.</dd>
      </dl>
      <t indent="0" pn="section-6-4">A receiver <bcp14>MUST</bcp14> ignore any parameter unspecified in this
      specification.</t>
      <table anchor="TableOfProfileIds" align="center" pn="table-2">
        <name slugifiedName="name-correspondence-between-prof">Correspondence between profile-id to VP9 Profile Integer</name>
        <thead>
          <tr>
            <th align="center" colspan="1" rowspan="1">Profile</th>
            <th align="center" colspan="1" rowspan="1">profile-id</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">0</td>
            <td align="center" colspan="1" rowspan="1">0</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1</td>
            <td align="center" colspan="1" rowspan="1">1</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">2</td>
            <td align="center" colspan="1" rowspan="1">2</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">3</td>
            <td align="center" colspan="1" rowspan="1">3</td>
          </tr>
        </tbody>
      </table>
      <table anchor="TableOfProfiles" align="center" pn="table-3">
        <name slugifiedName="name-profile-capabilities">Profile Capabilities</name>
        <thead>
          <tr>
            <th align="center" colspan="1" rowspan="1">Profile</th>
            <th align="center" colspan="1" rowspan="1">Bit Depth</th>
            <th align="center" colspan="1" rowspan="1">SRGB Colorspace</th>
            <th align="center" colspan="1" rowspan="1">Chroma Subsampling</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">0</td>
            <td align="center" colspan="1" rowspan="1">8</td>
            <td align="center" colspan="1" rowspan="1">No</td>
            <td align="center" colspan="1" rowspan="1">YUV 4:2:0</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">1</td>
            <td align="center" colspan="1" rowspan="1">8</td>
            <td align="center" colspan="1" rowspan="1">Yes</td>
            <td align="center" colspan="1" rowspan="1">YUV 4:2:2,4:4:0 or 4:4:4</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">2</td>
            <td align="center" colspan="1" rowspan="1">10 or 12</td>
            <td align="center" colspan="1" rowspan="1">No</td>
            <td align="center" colspan="1" rowspan="1">YUV 4:2:0</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">3</td>
            <td align="center" colspan="1" rowspan="1">10 or 12</td>
            <td align="center" colspan="1" rowspan="1">Yes</td>
            <td align="center" colspan="1" rowspan="1">YUV 4:2:2,4:4:0 or 4:4:4</td>
          </tr>
        </tbody>
      </table>
      <aside pn="section-6-7">
        <t keepWithPrevious="true" indent="0" pn="section-6-7.1">Note: SRGB (often sRGB) = Standard Red-Green-Blue</t>
      </aside>
      <section anchor="SDPParameters" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-sdp-parameters">SDP Parameters</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1.1">
          <name slugifiedName="name-mapping-of-media-subtype-pa">Mapping of Media Subtype Parameters to SDP</name>
          <t indent="0" pn="section-6.1.1-1">The media type video/vp9 string is mapped to fields in the
          Session Description Protocol (SDP) <xref target="RFC8866" format="default" sectionFormat="of" derivedContent="RFC8866"/> as
          follows: </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.1-2">
            <li pn="section-6.1.1-2.1">The media name in the "m=" line of SDP <bcp14>MUST</bcp14> be video.</li>
            <li pn="section-6.1.1-2.2">The encoding name in the "a=rtpmap" line of SDP
            <bcp14>MUST</bcp14> be VP9 (the media subtype).</li>
            <li pn="section-6.1.1-2.3">The clock rate in the "a=rtpmap" line <bcp14>MUST</bcp14> be 90000.</li>
            <li pn="section-6.1.1-2.4">The parameters max-fr and max-fs <bcp14>MUST</bcp14> be included in
              the "a=fmtp" line of SDP if the receiver wishes to declare its receiver
              capabilities. These parameters are expressed as a media subtype
	      string in the form of a semicolon-separated list of
	      parameter=value pairs.</li>
            <li pn="section-6.1.1-2.5">The <bcp14>OPTIONAL</bcp14> parameter profile-id, when present, <bcp14>SHOULD</bcp14> be
	      included in the "a=fmtp" line of SDP. This parameter is expressed
	      as a media subtype string in the form of a parameter=value
	      pair. When the parameter is not present, a value of 0 <bcp14>MUST</bcp14> be
	      inferred for profile-id.</li>
          </ul>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-6.1.1.1">
            <name slugifiedName="name-example">Example</name>
            <t indent="0" pn="section-6.1.1.1-1">An example of media representation in SDP is as follows:</t>
            <sourcecode type="sdp" markers="false" pn="section-6.1.1.1-2">m=video 49170 RTP/AVPF 98
a=rtpmap:98 VP9/90000
a=fmtp:98 max-fr=30;max-fs=3600;profile-id=0
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1.2">
          <name slugifiedName="name-offer-answer-considerations">Offer/Answer Considerations</name>
          <t indent="0" pn="section-6.1.2-1">When VP9 is offered over RTP using SDP in an Offer/Answer model
          <xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/> for negotiation for unicast usage, the following
          limitations and rules apply: </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.2-2">
            <li pn="section-6.1.2-2.1">The parameter identifying a media format configuration for VP9 is
	      profile-id. This media format configuration parameter <bcp14>MUST</bcp14> be used
	      symmetrically; that is, the answerer <bcp14>MUST</bcp14> either maintain this
	      configuration parameter or remove the media format (payload type)
	      completely if it is not supported.</li>
            <li pn="section-6.1.2-2.2">The max-fr and max-fs parameters are used declaratively to
              describe receiver capabilities, even in the Offer/Answer model.
              The values in an answer are used to describe the answerer's
              capabilities; thus, their values are set independently of the
              values in the offer.</li>
            <li pn="section-6.1.2-2.3">To simplify the handling and matching of these configurations, the
              same RTP payload type number used in the offer <bcp14>SHOULD</bcp14> also be used
              in the answer and in a subsequent offer, as specified in <xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. An answer or subsequent offer
	      <bcp14>MUST NOT</bcp14> contain the payload type number used in the offer unless the
	      profile-id value is exactly the same as in the original offer.
              However, max-fr and max-fs parameters <bcp14>MAY</bcp14> be changed in subsequent
              offers and answers, with the same payload type number, if an endpoint
              wishes to change its declared receiver capabilities.</li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="mediaTypeRegistration" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-media-type-definition">Media Type Definition</name>
      <t indent="0" pn="section-7-1">This registration uses the template defined in <xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/> and following <xref target="RFC4855" format="default" sectionFormat="of" derivedContent="RFC4855"/>. </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-7-2">
        <dt pn="section-7-2.1">Type name:</dt>
        <dd pn="section-7-2.2">video</dd>
        <dt pn="section-7-2.3">Subtype name:</dt>
        <dd pn="section-7-2.4">VP9</dd>
        <dt pn="section-7-2.5">Required parameters:</dt>
        <dd pn="section-7-2.6">N/A</dd>
        <dt pn="section-7-2.7">Optional parameters:</dt>
        <dd pn="section-7-2.8">
            There are three optional parameters: max-fr, max-fs, and profile-id.
            See <xref target="payloadFormatParameters" format="default" sectionFormat="of" derivedContent="Section 6"/> for their definition.
            </dd>
        <dt pn="section-7-2.9">Encoding considerations:</dt>
        <dd pn="section-7-2.10">
            This media type is framed in RTP and contains binary data; see
            <xref target="RFC6838" sectionFormat="of" section="4.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6838#section-4.8" derivedContent="RFC6838"/>.</dd>
        <dt pn="section-7-2.11">Security considerations:</dt>
        <dd pn="section-7-2.12">
          <t indent="0" pn="section-7-2.12.1">See <xref target="securityConsiderations" format="default" sectionFormat="of" derivedContent="Section 8"/> of RFC 9628. </t>
        </dd>
        <dt pn="section-7-2.13">Interoperability considerations:</dt>
        <dd pn="section-7-2.14">None</dd>
        <dt pn="section-7-2.15">Published specification:</dt>
        <dd pn="section-7-2.16">
          <t indent="0" pn="section-7-2.16.1">VP9 bitstream format <xref target="VP9-BITSTREAM" format="default" sectionFormat="of" derivedContent="VP9-BITSTREAM"/> and RFC 9628. </t>
        </dd>
        <dt pn="section-7-2.17">Applications that use this media type:</dt>
        <dd pn="section-7-2.18"> For example, video over IP, video
            conferencing.</dd>
        <dt pn="section-7-2.19">Fragment identifier considerations:</dt>
        <dd pn="section-7-2.20">N/A</dd>
        <dt pn="section-7-2.21">Additional information:</dt>
        <dd pn="section-7-2.22">None</dd>
        <dt pn="section-7-2.23">Person &amp; email address to contact for further information:</dt>
        <dd pn="section-7-2.24">
          <t indent="0" pn="section-7-2.24.1"><contact fullname="Jonathan Lennox"/> &lt;jonathan.lennox@8x8.com&gt;</t>
        </dd>
        <dt pn="section-7-2.25">Intended usage:</dt>
        <dd pn="section-7-2.26">COMMON</dd>
        <dt pn="section-7-2.27">Restrictions on usage:</dt>
        <dd pn="section-7-2.28"> This media type depends on RTP framing; hence, it is only defined
        for transfer via RTP <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>.</dd>
        <dt pn="section-7-2.29">Author:</dt>
        <dd pn="section-7-2.30">
          <t indent="0" pn="section-7-2.30.1"><contact fullname="Jonathan Lennox"/> &lt;jonathan.lennox@8x8.com&gt;</t>
        </dd>
        <dt pn="section-7-2.31">Change controller:</dt>
        <dd pn="section-7-2.32"> IETF
            AVTCore Working Group delegated from the IETF.</dd>
      </dl>
    </section>
    <section anchor="securityConsiderations" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">RTP packets using the payload format defined in this specification
      are subject to the security considerations discussed in the RTP
      specification <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>, and in any
      applicable RTP profile such as <xref target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551">RTP/AVP</xref>, <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">RTP/AVPF</xref>, <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711">RTP/SAVP</xref>, or <xref target="RFC5124" format="default" sectionFormat="of" derivedContent="RFC5124">RTP/SAVPF</xref>.  However, as "<xref target="RFC7202" format="title" sectionFormat="of" derivedContent="Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution"/>" <xref target="RFC7202" format="default" sectionFormat="of" derivedContent="RFC7202"/> discusses, it is not an RTP
      payload format's responsibility to discuss or mandate what solutions are
      used to meet the basic security goals like confidentiality, integrity,
      and source authenticity for RTP in general.  This responsibility lies with
      anyone using RTP in an application.  They can find guidance on available
      security mechanisms in "<xref target="RFC7201" format="title" sectionFormat="of" derivedContent="Options for Securing RTP Sessions"/>" <xref target="RFC7201" format="default" sectionFormat="of" derivedContent="RFC7201"/>.  Applications <bcp14>SHOULD</bcp14>
      use one or more appropriate strong security mechanisms.</t>
      <t indent="0" pn="section-8-2">Implementations of this RTP payload format need to take appropriate
      security considerations into account.  It is extremely important for the
      decoder to be robust against malicious or malformed payloads and ensure
      that they do not cause the decoder to overrun its allocated memory or
      otherwise misbehave.  An overrun in allocated memory could lead to
      arbitrary code execution by an attacker.  The same applies to the
      encoder, even though problems in encoders are (typically) rarer.</t>
      <t indent="0" pn="section-8-3">This RTP payload format and its media decoder do not exhibit any
      significant non-uniformity in the receiver-side computational complexity
      for packet processing; thus, they are unlikely to pose a denial-of-service
      threat due to the receipt of pathological data. Nor does the RTP payload
      format contain any active content.</t>
    </section>
    <section anchor="congestionControl" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-congestion-control">Congestion Control</name>
      <t indent="0" pn="section-9-1">Congestion control for RTP <bcp14>SHALL</bcp14> be used in accordance
      with <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>, and with any
      applicable RTP profile, e.g., <xref target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551"/>. The congestion control mechanism can, in a real-time
      encoding scenario, adapt the transmission rate by instructing the
      encoder to encode at a certain target rate. Media-aware network elements
      <bcp14>MAY</bcp14> use the information in the VP9 payload descriptor in
      <xref target="VP9payloadDescriptor" format="default" sectionFormat="of" derivedContent="Section 4.2"/> to identify
      non-reference frames and discard them in order to reduce network
      congestion. Note that discarding of non-reference frames cannot be done
      if the stream is encrypted (because the non-reference marker is
      encrypted).</t>
    </section>
    <section anchor="IANAConsiderations" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-10-1">IANA has registered the media type "video/vp9"
      as specified in <xref target="mediaTypeRegistration" format="default" sectionFormat="of" derivedContent="Section 7"/>.
      The media type has also been added to the 
      "RTP Payload Format Media Types" registry of the "Real-Time Transport Protocol (RTP) Parameters" registry group (<eref target="https://www.iana.org/assignments/rtp-parameters" brackets="none"/>) as follows.</t>
      <dl spacing="compact" indent="3" newline="false" pn="section-10-2">
        <dt pn="section-10-2.1">Media Type:</dt>
        <dd pn="section-10-2.2">video</dd>
        <dt pn="section-10-2.3">Subtype:</dt>
        <dd pn="section-10-2.4">VP9</dd>
        <dt pn="section-10-2.5">Clock Rate (Hz):</dt>
        <dd pn="section-10-2.6">90000</dd>
        <dt pn="section-10-2.7">Reference:</dt>
        <dd pn="section-10-2.8">RFC 9628</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <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 indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted 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="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264">
          <front>
            <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <date month="June" year="2002"/>
            <abstract>
              <t indent="0">This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3264"/>
          <seriesInfo name="DOI" value="10.17487/RFC3264"/>
        </reference>
        <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="S. Casner" initials="S." surname="Casner"/>
            <author fullname="R. Frederick" initials="R." surname="Frederick"/>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="64"/>
          <seriesInfo name="RFC" value="3550"/>
          <seriesInfo name="DOI" value="10.17487/RFC3550"/>
        </reference>
        <reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4585" quoteTitle="true" derivedAnchor="RFC4585">
          <front>
            <title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</title>
            <author fullname="J. Ott" initials="J." surname="Ott"/>
            <author fullname="S. Wenger" initials="S." surname="Wenger"/>
            <author fullname="N. Sato" initials="N." surname="Sato"/>
            <author fullname="C. Burmeister" initials="C." surname="Burmeister"/>
            <author fullname="J. Rey" initials="J." surname="Rey"/>
            <date month="July" year="2006"/>
            <abstract>
              <t indent="0">Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4585"/>
          <seriesInfo name="DOI" value="10.17487/RFC4585"/>
        </reference>
        <reference anchor="RFC4855" target="https://www.rfc-editor.org/info/rfc4855" quoteTitle="true" derivedAnchor="RFC4855">
          <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 indent="0">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>
        <reference anchor="RFC5104" target="https://www.rfc-editor.org/info/rfc5104" quoteTitle="true" derivedAnchor="RFC5104">
          <front>
            <title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</title>
            <author fullname="S. Wenger" initials="S." surname="Wenger"/>
            <author fullname="U. Chandra" initials="U." surname="Chandra"/>
            <author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
            <author fullname="B. Burman" initials="B." surname="Burman"/>
            <date month="February" year="2008"/>
            <abstract>
              <t indent="0">This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.</t>
              <t indent="0">The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5104"/>
          <seriesInfo name="DOI" value="10.17487/RFC5104"/>
        </reference>
        <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t indent="0">This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8866" quoteTitle="true" derivedAnchor="RFC8866">
          <front>
            <title>SDP: Session Description Protocol</title>
            <author fullname="A. Begen" initials="A." surname="Begen"/>
            <author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/>
            <author fullname="C. Perkins" initials="C." surname="Perkins"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <date month="January" year="2021"/>
            <abstract>
              <t indent="0">This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8866"/>
          <seriesInfo name="DOI" value="10.17487/RFC8866"/>
        </reference>
        <reference anchor="RFC9627" target="https://www.rfc-editor.org/info/rfc9627" quoteTitle="true" derivedAnchor="RFC9627">
          <front>
            <title>The Layer Refresh Request (LRR) RTCP Feedback Message</title>
            <author initials="J." surname="Lennox" fullname="Jonathan Lennox">
              <organization showOnFrontPage="true">8x8, Inc. / Jitsi</organization>
            </author>
            <author initials="D." surname="Hong" fullname="Danny Hong">
              <organization showOnFrontPage="true">Google, Inc.</organization>
            </author>
            <author initials="J." surname="Uberti" fullname="Justin Uberti">
              <organization showOnFrontPage="true">OpenAI</organization>
            </author>
            <author initials="S." surname="Holmer" fullname="Stefan Holmer">
              <organization showOnFrontPage="true">Google, Inc.</organization>
            </author>
            <author initials="M." surname="Flodman" fullname="Magnus Flodman">
              <organization showOnFrontPage="true">Google, Inc.</organization>
            </author>
            <date month="March" year="2025"/>
          </front>
          <seriesInfo name="RFC" value="9627"/>
          <seriesInfo name="DOI" value="10.17487/RFC9627"/>
        </reference>
        <reference anchor="VP9-BITSTREAM" target="https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf" quoteTitle="true" derivedAnchor="VP9-BITSTREAM">
          <front>
            <title>VP9 Bitstream &amp; Decoding Process Specification</title>
            <author initials="A" surname="Grange" fullname="Adrian Grange">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author initials="P" surname="de Rivaz" fullname="Peter de Rivaz">
              <organization showOnFrontPage="true">Argon Design</organization>
            </author>
            <author initials="J" surname="Hunt" fullname="Jonathan Hunt">
              <organization showOnFrontPage="true">Argon Design</organization>
            </author>
            <date month="March" day="31" year="2016"/>
            <abstract>
              <t indent="0">
			  This document defines the bitstream format and decoding process for the
			  Google VP9 video codec.
              </t>
            </abstract>
          </front>
          <seriesInfo name="Version" value="0.6"/>
        </reference>
      </references>
      <references pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3551" quoteTitle="true" derivedAnchor="RFC3551">
          <front>
            <title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="S. Casner" initials="S." surname="Casner"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="65"/>
          <seriesInfo name="RFC" value="3551"/>
          <seriesInfo name="DOI" value="10.17487/RFC3551"/>
        </reference>
        <reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711">
          <front>
            <title>The Secure Real-time Transport Protocol (SRTP)</title>
            <author fullname="M. Baugher" initials="M." surname="Baugher"/>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="M. Naslund" initials="M." surname="Naslund"/>
            <author fullname="E. Carrara" initials="E." surname="Carrara"/>
            <author fullname="K. Norrman" initials="K." surname="Norrman"/>
            <date month="March" year="2004"/>
            <abstract>
              <t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3711"/>
          <seriesInfo name="DOI" value="10.17487/RFC3711"/>
        </reference>
        <reference anchor="RFC5124" target="https://www.rfc-editor.org/info/rfc5124" quoteTitle="true" derivedAnchor="RFC5124">
          <front>
            <title>Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)</title>
            <author fullname="J. Ott" initials="J." surname="Ott"/>
            <author fullname="E. Carrara" initials="E." surname="Carrara"/>
            <date month="February" year="2008"/>
            <abstract>
              <t indent="0">An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5124"/>
          <seriesInfo name="DOI" value="10.17487/RFC5124"/>
        </reference>
        <reference anchor="RFC6386" target="https://www.rfc-editor.org/info/rfc6386" quoteTitle="true" derivedAnchor="RFC6386">
          <front>
            <title>VP8 Data Format and Decoding Guide</title>
            <author fullname="J. Bankoski" initials="J." surname="Bankoski"/>
            <author fullname="J. Koleszar" initials="J." surname="Koleszar"/>
            <author fullname="L. Quillio" initials="L." surname="Quillio"/>
            <author fullname="J. Salonen" initials="J." surname="Salonen"/>
            <author fullname="P. Wilkins" initials="P." surname="Wilkins"/>
            <author fullname="Y. Xu" initials="Y." surname="Xu"/>
            <date month="November" year="2011"/>
            <abstract>
              <t indent="0">This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6386"/>
          <seriesInfo name="DOI" value="10.17487/RFC6386"/>
        </reference>
        <reference anchor="RFC7201" target="https://www.rfc-editor.org/info/rfc7201" quoteTitle="true" derivedAnchor="RFC7201">
          <front>
            <title>Options for Securing RTP Sessions</title>
            <author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
            <author fullname="C. Perkins" initials="C." surname="Perkins"/>
            <date month="April" year="2014"/>
            <abstract>
              <t indent="0">The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7201"/>
          <seriesInfo name="DOI" value="10.17487/RFC7201"/>
        </reference>
        <reference anchor="RFC7202" target="https://www.rfc-editor.org/info/rfc7202" quoteTitle="true" derivedAnchor="RFC7202">
          <front>
            <title>Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution</title>
            <author fullname="C. Perkins" initials="C." surname="Perkins"/>
            <author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
            <date month="April" year="2014"/>
            <abstract>
              <t indent="0">This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7202"/>
          <seriesInfo name="DOI" value="10.17487/RFC7202"/>
        </reference>
        <reference anchor="RFC7667" target="https://www.rfc-editor.org/info/rfc7667" quoteTitle="true" derivedAnchor="RFC7667">
          <front>
            <title>RTP Topologies</title>
            <author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
            <author fullname="S. Wenger" initials="S." surname="Wenger"/>
            <date month="November" year="2015"/>
            <abstract>
              <t indent="0">This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7667"/>
          <seriesInfo name="DOI" value="10.17487/RFC7667"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1"><contact fullname="Alex Eleftheriadis"/>, <contact fullname="Yuki       Ito"/>, <contact fullname="Won Kap Jang"/>, <contact fullname="Sergio       Garcia"/> <contact fullname="Murillo"/>, <contact fullname="Roi       Sasson"/>, <contact fullname="Timothy Terriberry"/>, <contact fullname="Emircan Uysaler"/>, and <contact fullname="Thomas Volkert"/>
      commented on the development of this document and provided helpful
      feedback.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Justin Uberti" initials="J." surname="Uberti">
        <organization showOnFrontPage="true">OpenAI</organization>
        <address>
          <postal>
            <street>1455 3rd St</street>
            <city>San Francisco</city>
            <region>CA</region>
            <code>94158</code>
            <country>United States of America</country>
          </postal>
          <email>justin@uberti.name</email>
        </address>
      </author>
      <author fullname="Stefan Holmer" initials="S." surname="Holmer">
        <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization>
        <address>
          <postal>
            <street>Kungsbron 2</street>
            <code>111 22</code>
            <city>Stockholm</city>
            <country>Sweden</country>
          </postal>
          <email>holmer@google.com</email>
        </address>
      </author>
      <author fullname="Magnus Flodman" initials="M." surname="Flodman">
        <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization>
        <address>
          <postal>
            <street>Kungsbron 2</street>
            <code>111 22</code>
            <city>Stockholm</city>
            <country>Sweden</country>
          </postal>
          <email>mflodman@google.com</email>
        </address>
      </author>
      <author fullname="Danny Hong" initials="D." surname="Hong">
        <organization abbrev="Google" showOnFrontPage="true">Google, Inc.</organization>
        <address>
          <postal>
            <street>315 Hudson St.</street>
            <city>New York</city>
            <region>NY</region>
            <code>10013</code>
            <country>United States of America</country>
          </postal>
          <email>dannyhong@google.com</email>
        </address>
      </author>
      <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
        <organization abbrev="8x8 / Jitsi" showOnFrontPage="true">8x8, Inc. / Jitsi</organization>
        <address>
          <postal>
            <street/>
            <city>Jersey City</city>
            <region>NJ</region>
            <code>07302</code>
            <country>United States of America</country>
          </postal>
          <email>jonathan.lennox@8x8.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
