Dos2unix, trailing whitespace on draft-spittka-payload-rtp-opus.xml.
authorGregory Maxwell <greg@xiph.org>
Tue, 19 Jun 2012 13:11:40 +0000 (09:11 -0400)
committerGregory Maxwell <greg@xiph.org>
Tue, 19 Jun 2012 13:11:40 +0000 (09:11 -0400)
doc/draft-spittka-payload-rtp-opus.xml

index 339d786..042d171 100644 (file)
-<?xml version="1.0" encoding="UTF-8"?>\r
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [\r
-<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>\r
-<!ENTITY rfc3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>\r
-<!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'>\r
-<!ENTITY rfc3551 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml'>\r
-<!ENTITY rfc4288 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'>\r
-<!ENTITY rfc4855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml'>\r
-<!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>\r
-<!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>\r
-<!ENTITY rfc2974 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml'>\r
-<!ENTITY rfc2326 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml'>\r
-<!ENTITY rfc3555 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3555.xml'>\r
-<!ENTITY rfc6562 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6562.xml'>\r
-  \r
-  ]>\r
-\r
-  <rfc category="info" ipr="trust200902" docName="draft-spittka-payload-rtp-opus-01.txt">\r
-<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>\r
-\r
-<?rfc strict="yes" ?>\r
-<?rfc toc="yes" ?>\r
-<?rfc tocdepth="3" ?>\r
-<?rfc tocappendix='no' ?>\r
-<?rfc tocindent='yes' ?>\r
-<?rfc symrefs="yes" ?>\r
-<?rfc sortrefs="yes" ?>\r
-<?rfc compact="no" ?>\r
-<?rfc subcompact="yes" ?>\r
-<?rfc iprnotified="yes" ?>\r
-\r
-  <front>\r
-    <title abbrev="RTP Payload Format for Opus Codec">\r
-      RTP Payload Format for Opus Speech and Audio Codec\r
-    </title>\r
-\r
-    <author fullname="Julian Spittka" initials="J." surname="Spittka">\r
-      <organization>Skype Technologies S.A.</organization>\r
-      <address>\r
-        <postal>\r
-          <street>3210 Porter Drive</street>\r
-          <code>94304</code>\r
-          <city>Palo Alto</city>\r
-          <region>CA</region>\r
-          <country>USA</country>\r
-        </postal>\r
-        <email>julian.spittka@skype.net</email>\r
-      </address>\r
-    </author>\r
-\r
-    <author initials='K.' surname='Vos' fullname='Koen Vos'>\r
-      <organization>Skype Technologies S.A.</organization>\r
-      <address>\r
-        <postal>\r
-          <street>3210 Porter Drive</street>\r
-          <code>94304</code>\r
-          <city>Palo Alto</city>\r
-          <region>CA</region>\r
-          <country>USA</country>\r
-        </postal>\r
-        <email>koen.vos@skype.net</email>\r
-      </address>\r
-    </author>\r
-\r
-    <author initials="JM" surname="Valin" fullname="Jean-Marc Valin">\r
-      <organization>Mozilla</organization>\r
-      <address>\r
-        <postal>\r
-          <street>650 Castro Street</street>\r
-          <city>Mountain View</city>\r
-          <region>CA</region>\r
-          <code>94041</code>\r
-          <country>USA</country>\r
-        </postal>\r
-        <email>jmvalin@jmvalin.ca</email>\r
-      </address>\r
-    </author>\r
-\r
-    <date day='1' month='May' year='2012' />\r
-\r
-    <abstract>\r
-      <t>\r
-        This document defines the Real-time Transport Protocol (RTP) payload\r
-        format for packetization of Opus encoded \r
-        speech and audio data that is essential to integrate the codec in the \r
-        most compatible way. Further, media type registrations \r
-        are described for the RTP payload format.\r
-      </t>\r
-    </abstract>\r
-  </front>\r
-\r
-  <middle>\r
-    <section title='Introduction'>\r
-      <t>\r
-        The Opus codec is a speech and audio codec developed within the\r
-        IETF Internet Wideband Audio Codec working group [codec]. The codec \r
-        has a very low algorithmic delay and is\r
-        is highly scalable in terms of audio bandwidth, bitrate, and\r
-        complexity. Further, it provides different modes to efficiently encode speech signals\r
-        as well as music signals, thus, making it the codec of choice for\r
-        various applications using the Internet or similar networks.\r
-      </t>\r
-      <t>\r
-        This document defines the Real-time Transport Protocol (RTP)\r
-        <xref target="RFC3550"/> payload format for packetization\r
-        of Opus encoded speech and audio data that is essential to\r
-        integrate the Opus codec in the\r
-        most compatible way. Further, media type registrations are described for\r
-        the RTP payload format. More information on the Opus\r
-        codec can be obtained from the following IETF draft \r
-        [Opus].\r
-      </t>\r
-    </section>\r
-\r
-    <section title='Conventions, Definitions and Acronyms used in this document'>\r
-      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
-      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
-      document are to be interpreted as described in <xref target="RFC2119"/>.</t>\r
-      <t>\r
-      <list style='hanging'>\r
-        <t hangText="CPU:"> Central Processing Unit</t>\r
-             <t hangText="IP:"> Internet Protocol</t>\r
-             <t hangText="PSTN:"> Public Switched Telephone Network</t>\r
-             <t hangText="samples:"> Speech or audio samples</t>\r
-             <t hangText="SDP:"> Session Description Protocol</t>\r
-      </list>\r
-      </t>\r
-      <section title='Audio Bandwidth'>\r
-       <t>\r
-         Throughout this document, we refer to the following definitions:\r
-       </t>\r
-          <texttable anchor='bandwidth_definitions'>\r
-           <ttcol align='center'>Abbreviation</ttcol>\r
-            <ttcol align='center'>Name</ttcol>\r
-            <ttcol align='center'>Bandwidth</ttcol>\r
-            <ttcol align='center'>Sampling</ttcol>\r
-            <c>nb</c>\r
-            <c>Narrowband</c>\r
-            <c>0 - 4000</c>\r
-            <c>8000</c>\r
-\r
-            <c>mb</c>\r
-            <c>Mediumband</c>\r
-            <c>0 - 6000</c>\r
-            <c>12000</c>\r
-\r
-            <c>wb</c>\r
-            <c>Wideband</c>\r
-            <c>0 - 8000</c>\r
-            <c>16000</c>\r
-           \r
-            <c>swb</c>\r
-            <c>Super-wideband</c>\r
-            <c>0 - 12000</c>\r
-            <c>24000</c>\r
-           \r
-            <c>fb</c>\r
-            <c>Fullband</c>\r
-            <c>0 - 20000</c>\r
-            <c>48000</c>\r
-\r
-            <postamble>\r
-              Audio bandwidth naming\r
-            </postamble>\r
-          </texttable>\r
-      </section>\r
-    </section>\r
-\r
-    <section title='Opus Codec'>\r
-      <t>\r
-        The Opus [Opus] speech and audio codec has been developed to encode speech\r
-        signals as well as audio signals. Two different modes, a voice mode \r
-        or an audio mode, may be chosen to allow the most efficient coding \r
-        dependent on the type of input signal, the sampling frequency of the \r
-        input signal, and the specific application.\r
-      </t>\r
-\r
-      <t>\r
-        The voice mode allows to efficiently encode voice signals at lower bit\r
-        rates while the audio mode is optimized for audio signals at medium and \r
-        higher bitrates. \r
-      </t>\r
-\r
-      <t>\r
-        The Opus speech and audio codec is highly scalable in terms of audio\r
-        bandwidth and bitrate and complexity. Further, Opus allows to\r
-        transmit stereo signals.\r
-      </t>\r
-\r
-      <section title='Network Bandwidth'>\r
-          <t>\r
-           Opus supports all bitrates from 6&nbsp;kb/s to 510&nbsp;kb/s. \r
-           The bitrate can be changed dynamically within that range. \r
-           All \r
-           other parameters being\r
-           equal, higher bitrate results in higher quality. \r
-         </t>\r
-         <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'>\r
-         <t>\r
-           For a frame size of \r
-           20&nbsp;ms, these\r
-           are the bitrate "sweet spots" for Opus in various configurations:\r
-           \r
-\r
-          <list style="symbols">\r
-           <t>8-12 kb/s for NB speech,</t>\r
-           <t>16-20 kb/s for WB speech,</t>\r
-           <t>28-40 kb/s for FB speech,</t>\r
-           <t>48-64 kb/s for FB mono music, and</t>\r
-           <t>64-128 kb/s for FB stereo music.</t>\r
-         </list>\r
-       </t>\r
-      </section>\r
-        <section title='Variable versus Constant Bit Rate'  anchor='variable-vs-constant-bitrate'>\r
-          <t>\r
-           For the same average bitrate, variable bitrate (VBR) can achieve higher quality\r
-           than constant bitrate (CBR). For the majority of voice transmission application, VBR\r
-           is the best choice. One potential reason for choosing CBR is the potential \r
-           information leak that <spanx style='emph'>may</spanx> occur when encrypting the\r
-           compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is\r
-           appropriate for encrypted audio communications. In the case where an existing\r
-           VBR stream needs to be converted to CBR for security reasons, then the Opus padding\r
-           mechanism described in [Opus] is the RECOMMENDED way to achieve padding\r
-           because the RTP padding bit is unencrypted.</t>\r
-           \r
-           <t> \r
-            The bitrate can be adjusted at any point in time. To avoid congestion,\r
-            the average bitrate SHOULD be adjusted to the available\r
-            network capacity. If no target bitrate is specified the average bitrate \r
-            may go up to the highest bitrate specified in \r
-            <xref target='bitrate_by_bandwidth'/>. \r
-          </t>\r
-            \r
-        </section>\r
-\r
-        <section title='Discontinuous Transmission (DTX)'>\r
-\r
-          <t>\r
-            The Opus codec may, as described in <xref target='variable-vs-constant-bitrate'/>, \r
-            be operated with an adaptive bitrate. In that case, the bitrate \r
-            will automatically be reduced for certain input signals like periods \r
-            of silence. During continuous transmission the bitrate will be \r
-            reduced, when the input signal allows to do so, but the transmission \r
-            to the receiver itself will never be interrupted. Therefore, the \r
-            received signal will maintain the same high level of quality over the \r
-            full duration of a transmission while minimizing the average bit \r
-            rate over time.\r
-          </t>\r
-\r
-          <t>\r
-            In cases where the bitrate of Opus needs to be reduced even\r
-            further or in cases where only constant bitrate is available, \r
-            the Opus encoder may be set to use discontinuous\r
-            transmission (DTX), where parts of the encoded signal that\r
-            correspond to periods of silence in the input speech or audio signal\r
-            are not transmitted to the receiver.\r
-          </t>\r
-\r
-          <t>\r
-            On the receiving side, the non-transmitted parts will be handled by a\r
-            frame loss concealment unit in the Opus decoder which generates a\r
-            comfort noise signal to replace the non transmitted parts of the\r
-            speech or audio signal.\r
-          </t>\r
-\r
-          <t>\r
-            The DTX mode of Opus will have a slightly lower speech or audio\r
-            quality than the continuous mode. Therefore, it is RECOMMENDED to\r
-            use Opus in the continuous mode unless restraints on network\r
-            capacity are severe. The DTX mode can be engaged for operation\r
-            in both adaptive or constant bitrate.\r
-          </t>\r
-\r
-        </section>\r
-        \r
-        </section>\r
-\r
-      <section title='Complexity'>\r
-\r
-        <t>\r
-          Complexity can be scaled to optimize for CPU resources in real-time, mostly as\r
-          a trade-off between audio quality and bitrate. Also, different modes of Opus have different complexity.\r
-        </t>\r
-        \r
-      </section>\r
-\r
-      <section title="Forward Error Correction (FEC)">\r
-\r
-        <t>\r
-          The voice mode of Opus allows for "in-band" forward error correction (FEC)\r
-          data to be embedded into the bit stream of Opus. This FEC scheme adds\r
-          redundant information about the previous packet (n-1) to the current \r
-          output packet n. For\r
-          each frame, the encoder decides whether to use FEC based on (1) an\r
-          externally-provided estimate of the channel's packet loss rate; (2) an\r
-          externally-provided estimate of the channel's capacity; (3) the\r
-          sensitivity of the audio or speech signal to packet loss; (4) whether\r
-          the receiving decoder has indicated it can take advantage of "in-band"\r
-          FEC information. The decision to send "in-band" FEC information is\r
-          entirely controlled by the encoder and therefore no special precautions\r
-          for the payload have to be taken.\r
-        </t>\r
-\r
-        <t>\r
-          On the receiving side, the decoder can take advantage of this\r
-          additional information when, in case of a packet loss, the next packet\r
-          is available.  In order to use the FEC data, the jitter buffer needs\r
-          to provide access to payloads with the FEC data.  The decoder API function\r
-          has a flag to indicate that a FEC frame rather than a regular frame should\r
-          be decoded.  If no FEC data is available for the current frame, the decoder\r
-          will consider the frame lost and invokes the frame loss concealment.\r
-        </t>\r
-\r
-        <t>\r
-          If the FEC scheme is not implemented on the receiving side, FEC\r
-          SHOULD NOT be used, as it leads to an inefficient usage of network\r
-          resources. Decoder support for FEC SHOULD be indicated at the time a\r
-          session is set up.\r
-        </t>\r
-      \r
-      </section>\r
-\r
-      <section title='Stereo Operation'>\r
-\r
-        <t>\r
-          Opus allows for transmission of stereo audio signals. This operation\r
-          is signaled in-band in the Opus payload and no special arrangement\r
-          is required in the payload format. Any implementation of the Opus\r
-          decoder MUST be capable of receiving stereo signals.\r
-        </t>\r
-        <t>\r
-          If a decoder can not take advantage of the benefits of a stereo signal \r
-          this SHOULD be indicated at the time a session is set up. In that case\r
-          the sending side SHOULD NOT send stereo signals as it leads to an \r
-          inefficient usage of the network.\r
-        </t>\r
-\r
-      </section>\r
-\r
-    </section>\r
\r
-    <section title='Opus RTP Payload Format' anchor='opus-rtp-payload-format'>\r
-      <t>The payload format for Opus consists of the RTP header and Opus payload\r
-      data.</t>\r
-      <section title='RTP Header Usage'>\r
-        <t>The format of the RTP header is specified in <xref target="RFC3550"/>. The Opus\r
-        payload format uses the fields of the RTP header consistent with this\r
-        specification.</t>\r
-\r
-        <t>The payload length of Opus is a multiple number of octets and\r
-        therefore no padding is required. The payload MAY be padded by an\r
-        integer number of octets according to <xref target="RFC3550"/>.</t>\r
-\r
-        <t>The marker bit (M) of the RTP header has no function in combination\r
-        with Opus and MAY be ignored.</t>\r
-\r
-        <t>The RTP payload type for Opus has not been assigned statically and is\r
-        expected to be assigned dynamically.</t>\r
-\r
-        <t>The receiving side MUST be prepared to receive duplicates of RTP\r
-        packets. Only one of those payloads MUST be provided to the Opus decoder\r
-        for decoding and others MUST be discarded.</t>\r
-\r
-        <t>Opus supports 5 different audio bandwidths which may be adjusted during\r
-        the duration of a call. The RTP timestamp clock frequency is defined as \r
-        the highest supported sampling frequency of Opus, i.e. 48000 Hz, for all \r
-        modes and sampling rates of Opus. The unit\r
-        for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the\r
-        sample time of the first encoded sample in the encoded frame. For sampling\r
-        rates lower than 48000 Hz the number of samples has to be multiplied with \r
-        a multiplier according to <xref target="fs-upsample-factors"/> to determine \r
-        the RTP timestamp.</t>\r
-\r
-        <texttable anchor='fs-upsample-factors'>\r
-          <ttcol align='center'>fs (Hz)</ttcol>\r
-          <ttcol align='center'>Multiplier</ttcol>\r
-          <c>8000</c>\r
-          <c>6</c>\r
-          <c>12000</c>\r
-          <c>4</c>\r
-          <c>16000</c>\r
-          <c>3</c>\r
-          <c>24000</c>\r
-          <c>2</c>\r
-          <c>48000</c>\r
-          <c>1</c>\r
-          <postamble>\r
-            fs specifies the audio sampling frequency in Hertz (Hz); Multiplier is the \r
-            value that the number of samples have to be multiplied with to calculate \r
-            the RTP timestamp.\r
-          </postamble>\r
-        </texttable>\r
-      </section>\r
-\r
-      <section title='Payload Structure'>\r
-        <t>\r
-          The Opus encoder can be set to output encoded frames representing 2.5, 5, 10, 20,\r
-          40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be\r
-          combined into a packet. The maximum packet length is limited to the amount of encoded\r
-          data representing 120 ms of speech or audio data. The packetization of encoded data\r
-          is purely done by the Opus encoder and therefore only one packet output from the Opus\r
-          encoder MUST be used as a payload.\r
-        </t>\r
-\r
-        <t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t>\r
-\r
-        <figure anchor="payload-structure"\r
-                title="Payload Structure with RTP header">\r
-          <artwork>\r
-            <![CDATA[\r
-+----------+--------------+\r
-|RTP Header| Opus Payload |\r
-+----------+--------------+\r
-           ]]>\r
-          </artwork>\r
-        </figure>\r
-\r
-        <t>\r
-          <xref target='opus-packetization'/> shows supported frame sizes for different modes\r
-          and sampling rates of Opus and how the timestamp needs to be incremented for \r
-          packetization.\r
-        </t>\r
-\r
-        <texttable anchor='opus-packetization'>\r
-            <ttcol align='center'>Mode</ttcol>\r
-            <ttcol align='center'>fs</ttcol>\r
-            <ttcol align='center'>2.5</ttcol>\r
-            <ttcol align='center'>5</ttcol>\r
-            <ttcol align='center'>10</ttcol>\r
-            <ttcol align='center'>20</ttcol>\r
-            <ttcol align='center'>40</ttcol>\r
-            <ttcol align='center'>60</ttcol>\r
-            <c>ts incr</c>\r
-            <c>all</c>\r
-            <c>120</c>\r
-            <c>240</c>\r
-            <c>480</c>\r
-            <c>960</c>\r
-            <c>1920</c>\r
-            <c>2880</c>\r
-            <c>voice</c>\r
-            <c>nb/mb/wb/swb/fb</c>\r
-            <c></c>\r
-            <c></c>\r
-            <c>x</c>\r
-            <c>x</c>\r
-            <c>x</c>\r
-            <c>x</c>\r
-            <c>audio</c>\r
-            <c>nb/wb/swb/fb</c>\r
-            <c>x</c>\r
-            <c>x</c>\r
-            <c>x</c>\r
-            <c>x</c>\r
-            <c></c>\r
-            <c></c>\r
-            <postamble>\r
-              Mode specifies the Opus mode of operation; fs specifies the audio sampling \r
-              frequency in Hertz (Hz); 2.5, 5, 10, 20, 40, and 60 represent the duration of \r
-              encoded speech or audio data in a packet; ts incr specifies the \r
-              value the timestamp needs to be incremented for the representing packet size.\r
-              For multiple frames in a packet these values have to be multiplied with the \r
-              respective number of frames.\r
-            </postamble>\r
-          </texttable>\r
-\r
-      </section>\r
-\r
-    </section>\r
-\r
-    <section title='Congestion Control'>\r
-      \r
-      <t>The adaptive nature of the Opus codec allows for an efficient\r
-      congestion control.</t>\r
-\r
-      <t>The target bitrate of Opus can be adjusted at any point in time and \r
-      thus allowing for an efficient congestion control. Furthermore, the amount\r
-      of encoded speech or audio data encoded in a \r
-      single packet can be used for congestion control since the transmission \r
-      rate is inversely proportional to these frame sizes. A lower packet \r
-      transmission rate reduces the amount of header overhead but at the same \r
-      time increases latency and error sensitivity and should be done with care.</t>\r
-\r
-      <t>It is RECOMMENDED that congestion control is applied during the\r
-      transmission of Opus encoded data.</t>\r
-    </section>\r
-\r
-    <section title='IANA Considerations'>\r
-      <t>One media subtype (audio/opus) has been defined and registered as\r
-      described in the following section.</t>\r
-\r
-      <section title='Opus Media Type Registration'>\r
-        <t>Media type registration is done according to <xref\r
-        target="RFC4288"/> and <xref target="RFC4855"/>.<vspace\r
-        blankLines='1'/></t>\r
-\r
-          <t>Type name: audio<vspace blankLines='1'/></t>\r
-          <t>Subtype name: opus<vspace blankLines='1'/></t>\r
-\r
-          <t>Required parameters:</t>\r
-          <t><list style="hanging">\r
-            <t hangText="rate:"> RTP timestamp clock rate is incremented with \r
-            48000 Hz clock rate for all modes of Opus and all sampling \r
-            frequencies. For audio sampling rates other than 48000 Hz the rate\r
-            has to be adjusted to 48000 Hz according to <xref target="fs-upsample-factors"/>.\r
-          </t>\r
-          </list></t>\r
-\r
-          <t>Optional parameters:</t>\r
-          \r
-          <t><list style="hanging">\r
-            <t hangText="maxcodedaudiobandwidth:">\r
-              a hint about the maximum audio bandwidth that the receiver is capable of rendering.\r
-             The decoder MUST be capable of decoding \r
-              any audio bandwidth but due to hardware limitations only signals \r
-              up to the specified audio bandwidth can be processed. Sending signals \r
-              with higher audio bandwidth results in higher than necessary network \r
-              usage and encoding complexity, so an encoder SHOULD NOT encode\r
-             frequencies above the audio bandwidth specified by maxcodedaudiobandwidth. \r
-             Possible values are nb, mb, wb, swb, fb. By default, the receiver\r
-             is assumed to have no limitations, i.e. fb. \r
-              <vspace blankLines='1'/>\r
-            </t>\r
-            \r
-            <t hangText="maxptime:"> the decoder's maximum length of time in\r
-            milliseconds rounded up to the next full integer value represented \r
-            by the media in a packet that can be\r
-            encapsulated in a received packet according to Section 6 of\r
-            <xref target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, \r
-            and 60 or an arbitrary multiple of Opus frame sizes rounded up to \r
-            the next full integer value up to a maximum value of 120 as \r
-            defined in <xref target='opus-rtp-payload-format'/>. If no value is\r
-              specified, 120 is assumed as default. This value is a recommendation \r
-              by the decoding side to ensure the best\r
-              performance for the decoder. The decoder MUST be\r
-              capable of accepting any allowed packet sizes to\r
-              ensure maximum compatibility.\r
-              <vspace blankLines='1'/></t>\r
-            \r
-            <t hangText="ptime:"> the decoder's recommended length of time in\r
-            milliseconds rounded up to the next full integer value represented \r
-            by the media in a packet according to\r
-            Section 6 of <xref target="RFC4566"/>. Possible values are\r
-            3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes \r
-            rounded up to the next full integer value up to a maximum \r
-            value of 120 as defined in <xref\r
-            target='opus-rtp-payload-format'/>. If no value is\r
-              specified, 20 is assumed as default. If ptime is greater than\r
-              maxptime, ptime MUST be ignored. This parameter MAY be changed\r
-              during a session. This value is a recommendation by the decoding \r
-              side to ensure the best\r
-              performance for the decoder. The decoder MUST be\r
-              capable of accepting any allowed packet sizes to\r
-              ensure maximum compatibility.\r
-              <vspace blankLines='1'/></t>\r
-            \r
-            <t hangText="minptime:"> the decoder's minimum length of time in\r
-            milliseconds rounded up to the next full integer value represented \r
-            by the media in a packet that SHOULD\r
-            be encapsulated in a received packet according to Section 6 of <xref\r
-            target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, and 60 \r
-            or an arbitrary multiple of Opus frame sizes rounded up to the next \r
-            full integer value up to a maximum value of 120\r
-            as defined in <xref target='opus-rtp-payload-format'/>. If no value is\r
-              specified, 3 is assumed as default. This value is a recommendation \r
-              by the decoding side to ensure the best\r
-              performance for the decoder. The decoder MUST be\r
-              capable to accept any allowed packet sizes to\r
-              ensure maximum compatibility.\r
-              <vspace blankLines='1'/></t>\r
-\r
-            <t hangText="maxaveragebitrate:"> specifies the maximum average\r
-           receive bitrate of a session in bits per second (b/s). The actual\r
-            value of the bitrate may vary as it is dependent on the\r
-            characteristics of the media in a packet. Note that the maximum\r
-            average bitrate MAY be modified dynamically during a session. Any\r
-            positive integer is allowed but values outside the range between \r
-            6000 and 510000 SHOULD be ignored. If no value is specified, the \r
-            maximum value specified in <xref target='bitrate_by_bandwidth'/>\r
-            for the corresponding mode of Opus and corresponding maxcodedaudiobandwidth: \r
-            will be the default.<vspace blankLines='1'/></t>\r
-\r
-            <t hangText="stereo:">\r
-              specifies whether the decoder prefers receiving stereo or mono signals.\r
-              Possible values are 1 and 0 where 1 specifies that stereo signals are preferred\r
-              and 0 specifies that only mono signals are preferred.\r
-              Independent of the stereo parameter every receiver MUST be able to receive and\r
-              decode stereo signals but sending stereo signals to a receiver that signaled a\r
-              preference for mono signals may result in higher than necessary network\r
-              utilisation and encoding complexity. If no value is specified, mono\r
-              is assumed (stereo=0).<vspace blankLines='1'/>\r
-            </t>\r
-            \r
-            <t hangText="cbr:">\r
-              specifies if the decoder prefers the use of a constant bitrate versus\r
-              variable bitrate. Possible values are 1 and 0 where 1 specifies constant \r
-              bitrate and 0 specifies variable bitrate. If no value is specified, cbr\r
-              is assumed to be 0. Note that the maximum average bitrate may still be \r
-              changed, e.g. to adapt to changing network conditions.<vspace blankLines='1'/>\r
-            </t>\r
-\r
-            <t hangText="useinbandfec:"> specifies that Opus in-band FEC is\r
-            supported by the decoder and MAY be used during a\r
-            session. Possible values are 1 and 0. It is RECOMMENDED to provide\r
-            0 in case FEC is not implemented on the receiving side. If no\r
-            value is specified, useinbandfec is assumed to be 1.<vspace blankLines='1'/></t>\r
-\r
-            <t hangText="usedtx:"> specifies if the decoder prefers the use of\r
-            DTX. Possible values are 1 and 0. If no value is specified, usedtx\r
-            is assumed to be 0.<vspace blankLines='1'/></t>\r
-          </list></t>\r
-\r
-          <t>Encoding considerations:<vspace blankLines='1'/></t>\r
-          <t><list style="hanging">\r
-            <t>Opus media type is framed and consists of binary data according\r
-            to Section 4.8 in <xref target="RFC4288"/>.</t>\r
-          </list></t>\r
-          \r
-          <t>Security considerations: </t>\r
-          <t><list style="hanging">\r
-            <t>See <xref target='security-considerations'/> of this document.</t>\r
-          </list></t>\r
-\r
-          <t>Interoperability considerations: none<vspace blankLines='1'/></t>\r
-          <t>Published specification: none<vspace blankLines='1'/></t>\r
-\r
-          <t>Applications that use this media type: </t>\r
-          <t><list style="hanging">\r
-            <t>Any application that requires the transport of\r
-            speech or audio data may use this media type. Some examples are,\r
-            but not limited to, audio and video conferencing, Voice over IP,\r
-            media streaming.</t>\r
-          </list></t>\r
-          \r
-          <t>Person & email address to contact for further information:</t>\r
-          <t><list style="hanging">\r
-            <t>SILK Support silksupport@skype.net</t>\r
-            <t>Jean-Marc Valin jmvalin@jmvalin.ca</t>\r
-          </list></t>\r
-          \r
-          <t>Intended usage: COMMON<vspace blankLines='1'/></t>\r
-          \r
-          <t>Restrictions on usage:<vspace blankLines='1'/></t> \r
-          \r
-          <t><list style="hanging">\r
-            <t>For transfer over RTP, the RTP payload format (<xref\r
-            target='opus-rtp-payload-format'/> of this document) SHALL be\r
-            used.</t>\r
-          </list></t>\r
-          \r
-          <t>Author:</t>\r
-          <t><list style="hanging">\r
-            <t>Julian Spittka julian.spittka@skype.net<vspace blankLines='1'/></t>\r
-            <t>Koen Vos koen.vos@skype.net<vspace blankLines='1'/></t>\r
-            <t>Jean-Marc Valin jmvalin@jmvalin.ca<vspace blankLines='1'/></t>\r
-          </list></t>\r
-          \r
-          <t> Change controller: TBD</t>\r
-      </section>\r
-      \r
-      <section title='Mapping to SDP Parameters'>\r
-        <t>The information described in the media type specification has a\r
-        specific mapping to fields in the Session Description Protocol (SDP)\r
-        <xref target="RFC4566"/>, which is commonly used to describe RTP\r
-        sessions. When SDP is used to specify sessions employing the Opus codec,\r
-        the mapping is as follows:</t>\r
-\r
-        <t>\r
-          <list style="symbols">\r
-            <t>The media type ("audio") goes in SDP "m=" as the media name.</t>\r
-          \r
-            <t>The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding\r
-            name. The RTP clock rate in "a=rtpmap" MUST be mapped to the required\r
-            media type parameter "rate".</t>\r
-\r
-            <t>The optional media type parameters "ptime" and "maxptime" are\r
-            mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the\r
-            SDP.</t>\r
-\r
-            <t>All remaining media type parameters are mapped to the "a=fmtp"\r
-            attribute in the SDP by copying them directly from the media type\r
-            parameter string as a semicolon-separated list of parameter=value\r
-            pairs (e.g. maxaveragebitrate=20000).</t>\r
-          </list>\r
-        </t>\r
-\r
-        <t>Below are some examples of SDP session descriptions for Opus:</t>\r
-\r
-        <t>Example 1: Standard session with 48000 Hz clock rate</t>\r
-          <figure>  \r
-            <artwork>\r
-              <![CDATA[\r
-    m=audio 54312 RTP/AVP 101\r
-    a=rtpmap:101 opus/48000\r
-              ]]>\r
-            </artwork>\r
-          </figure>\r
-\r
-\r
-        <t>Example 2: 16000 Hz clock rate, maximum packet size of 40 ms,\r
-        recommended packet size of 40 ms, maximum average bitrate of 20000 bps,\r
-        stereo signals are preferred, FEC is allowed, DTX is not allowed</t>\r
-\r
-        <figure>  \r
-          <artwork> \r
-            <![CDATA[\r
-    m=audio 54312 RTP/AVP 101\r
-    a=rtpmap:101 opus/48000\r
-    a=fmtp:101 maxcodedaudiobandwidth=wb; maxaveragebitrate=20000; \r
-    stereo=1; useinbandfec=1; usedtx=0\r
-    a=ptime:40\r
-    a=maxptime:40\r
-            ]]>\r
-          </artwork> \r
-        </figure>\r
-\r
-      <section title='Offer-Answer Model Considerations for Opus'>\r
-\r
-          <t>When using the offer-answer procedure described in <xref\r
-          target="RFC3264"/> to negotiate the use of Opus, the following\r
-          considerations apply:</t>\r
-\r
-          <t><list style="symbols">\r
-\r
-            <t>Opus supports several clock rates. For signaling purposes only\r
-            the highest, i.e. 48000, is used. The actual clock rate of the \r
-            corresponding media is signaled inside the payload and is not \r
-            subject to this payload format description. The decoder MUST be\r
-            capable to decode every received clock rate. An example\r
-            is shown below:\r
-\r
-            <figure>  \r
-              <artwork> \r
-                <![CDATA[\r
-        m=audio 54312 RTP/AVP 100\r
-        a=rtpmap:100 opus/48000\r
-                ]]> \r
-              </artwork> \r
-            </figure>\r
-            </t>\r
-\r
-            <t>The parameters "ptime" and "maxptime" are unidirectional\r
-            receive-only parameters and typically will not compromise\r
-            interoperability; however, dependent on the set values of the\r
-            parameters the performance of the application may suffer.  <xref\r
-            target="RFC3264"/> defines the SDP offer-answer handling of the\r
-            "ptime" parameter. The "maxptime" parameter MUST be handled in the\r
-            same way.</t>\r
-\r
-            <t>\r
-              The parameter "minptime" is a unidirectional\r
-              receive-only parameters and typically will not compromise\r
-              interoperability; however, dependent on the set values of the\r
-              parameter the performance of the application may suffer and should be\r
-              set with care.\r
-            </t>\r
-\r
-            <t>\r
-              The parameter "maxcodedaudiobandwidth" is a unidirectional receive-only\r
-              parameter that reflects limitations of the local receiver. The sender\r
-              of the other side SHOULD NOT send with an audio bandwidth higher than\r
-              "maxcodedaudiobandwidth" as this would lead to inefficient use of network resources. The "maxcodedaudiobandwidth" parameter does not \r
-             affect interoperability. Also, this parameter SHOULD NOT be used\r
-             to adjust the audio bandwidth as a function of the bitrates, as this\r
-             is the responsability of the Opus encoder implementation.\r
-            </t>\r
-            \r
-            <t>The parameter "maxaveragebitrate" is a unidirectional receive-only\r
-            parameter that reflects limitations of the local receiver. The sender\r
-            of the other side MUST NOT send with an average bitrate higher than\r
-            "maxaveragebitrate" as it might overload the network and/or\r
-            receiver. The parameter "maxaveragebitrate" typically will not\r
-            compromise interoperability; however, dependent on the set value of\r
-            the parameter the performance of the application may suffer and should\r
-            be set with care.</t>\r
-            \r
-            <t>If the parameter "maxaveragebitrate" is below the range specified\r
-            in <xref target='bitrate_by_bandwidth'/> the session MUST be rejected.</t>\r
-\r
-            <t>\r
-              The parameter "stereo" is a unidirectional receive-only\r
-              parameter.\r
-            </t>\r
-\r
-            <t>\r
-              The parameter "cbr" is a unidirectional receive-only\r
-              parameter.\r
-            </t>\r
-\r
-            <t>The parameter "useinbandfec" is a unidirectional receive-only\r
-            parameter.</t>\r
-            \r
-            <t>The parameter "usedtx" is a unidirectional receive-only\r
-            parameter.</t>\r
-            \r
-            <t>Any unknown parameter in an offer MUST be ignored by the receiver\r
-            and MUST be removed from the answer.</t>\r
-            \r
-          </list></t>\r
-      </section>\r
-\r
-      <section title='Declarative SDP Considerations for Opus'>\r
-\r
-        <t>For declarative use of SDP such as in Session Announcement Protocol\r
-        (SAP), <xref target="RFC2974"/>, and RTSP, <xref target="RFC2326"/>, for\r
-        Opus, the following needs to be considered:</t>\r
-\r
-        <t><list style="symbols">\r
-\r
-          <t>The values for "maxptime", "ptime", "minptime", "maxcodedaudiobandwidth", and \r
-          "maxaveragebitrate" should be selected carefully to ensure that a \r
-          reasonable performance can be achieved for the participants of a session.</t>\r
-\r
-          <t>\r
-            The values for "maxptime", "ptime", and "minptime" of the payload\r
-            format configuration are recommendations by the decoding side to ensure \r
-            the best performance for the decoder. The decoder MUST be\r
-            capable to accept any allowed packet sizes to\r
-            ensure maximum compatibility.\r
-          </t>\r
-\r
-          <t>All other parameters of the payload format configuration are declarative\r
-          and a participant MUST use the configurations that are provided for\r
-          the session. More than one configuration may be provided if necessary\r
-          by declaring multiple RTP payload types; however, the number of types\r
-          should be kept small.</t>\r
-        </list></t>\r
-      </section>\r
-    </section>\r
-  </section>\r
-\r
-    <section title='Security Considerations' anchor='security-considerations'> \r
-      \r
-      <t>All RTP packets using the payload format defined in this specification\r
-      are subject to the general security considerations discussed in the RTP\r
-      specification <xref target="RFC3550"/> and any profile from\r
-      e.g. <xref target="RFC3711"/> or <xref target="RFC3551"/>.</t>\r
-\r
-      <t>This payload format transports Opus encoded speech or audio data,\r
-      hence, security issues include confidentiality, integrity protection, and\r
-      authentication of the speech or audio itself. The Opus payload format does\r
-      not have any built-in security mechanisms. Any suitable external\r
-      mechanisms, such as SRTP <xref target="RFC3711"/>, MAY be used.</t>\r
-\r
-      <t>This payload format and the Opus encoding do not exhibit any\r
-      significant non-uniformity in the receiver-end computational load and thus\r
-      are unlikely to pose a denial-of-service threat due to the receipt of\r
-      pathological datagrams.</t>\r
-    </section>\r
-    \r
-    <section title='Acknowledgements'>\r
-    <t>TBD</t>\r
-    </section>\r
-  </middle>\r
-\r
-  <back>\r
-    <references title="Normative References"> \r
-      &rfc2119;\r
-      &rfc3550;\r
-      &rfc3711;\r
-      &rfc3551;\r
-      &rfc4288;\r
-      &rfc4855;\r
-      &rfc4566;\r
-      &rfc3264;\r
-      &rfc2974;\r
-      &rfc2326;\r
-    </references>\r
-\r
-\r
-    <section title='Informational References'>\r
-      <t><list style="hanging">\r
-      <t>[codec]  http://datatracker.ietf.org/wg/codec/</t>\r
-      <t>[Opus]  http://datatracker.ietf.org/doc/draft-ietf-codec-opus/</t>\r
-      </list></t>\r
-    </section>\r
-\r
-    \r
-  </back>\r
-</rfc>\r
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
+<!ENTITY rfc3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
+<!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'>
+<!ENTITY rfc3551 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml'>
+<!ENTITY rfc4288 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'>
+<!ENTITY rfc4855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml'>
+<!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
+<!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
+<!ENTITY rfc2974 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml'>
+<!ENTITY rfc2326 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml'>
+<!ENTITY rfc3555 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3555.xml'>
+<!ENTITY rfc6562 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6562.xml'>
+
+  ]>
+
+  <rfc category="info" ipr="trust200902" docName="draft-spittka-payload-rtp-opus-01.txt">
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+
+<?rfc strict="yes" ?>
+<?rfc toc="yes" ?>
+<?rfc tocdepth="3" ?>
+<?rfc tocappendix='no' ?>
+<?rfc tocindent='yes' ?>
+<?rfc symrefs="yes" ?>
+<?rfc sortrefs="yes" ?>
+<?rfc compact="no" ?>
+<?rfc subcompact="yes" ?>
+<?rfc iprnotified="yes" ?>
+
+  <front>
+    <title abbrev="RTP Payload Format for Opus Codec">
+      RTP Payload Format for Opus Speech and Audio Codec
+    </title>
+
+    <author fullname="Julian Spittka" initials="J." surname="Spittka">
+      <organization>Skype Technologies S.A.</organization>
+      <address>
+        <postal>
+          <street>3210 Porter Drive</street>
+          <code>94304</code>
+          <city>Palo Alto</city>
+          <region>CA</region>
+          <country>USA</country>
+        </postal>
+        <email>julian.spittka@skype.net</email>
+      </address>
+    </author>
+
+    <author initials='K.' surname='Vos' fullname='Koen Vos'>
+      <organization>Skype Technologies S.A.</organization>
+      <address>
+        <postal>
+          <street>3210 Porter Drive</street>
+          <code>94304</code>
+          <city>Palo Alto</city>
+          <region>CA</region>
+          <country>USA</country>
+        </postal>
+        <email>koen.vos@skype.net</email>
+      </address>
+    </author>
+
+    <author initials="JM" surname="Valin" fullname="Jean-Marc Valin">
+      <organization>Mozilla</organization>
+      <address>
+        <postal>
+          <street>650 Castro Street</street>
+          <city>Mountain View</city>
+          <region>CA</region>
+          <code>94041</code>
+          <country>USA</country>
+        </postal>
+        <email>jmvalin@jmvalin.ca</email>
+      </address>
+    </author>
+
+    <date day='1' month='May' year='2012' />
+
+    <abstract>
+      <t>
+        This document defines the Real-time Transport Protocol (RTP) payload
+        format for packetization of Opus encoded
+        speech and audio data that is essential to integrate the codec in the
+        most compatible way. Further, media type registrations
+        are described for the RTP payload format.
+      </t>
+    </abstract>
+  </front>
+
+  <middle>
+    <section title='Introduction'>
+      <t>
+        The Opus codec is a speech and audio codec developed within the
+        IETF Internet Wideband Audio Codec working group [codec]. The codec
+        has a very low algorithmic delay and is
+        is highly scalable in terms of audio bandwidth, bitrate, and
+        complexity. Further, it provides different modes to efficiently encode speech signals
+        as well as music signals, thus, making it the codec of choice for
+        various applications using the Internet or similar networks.
+      </t>
+      <t>
+        This document defines the Real-time Transport Protocol (RTP)
+        <xref target="RFC3550"/> payload format for packetization
+        of Opus encoded speech and audio data that is essential to
+        integrate the Opus codec in the
+        most compatible way. Further, media type registrations are described for
+        the RTP payload format. More information on the Opus
+        codec can be obtained from the following IETF draft
+        [Opus].
+      </t>
+    </section>
+
+    <section title='Conventions, Definitions and Acronyms used in this document'>
+      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+      document are to be interpreted as described in <xref target="RFC2119"/>.</t>
+      <t>
+      <list style='hanging'>
+        <t hangText="CPU:"> Central Processing Unit</t>
+             <t hangText="IP:"> Internet Protocol</t>
+             <t hangText="PSTN:"> Public Switched Telephone Network</t>
+             <t hangText="samples:"> Speech or audio samples</t>
+             <t hangText="SDP:"> Session Description Protocol</t>
+      </list>
+      </t>
+      <section title='Audio Bandwidth'>
+       <t>
+         Throughout this document, we refer to the following definitions:
+       </t>
+          <texttable anchor='bandwidth_definitions'>
+           <ttcol align='center'>Abbreviation</ttcol>
+            <ttcol align='center'>Name</ttcol>
+            <ttcol align='center'>Bandwidth</ttcol>
+            <ttcol align='center'>Sampling</ttcol>
+            <c>nb</c>
+            <c>Narrowband</c>
+            <c>0 - 4000</c>
+            <c>8000</c>
+
+            <c>mb</c>
+            <c>Mediumband</c>
+            <c>0 - 6000</c>
+            <c>12000</c>
+
+            <c>wb</c>
+            <c>Wideband</c>
+            <c>0 - 8000</c>
+            <c>16000</c>
+
+            <c>swb</c>
+            <c>Super-wideband</c>
+            <c>0 - 12000</c>
+            <c>24000</c>
+
+            <c>fb</c>
+            <c>Fullband</c>
+            <c>0 - 20000</c>
+            <c>48000</c>
+
+            <postamble>
+              Audio bandwidth naming
+            </postamble>
+          </texttable>
+      </section>
+    </section>
+
+    <section title='Opus Codec'>
+      <t>
+        The Opus [Opus] speech and audio codec has been developed to encode speech
+        signals as well as audio signals. Two different modes, a voice mode
+        or an audio mode, may be chosen to allow the most efficient coding
+        dependent on the type of input signal, the sampling frequency of the
+        input signal, and the specific application.
+      </t>
+
+      <t>
+        The voice mode allows to efficiently encode voice signals at lower bit
+        rates while the audio mode is optimized for audio signals at medium and
+        higher bitrates.
+      </t>
+
+      <t>
+        The Opus speech and audio codec is highly scalable in terms of audio
+        bandwidth and bitrate and complexity. Further, Opus allows to
+        transmit stereo signals.
+      </t>
+
+      <section title='Network Bandwidth'>
+          <t>
+           Opus supports all bitrates from 6&nbsp;kb/s to 510&nbsp;kb/s.
+           The bitrate can be changed dynamically within that range.
+           All
+           other parameters being
+           equal, higher bitrate results in higher quality.
+         </t>
+         <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'>
+         <t>
+           For a frame size of
+           20&nbsp;ms, these
+           are the bitrate "sweet spots" for Opus in various configurations:
+
+          <list style="symbols">
+           <t>8-12 kb/s for NB speech,</t>
+           <t>16-20 kb/s for WB speech,</t>
+           <t>28-40 kb/s for FB speech,</t>
+           <t>48-64 kb/s for FB mono music, and</t>
+           <t>64-128 kb/s for FB stereo music.</t>
+         </list>
+       </t>
+      </section>
+        <section title='Variable versus Constant Bit Rate'  anchor='variable-vs-constant-bitrate'>
+          <t>
+           For the same average bitrate, variable bitrate (VBR) can achieve higher quality
+           than constant bitrate (CBR). For the majority of voice transmission application, VBR
+           is the best choice. One potential reason for choosing CBR is the potential
+           information leak that <spanx style='emph'>may</spanx> occur when encrypting the
+           compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is
+           appropriate for encrypted audio communications. In the case where an existing
+           VBR stream needs to be converted to CBR for security reasons, then the Opus padding
+           mechanism described in [Opus] is the RECOMMENDED way to achieve padding
+           because the RTP padding bit is unencrypted.</t>
+
+           <t>
+            The bitrate can be adjusted at any point in time. To avoid congestion,
+            the average bitrate SHOULD be adjusted to the available
+            network capacity. If no target bitrate is specified the average bitrate
+            may go up to the highest bitrate specified in
+            <xref target='bitrate_by_bandwidth'/>.
+          </t>
+
+        </section>
+
+        <section title='Discontinuous Transmission (DTX)'>
+
+          <t>
+            The Opus codec may, as described in <xref target='variable-vs-constant-bitrate'/>,
+            be operated with an adaptive bitrate. In that case, the bitrate
+            will automatically be reduced for certain input signals like periods
+            of silence. During continuous transmission the bitrate will be
+            reduced, when the input signal allows to do so, but the transmission
+            to the receiver itself will never be interrupted. Therefore, the
+            received signal will maintain the same high level of quality over the
+            full duration of a transmission while minimizing the average bit
+            rate over time.
+          </t>
+
+          <t>
+            In cases where the bitrate of Opus needs to be reduced even
+            further or in cases where only constant bitrate is available,
+            the Opus encoder may be set to use discontinuous
+            transmission (DTX), where parts of the encoded signal that
+            correspond to periods of silence in the input speech or audio signal
+            are not transmitted to the receiver.
+          </t>
+
+          <t>
+            On the receiving side, the non-transmitted parts will be handled by a
+            frame loss concealment unit in the Opus decoder which generates a
+            comfort noise signal to replace the non transmitted parts of the
+            speech or audio signal.
+          </t>
+
+          <t>
+            The DTX mode of Opus will have a slightly lower speech or audio
+            quality than the continuous mode. Therefore, it is RECOMMENDED to
+            use Opus in the continuous mode unless restraints on network
+            capacity are severe. The DTX mode can be engaged for operation
+            in both adaptive or constant bitrate.
+          </t>
+
+        </section>
+
+        </section>
+
+      <section title='Complexity'>
+
+        <t>
+          Complexity can be scaled to optimize for CPU resources in real-time, mostly as
+          a trade-off between audio quality and bitrate. Also, different modes of Opus have different complexity.
+        </t>
+
+      </section>
+
+      <section title="Forward Error Correction (FEC)">
+
+        <t>
+          The voice mode of Opus allows for "in-band" forward error correction (FEC)
+          data to be embedded into the bit stream of Opus. This FEC scheme adds
+          redundant information about the previous packet (n-1) to the current
+          output packet n. For
+          each frame, the encoder decides whether to use FEC based on (1) an
+          externally-provided estimate of the channel's packet loss rate; (2) an
+          externally-provided estimate of the channel's capacity; (3) the
+          sensitivity of the audio or speech signal to packet loss; (4) whether
+          the receiving decoder has indicated it can take advantage of "in-band"
+          FEC information. The decision to send "in-band" FEC information is
+          entirely controlled by the encoder and therefore no special precautions
+          for the payload have to be taken.
+        </t>
+
+        <t>
+          On the receiving side, the decoder can take advantage of this
+          additional information when, in case of a packet loss, the next packet
+          is available.  In order to use the FEC data, the jitter buffer needs
+          to provide access to payloads with the FEC data.  The decoder API function
+          has a flag to indicate that a FEC frame rather than a regular frame should
+          be decoded.  If no FEC data is available for the current frame, the decoder
+          will consider the frame lost and invokes the frame loss concealment.
+        </t>
+
+        <t>
+          If the FEC scheme is not implemented on the receiving side, FEC
+          SHOULD NOT be used, as it leads to an inefficient usage of network
+          resources. Decoder support for FEC SHOULD be indicated at the time a
+          session is set up.
+        </t>
+
+      </section>
+
+      <section title='Stereo Operation'>
+
+        <t>
+          Opus allows for transmission of stereo audio signals. This operation
+          is signaled in-band in the Opus payload and no special arrangement
+          is required in the payload format. Any implementation of the Opus
+          decoder MUST be capable of receiving stereo signals.
+        </t>
+        <t>
+          If a decoder can not take advantage of the benefits of a stereo signal
+          this SHOULD be indicated at the time a session is set up. In that case
+          the sending side SHOULD NOT send stereo signals as it leads to an
+          inefficient usage of the network.
+        </t>
+
+      </section>
+
+    </section>
+
+    <section title='Opus RTP Payload Format' anchor='opus-rtp-payload-format'>
+      <t>The payload format for Opus consists of the RTP header and Opus payload
+      data.</t>
+      <section title='RTP Header Usage'>
+        <t>The format of the RTP header is specified in <xref target="RFC3550"/>. The Opus
+        payload format uses the fields of the RTP header consistent with this
+        specification.</t>
+
+        <t>The payload length of Opus is a multiple number of octets and
+        therefore no padding is required. The payload MAY be padded by an
+        integer number of octets according to <xref target="RFC3550"/>.</t>
+
+        <t>The marker bit (M) of the RTP header has no function in combination
+        with Opus and MAY be ignored.</t>
+
+        <t>The RTP payload type for Opus has not been assigned statically and is
+        expected to be assigned dynamically.</t>
+
+        <t>The receiving side MUST be prepared to receive duplicates of RTP
+        packets. Only one of those payloads MUST be provided to the Opus decoder
+        for decoding and others MUST be discarded.</t>
+
+        <t>Opus supports 5 different audio bandwidths which may be adjusted during
+        the duration of a call. The RTP timestamp clock frequency is defined as
+        the highest supported sampling frequency of Opus, i.e. 48000 Hz, for all
+        modes and sampling rates of Opus. The unit
+        for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the
+        sample time of the first encoded sample in the encoded frame. For sampling
+        rates lower than 48000 Hz the number of samples has to be multiplied with
+        a multiplier according to <xref target="fs-upsample-factors"/> to determine
+        the RTP timestamp.</t>
+
+        <texttable anchor='fs-upsample-factors'>
+          <ttcol align='center'>fs (Hz)</ttcol>
+          <ttcol align='center'>Multiplier</ttcol>
+          <c>8000</c>
+          <c>6</c>
+          <c>12000</c>
+          <c>4</c>
+          <c>16000</c>
+          <c>3</c>
+          <c>24000</c>
+          <c>2</c>
+          <c>48000</c>
+          <c>1</c>
+          <postamble>
+            fs specifies the audio sampling frequency in Hertz (Hz); Multiplier is the
+            value that the number of samples have to be multiplied with to calculate
+            the RTP timestamp.
+          </postamble>
+        </texttable>
+      </section>
+
+      <section title='Payload Structure'>
+        <t>
+          The Opus encoder can be set to output encoded frames representing 2.5, 5, 10, 20,
+          40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be
+          combined into a packet. The maximum packet length is limited to the amount of encoded
+          data representing 120 ms of speech or audio data. The packetization of encoded data
+          is purely done by the Opus encoder and therefore only one packet output from the Opus
+          encoder MUST be used as a payload.
+        </t>
+
+        <t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t>
+
+        <figure anchor="payload-structure"
+                title="Payload Structure with RTP header">
+          <artwork>
+            <![CDATA[
++----------+--------------+
+|RTP Header| Opus Payload |
++----------+--------------+
+           ]]>
+          </artwork>
+        </figure>
+
+        <t>
+          <xref target='opus-packetization'/> shows supported frame sizes for different modes
+          and sampling rates of Opus and how the timestamp needs to be incremented for
+          packetization.
+        </t>
+
+        <texttable anchor='opus-packetization'>
+            <ttcol align='center'>Mode</ttcol>
+            <ttcol align='center'>fs</ttcol>
+            <ttcol align='center'>2.5</ttcol>
+            <ttcol align='center'>5</ttcol>
+            <ttcol align='center'>10</ttcol>
+            <ttcol align='center'>20</ttcol>
+            <ttcol align='center'>40</ttcol>
+            <ttcol align='center'>60</ttcol>
+            <c>ts incr</c>
+            <c>all</c>
+            <c>120</c>
+            <c>240</c>
+            <c>480</c>
+            <c>960</c>
+            <c>1920</c>
+            <c>2880</c>
+            <c>voice</c>
+            <c>nb/mb/wb/swb/fb</c>
+            <c></c>
+            <c></c>
+            <c>x</c>
+            <c>x</c>
+            <c>x</c>
+            <c>x</c>
+            <c>audio</c>
+            <c>nb/wb/swb/fb</c>
+            <c>x</c>
+            <c>x</c>
+            <c>x</c>
+            <c>x</c>
+            <c></c>
+            <c></c>
+            <postamble>
+              Mode specifies the Opus mode of operation; fs specifies the audio sampling
+              frequency in Hertz (Hz); 2.5, 5, 10, 20, 40, and 60 represent the duration of
+              encoded speech or audio data in a packet; ts incr specifies the
+              value the timestamp needs to be incremented for the representing packet size.
+              For multiple frames in a packet these values have to be multiplied with the
+              respective number of frames.
+            </postamble>
+          </texttable>
+
+      </section>
+
+    </section>
+
+    <section title='Congestion Control'>
+
+      <t>The adaptive nature of the Opus codec allows for an efficient
+      congestion control.</t>
+
+      <t>The target bitrate of Opus can be adjusted at any point in time and
+      thus allowing for an efficient congestion control. Furthermore, the amount
+      of encoded speech or audio data encoded in a
+      single packet can be used for congestion control since the transmission
+      rate is inversely proportional to these frame sizes. A lower packet
+      transmission rate reduces the amount of header overhead but at the same
+      time increases latency and error sensitivity and should be done with care.</t>
+
+      <t>It is RECOMMENDED that congestion control is applied during the
+      transmission of Opus encoded data.</t>
+    </section>
+
+    <section title='IANA Considerations'>
+      <t>One media subtype (audio/opus) has been defined and registered as
+      described in the following section.</t>
+
+      <section title='Opus Media Type Registration'>
+        <t>Media type registration is done according to <xref
+        target="RFC4288"/> and <xref target="RFC4855"/>.<vspace
+        blankLines='1'/></t>
+
+          <t>Type name: audio<vspace blankLines='1'/></t>
+          <t>Subtype name: opus<vspace blankLines='1'/></t>
+
+          <t>Required parameters:</t>
+          <t><list style="hanging">
+            <t hangText="rate:"> RTP timestamp clock rate is incremented with
+            48000 Hz clock rate for all modes of Opus and all sampling
+            frequencies. For audio sampling rates other than 48000 Hz the rate
+            has to be adjusted to 48000 Hz according to <xref target="fs-upsample-factors"/>.
+          </t>
+          </list></t>
+
+          <t>Optional parameters:</t>
+
+          <t><list style="hanging">
+            <t hangText="maxcodedaudiobandwidth:">
+              a hint about the maximum audio bandwidth that the receiver is capable of rendering.
+             The decoder MUST be capable of decoding
+              any audio bandwidth but due to hardware limitations only signals
+              up to the specified audio bandwidth can be processed. Sending signals
+              with higher audio bandwidth results in higher than necessary network
+              usage and encoding complexity, so an encoder SHOULD NOT encode
+             frequencies above the audio bandwidth specified by maxcodedaudiobandwidth.
+             Possible values are nb, mb, wb, swb, fb. By default, the receiver
+             is assumed to have no limitations, i.e. fb.
+              <vspace blankLines='1'/>
+            </t>
+
+            <t hangText="maxptime:"> the decoder's maximum length of time in
+            milliseconds rounded up to the next full integer value represented
+            by the media in a packet that can be
+            encapsulated in a received packet according to Section 6 of
+            <xref target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40,
+            and 60 or an arbitrary multiple of Opus frame sizes rounded up to
+            the next full integer value up to a maximum value of 120 as
+            defined in <xref target='opus-rtp-payload-format'/>. If no value is
+              specified, 120 is assumed as default. This value is a recommendation
+              by the decoding side to ensure the best
+              performance for the decoder. The decoder MUST be
+              capable of accepting any allowed packet sizes to
+              ensure maximum compatibility.
+              <vspace blankLines='1'/></t>
+
+            <t hangText="ptime:"> the decoder's recommended length of time in
+            milliseconds rounded up to the next full integer value represented
+            by the media in a packet according to
+            Section 6 of <xref target="RFC4566"/>. Possible values are
+            3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes
+            rounded up to the next full integer value up to a maximum
+            value of 120 as defined in <xref
+            target='opus-rtp-payload-format'/>. If no value is
+              specified, 20 is assumed as default. If ptime is greater than
+              maxptime, ptime MUST be ignored. This parameter MAY be changed
+              during a session. This value is a recommendation by the decoding
+              side to ensure the best
+              performance for the decoder. The decoder MUST be
+              capable of accepting any allowed packet sizes to
+              ensure maximum compatibility.
+              <vspace blankLines='1'/></t>
+
+            <t hangText="minptime:"> the decoder's minimum length of time in
+            milliseconds rounded up to the next full integer value represented
+            by the media in a packet that SHOULD
+            be encapsulated in a received packet according to Section 6 of <xref
+            target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, and 60
+            or an arbitrary multiple of Opus frame sizes rounded up to the next
+            full integer value up to a maximum value of 120
+            as defined in <xref target='opus-rtp-payload-format'/>. If no value is
+              specified, 3 is assumed as default. This value is a recommendation
+              by the decoding side to ensure the best
+              performance for the decoder. The decoder MUST be
+              capable to accept any allowed packet sizes to
+              ensure maximum compatibility.
+              <vspace blankLines='1'/></t>
+
+            <t hangText="maxaveragebitrate:"> specifies the maximum average
+           receive bitrate of a session in bits per second (b/s). The actual
+            value of the bitrate may vary as it is dependent on the
+            characteristics of the media in a packet. Note that the maximum
+            average bitrate MAY be modified dynamically during a session. Any
+            positive integer is allowed but values outside the range between
+            6000 and 510000 SHOULD be ignored. If no value is specified, the
+            maximum value specified in <xref target='bitrate_by_bandwidth'/>
+            for the corresponding mode of Opus and corresponding maxcodedaudiobandwidth:
+            will be the default.<vspace blankLines='1'/></t>
+
+            <t hangText="stereo:">
+              specifies whether the decoder prefers receiving stereo or mono signals.
+              Possible values are 1 and 0 where 1 specifies that stereo signals are preferred
+              and 0 specifies that only mono signals are preferred.
+              Independent of the stereo parameter every receiver MUST be able to receive and
+              decode stereo signals but sending stereo signals to a receiver that signaled a
+              preference for mono signals may result in higher than necessary network
+              utilisation and encoding complexity. If no value is specified, mono
+              is assumed (stereo=0).<vspace blankLines='1'/>
+            </t>
+
+            <t hangText="cbr:">
+              specifies if the decoder prefers the use of a constant bitrate versus
+              variable bitrate. Possible values are 1 and 0 where 1 specifies constant
+              bitrate and 0 specifies variable bitrate. If no value is specified, cbr
+              is assumed to be 0. Note that the maximum average bitrate may still be
+              changed, e.g. to adapt to changing network conditions.<vspace blankLines='1'/>
+            </t>
+
+            <t hangText="useinbandfec:"> specifies that Opus in-band FEC is
+            supported by the decoder and MAY be used during a
+            session. Possible values are 1 and 0. It is RECOMMENDED to provide
+            0 in case FEC is not implemented on the receiving side. If no
+            value is specified, useinbandfec is assumed to be 1.<vspace blankLines='1'/></t>
+
+            <t hangText="usedtx:"> specifies if the decoder prefers the use of
+            DTX. Possible values are 1 and 0. If no value is specified, usedtx
+            is assumed to be 0.<vspace blankLines='1'/></t>
+          </list></t>
+
+          <t>Encoding considerations:<vspace blankLines='1'/></t>
+          <t><list style="hanging">
+            <t>Opus media type is framed and consists of binary data according
+            to Section 4.8 in <xref target="RFC4288"/>.</t>
+          </list></t>
+
+          <t>Security considerations: </t>
+          <t><list style="hanging">
+            <t>See <xref target='security-considerations'/> of this document.</t>
+          </list></t>
+
+          <t>Interoperability considerations: none<vspace blankLines='1'/></t>
+          <t>Published specification: none<vspace blankLines='1'/></t>
+
+          <t>Applications that use this media type: </t>
+          <t><list style="hanging">
+            <t>Any application that requires the transport of
+            speech or audio data may use this media type. Some examples are,
+            but not limited to, audio and video conferencing, Voice over IP,
+            media streaming.</t>
+          </list></t>
+
+          <t>Person & email address to contact for further information:</t>
+          <t><list style="hanging">
+            <t>SILK Support silksupport@skype.net</t>
+            <t>Jean-Marc Valin jmvalin@jmvalin.ca</t>
+          </list></t>
+
+          <t>Intended usage: COMMON<vspace blankLines='1'/></t>
+
+          <t>Restrictions on usage:<vspace blankLines='1'/></t>
+
+          <t><list style="hanging">
+            <t>For transfer over RTP, the RTP payload format (<xref
+            target='opus-rtp-payload-format'/> of this document) SHALL be
+            used.</t>
+          </list></t>
+
+          <t>Author:</t>
+          <t><list style="hanging">
+            <t>Julian Spittka julian.spittka@skype.net<vspace blankLines='1'/></t>
+            <t>Koen Vos koen.vos@skype.net<vspace blankLines='1'/></t>
+            <t>Jean-Marc Valin jmvalin@jmvalin.ca<vspace blankLines='1'/></t>
+          </list></t>
+
+          <t> Change controller: TBD</t>
+      </section>
+
+      <section title='Mapping to SDP Parameters'>
+        <t>The information described in the media type specification has a
+        specific mapping to fields in the Session Description Protocol (SDP)
+        <xref target="RFC4566"/>, which is commonly used to describe RTP
+        sessions. When SDP is used to specify sessions employing the Opus codec,
+        the mapping is as follows:</t>
+
+        <t>
+          <list style="symbols">
+            <t>The media type ("audio") goes in SDP "m=" as the media name.</t>
+
+            <t>The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding
+            name. The RTP clock rate in "a=rtpmap" MUST be mapped to the required
+            media type parameter "rate".</t>
+
+            <t>The optional media type parameters "ptime" and "maxptime" are
+            mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the
+            SDP.</t>
+
+            <t>All remaining media type parameters are mapped to the "a=fmtp"
+            attribute in the SDP by copying them directly from the media type
+            parameter string as a semicolon-separated list of parameter=value
+            pairs (e.g. maxaveragebitrate=20000).</t>
+          </list>
+        </t>
+
+        <t>Below are some examples of SDP session descriptions for Opus:</t>
+
+        <t>Example 1: Standard session with 48000 Hz clock rate</t>
+          <figure>
+            <artwork>
+              <![CDATA[
+    m=audio 54312 RTP/AVP 101
+    a=rtpmap:101 opus/48000
+              ]]>
+            </artwork>
+          </figure>
+
+
+        <t>Example 2: 16000 Hz clock rate, maximum packet size of 40 ms,
+        recommended packet size of 40 ms, maximum average bitrate of 20000 bps,
+        stereo signals are preferred, FEC is allowed, DTX is not allowed</t>
+
+        <figure>
+          <artwork>
+            <![CDATA[
+    m=audio 54312 RTP/AVP 101
+    a=rtpmap:101 opus/48000
+    a=fmtp:101 maxcodedaudiobandwidth=wb; maxaveragebitrate=20000;
+    stereo=1; useinbandfec=1; usedtx=0
+    a=ptime:40
+    a=maxptime:40
+            ]]>
+          </artwork>
+        </figure>
+
+      <section title='Offer-Answer Model Considerations for Opus'>
+
+          <t>When using the offer-answer procedure described in <xref
+          target="RFC3264"/> to negotiate the use of Opus, the following
+          considerations apply:</t>
+
+          <t><list style="symbols">
+
+            <t>Opus supports several clock rates. For signaling purposes only
+            the highest, i.e. 48000, is used. The actual clock rate of the
+            corresponding media is signaled inside the payload and is not
+            subject to this payload format description. The decoder MUST be
+            capable to decode every received clock rate. An example
+            is shown below:
+
+            <figure>
+              <artwork>
+                <![CDATA[
+        m=audio 54312 RTP/AVP 100
+        a=rtpmap:100 opus/48000
+                ]]>
+              </artwork>
+            </figure>
+            </t>
+
+            <t>The parameters "ptime" and "maxptime" are unidirectional
+            receive-only parameters and typically will not compromise
+            interoperability; however, dependent on the set values of the
+            parameters the performance of the application may suffer.  <xref
+            target="RFC3264"/> defines the SDP offer-answer handling of the
+            "ptime" parameter. The "maxptime" parameter MUST be handled in the
+            same way.</t>
+
+            <t>
+              The parameter "minptime" is a unidirectional
+              receive-only parameters and typically will not compromise
+              interoperability; however, dependent on the set values of the
+              parameter the performance of the application may suffer and should be
+              set with care.
+            </t>
+
+            <t>
+              The parameter "maxcodedaudiobandwidth" is a unidirectional receive-only
+              parameter that reflects limitations of the local receiver. The sender
+              of the other side SHOULD NOT send with an audio bandwidth higher than
+              "maxcodedaudiobandwidth" as this would lead to inefficient use of network resources. The "maxcodedaudiobandwidth" parameter does not
+             affect interoperability. Also, this parameter SHOULD NOT be used
+             to adjust the audio bandwidth as a function of the bitrates, as this
+             is the responsability of the Opus encoder implementation.
+            </t>
+
+            <t>The parameter "maxaveragebitrate" is a unidirectional receive-only
+            parameter that reflects limitations of the local receiver. The sender
+            of the other side MUST NOT send with an average bitrate higher than
+            "maxaveragebitrate" as it might overload the network and/or
+            receiver. The parameter "maxaveragebitrate" typically will not
+            compromise interoperability; however, dependent on the set value of
+            the parameter the performance of the application may suffer and should
+            be set with care.</t>
+
+            <t>If the parameter "maxaveragebitrate" is below the range specified
+            in <xref target='bitrate_by_bandwidth'/> the session MUST be rejected.</t>
+
+            <t>
+              The parameter "stereo" is a unidirectional receive-only
+              parameter.
+            </t>
+
+            <t>
+              The parameter "cbr" is a unidirectional receive-only
+              parameter.
+            </t>
+
+            <t>The parameter "useinbandfec" is a unidirectional receive-only
+            parameter.</t>
+
+            <t>The parameter "usedtx" is a unidirectional receive-only
+            parameter.</t>
+
+            <t>Any unknown parameter in an offer MUST be ignored by the receiver
+            and MUST be removed from the answer.</t>
+
+          </list></t>
+      </section>
+
+      <section title='Declarative SDP Considerations for Opus'>
+
+        <t>For declarative use of SDP such as in Session Announcement Protocol
+        (SAP), <xref target="RFC2974"/>, and RTSP, <xref target="RFC2326"/>, for
+        Opus, the following needs to be considered:</t>
+
+        <t><list style="symbols">
+
+          <t>The values for "maxptime", "ptime", "minptime", "maxcodedaudiobandwidth", and
+          "maxaveragebitrate" should be selected carefully to ensure that a
+          reasonable performance can be achieved for the participants of a session.</t>
+
+          <t>
+            The values for "maxptime", "ptime", and "minptime" of the payload
+            format configuration are recommendations by the decoding side to ensure
+            the best performance for the decoder. The decoder MUST be
+            capable to accept any allowed packet sizes to
+            ensure maximum compatibility.
+          </t>
+
+          <t>All other parameters of the payload format configuration are declarative
+          and a participant MUST use the configurations that are provided for
+          the session. More than one configuration may be provided if necessary
+          by declaring multiple RTP payload types; however, the number of types
+          should be kept small.</t>
+        </list></t>
+      </section>
+    </section>
+  </section>
+
+    <section title='Security Considerations' anchor='security-considerations'>
+
+      <t>All RTP packets using the payload format defined in this specification
+      are subject to the general security considerations discussed in the RTP
+      specification <xref target="RFC3550"/> and any profile from
+      e.g. <xref target="RFC3711"/> or <xref target="RFC3551"/>.</t>
+
+      <t>This payload format transports Opus encoded speech or audio data,
+      hence, security issues include confidentiality, integrity protection, and
+      authentication of the speech or audio itself. The Opus payload format does
+      not have any built-in security mechanisms. Any suitable external
+      mechanisms, such as SRTP <xref target="RFC3711"/>, MAY be used.</t>
+
+      <t>This payload format and the Opus encoding do not exhibit any
+      significant non-uniformity in the receiver-end computational load and thus
+      are unlikely to pose a denial-of-service threat due to the receipt of
+      pathological datagrams.</t>
+    </section>
+
+    <section title='Acknowledgements'>
+    <t>TBD</t>
+    </section>
+  </middle>
+
+  <back>
+    <references title="Normative References">
+      &rfc2119;
+      &rfc3550;
+      &rfc3711;
+      &rfc3551;
+      &rfc4288;
+      &rfc4855;
+      &rfc4566;
+      &rfc3264;
+      &rfc2974;
+      &rfc2326;
+    </references>
+
+
+    <section title='Informational References'>
+      <t><list style="hanging">
+      <t>[codec]  http://datatracker.ietf.org/wg/codec/</t>
+      <t>[Opus]  http://datatracker.ietf.org/doc/draft-ietf-codec-opus/</t>
+      </list></t>
+    </section>
+
+  </back>
+</rfc>