Adds a copy of the RTP payload XML
authorJean-Marc Valin <jmvalin@jmvalin.ca>
Thu, 14 Jun 2012 14:56:12 +0000 (10:56 -0400)
committerJean-Marc Valin <jmvalin@jmvalin.ca>
Thu, 14 Jun 2012 14:56:12 +0000 (10:56 -0400)
doc/draft-spittka-payload-rtp-opus.xml [new file with mode: 0644]

diff --git a/doc/draft-spittka-payload-rtp-opus.xml b/doc/draft-spittka-payload-rtp-opus.xml
new file mode 100644 (file)
index 0000000..339d786
--- /dev/null
@@ -0,0 +1,880 @@
+<?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