Gregory Maxwell | 0c90607 | 2012-06-19 09:11:40 -0400 | [diff] [blame] | 1 | <?xml version="1.0" encoding="UTF-8"?> |
| 2 | <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ |
| 3 | <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> |
| 4 | <!ENTITY rfc3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'> |
| 5 | <!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'> |
| 6 | <!ENTITY rfc3551 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml'> |
| 7 | <!ENTITY rfc4288 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'> |
| 8 | <!ENTITY rfc4855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml'> |
| 9 | <!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'> |
| 10 | <!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'> |
| 11 | <!ENTITY rfc2974 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml'> |
| 12 | <!ENTITY rfc2326 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml'> |
| 13 | <!ENTITY rfc3555 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3555.xml'> |
| 14 | <!ENTITY rfc6562 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6562.xml'> |
| 15 | |
| 16 | ]> |
| 17 | |
| 18 | <rfc category="info" ipr="trust200902" docName="draft-spittka-payload-rtp-opus-01.txt"> |
| 19 | <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> |
| 20 | |
| 21 | <?rfc strict="yes" ?> |
| 22 | <?rfc toc="yes" ?> |
| 23 | <?rfc tocdepth="3" ?> |
| 24 | <?rfc tocappendix='no' ?> |
| 25 | <?rfc tocindent='yes' ?> |
| 26 | <?rfc symrefs="yes" ?> |
| 27 | <?rfc sortrefs="yes" ?> |
| 28 | <?rfc compact="no" ?> |
| 29 | <?rfc subcompact="yes" ?> |
| 30 | <?rfc iprnotified="yes" ?> |
| 31 | |
| 32 | <front> |
| 33 | <title abbrev="RTP Payload Format for Opus Codec"> |
| 34 | RTP Payload Format for Opus Speech and Audio Codec |
| 35 | </title> |
| 36 | |
| 37 | <author fullname="Julian Spittka" initials="J." surname="Spittka"> |
| 38 | <organization>Skype Technologies S.A.</organization> |
| 39 | <address> |
| 40 | <postal> |
| 41 | <street>3210 Porter Drive</street> |
| 42 | <code>94304</code> |
| 43 | <city>Palo Alto</city> |
| 44 | <region>CA</region> |
| 45 | <country>USA</country> |
| 46 | </postal> |
| 47 | <email>julian.spittka@skype.net</email> |
| 48 | </address> |
| 49 | </author> |
| 50 | |
| 51 | <author initials='K.' surname='Vos' fullname='Koen Vos'> |
| 52 | <organization>Skype Technologies S.A.</organization> |
| 53 | <address> |
| 54 | <postal> |
| 55 | <street>3210 Porter Drive</street> |
| 56 | <code>94304</code> |
| 57 | <city>Palo Alto</city> |
| 58 | <region>CA</region> |
| 59 | <country>USA</country> |
| 60 | </postal> |
| 61 | <email>koen.vos@skype.net</email> |
| 62 | </address> |
| 63 | </author> |
| 64 | |
| 65 | <author initials="JM" surname="Valin" fullname="Jean-Marc Valin"> |
| 66 | <organization>Mozilla</organization> |
| 67 | <address> |
| 68 | <postal> |
| 69 | <street>650 Castro Street</street> |
| 70 | <city>Mountain View</city> |
| 71 | <region>CA</region> |
| 72 | <code>94041</code> |
| 73 | <country>USA</country> |
| 74 | </postal> |
| 75 | <email>jmvalin@jmvalin.ca</email> |
| 76 | </address> |
| 77 | </author> |
| 78 | |
| 79 | <date day='1' month='May' year='2012' /> |
| 80 | |
| 81 | <abstract> |
| 82 | <t> |
| 83 | This document defines the Real-time Transport Protocol (RTP) payload |
| 84 | format for packetization of Opus encoded |
| 85 | speech and audio data that is essential to integrate the codec in the |
| 86 | most compatible way. Further, media type registrations |
| 87 | are described for the RTP payload format. |
| 88 | </t> |
| 89 | </abstract> |
| 90 | </front> |
| 91 | |
| 92 | <middle> |
| 93 | <section title='Introduction'> |
| 94 | <t> |
| 95 | The Opus codec is a speech and audio codec developed within the |
| 96 | IETF Internet Wideband Audio Codec working group [codec]. The codec |
| 97 | has a very low algorithmic delay and is |
| 98 | is highly scalable in terms of audio bandwidth, bitrate, and |
| 99 | complexity. Further, it provides different modes to efficiently encode speech signals |
| 100 | as well as music signals, thus, making it the codec of choice for |
| 101 | various applications using the Internet or similar networks. |
| 102 | </t> |
| 103 | <t> |
| 104 | This document defines the Real-time Transport Protocol (RTP) |
| 105 | <xref target="RFC3550"/> payload format for packetization |
| 106 | of Opus encoded speech and audio data that is essential to |
| 107 | integrate the Opus codec in the |
| 108 | most compatible way. Further, media type registrations are described for |
| 109 | the RTP payload format. More information on the Opus |
| 110 | codec can be obtained from the following IETF draft |
| 111 | [Opus]. |
| 112 | </t> |
| 113 | </section> |
| 114 | |
| 115 | <section title='Conventions, Definitions and Acronyms used in this document'> |
| 116 | <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 117 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 118 | document are to be interpreted as described in <xref target="RFC2119"/>.</t> |
| 119 | <t> |
| 120 | <list style='hanging'> |
| 121 | <t hangText="CPU:"> Central Processing Unit</t> |
| 122 | <t hangText="IP:"> Internet Protocol</t> |
| 123 | <t hangText="PSTN:"> Public Switched Telephone Network</t> |
| 124 | <t hangText="samples:"> Speech or audio samples</t> |
| 125 | <t hangText="SDP:"> Session Description Protocol</t> |
| 126 | </list> |
| 127 | </t> |
| 128 | <section title='Audio Bandwidth'> |
| 129 | <t> |
| 130 | Throughout this document, we refer to the following definitions: |
| 131 | </t> |
| 132 | <texttable anchor='bandwidth_definitions'> |
| 133 | <ttcol align='center'>Abbreviation</ttcol> |
| 134 | <ttcol align='center'>Name</ttcol> |
| 135 | <ttcol align='center'>Bandwidth</ttcol> |
| 136 | <ttcol align='center'>Sampling</ttcol> |
| 137 | <c>nb</c> |
| 138 | <c>Narrowband</c> |
| 139 | <c>0 - 4000</c> |
| 140 | <c>8000</c> |
| 141 | |
| 142 | <c>mb</c> |
| 143 | <c>Mediumband</c> |
| 144 | <c>0 - 6000</c> |
| 145 | <c>12000</c> |
| 146 | |
| 147 | <c>wb</c> |
| 148 | <c>Wideband</c> |
| 149 | <c>0 - 8000</c> |
| 150 | <c>16000</c> |
| 151 | |
| 152 | <c>swb</c> |
| 153 | <c>Super-wideband</c> |
| 154 | <c>0 - 12000</c> |
| 155 | <c>24000</c> |
| 156 | |
| 157 | <c>fb</c> |
| 158 | <c>Fullband</c> |
| 159 | <c>0 - 20000</c> |
| 160 | <c>48000</c> |
| 161 | |
| 162 | <postamble> |
| 163 | Audio bandwidth naming |
| 164 | </postamble> |
| 165 | </texttable> |
| 166 | </section> |
| 167 | </section> |
| 168 | |
| 169 | <section title='Opus Codec'> |
| 170 | <t> |
| 171 | The Opus [Opus] speech and audio codec has been developed to encode speech |
| 172 | signals as well as audio signals. Two different modes, a voice mode |
| 173 | or an audio mode, may be chosen to allow the most efficient coding |
| 174 | dependent on the type of input signal, the sampling frequency of the |
| 175 | input signal, and the specific application. |
| 176 | </t> |
| 177 | |
| 178 | <t> |
| 179 | The voice mode allows to efficiently encode voice signals at lower bit |
| 180 | rates while the audio mode is optimized for audio signals at medium and |
| 181 | higher bitrates. |
| 182 | </t> |
| 183 | |
| 184 | <t> |
| 185 | The Opus speech and audio codec is highly scalable in terms of audio |
| 186 | bandwidth and bitrate and complexity. Further, Opus allows to |
| 187 | transmit stereo signals. |
| 188 | </t> |
| 189 | |
| 190 | <section title='Network Bandwidth'> |
| 191 | <t> |
| 192 | Opus supports all bitrates from 6 kb/s to 510 kb/s. |
| 193 | The bitrate can be changed dynamically within that range. |
| 194 | All |
| 195 | other parameters being |
| 196 | equal, higher bitrate results in higher quality. |
| 197 | </t> |
| 198 | <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'> |
| 199 | <t> |
| 200 | For a frame size of |
| 201 | 20 ms, these |
| 202 | are the bitrate "sweet spots" for Opus in various configurations: |
| 203 | |
| 204 | <list style="symbols"> |
| 205 | <t>8-12 kb/s for NB speech,</t> |
| 206 | <t>16-20 kb/s for WB speech,</t> |
| 207 | <t>28-40 kb/s for FB speech,</t> |
| 208 | <t>48-64 kb/s for FB mono music, and</t> |
| 209 | <t>64-128 kb/s for FB stereo music.</t> |
| 210 | </list> |
| 211 | </t> |
| 212 | </section> |
| 213 | <section title='Variable versus Constant Bit Rate' anchor='variable-vs-constant-bitrate'> |
| 214 | <t> |
| 215 | For the same average bitrate, variable bitrate (VBR) can achieve higher quality |
| 216 | than constant bitrate (CBR). For the majority of voice transmission application, VBR |
| 217 | is the best choice. One potential reason for choosing CBR is the potential |
| 218 | information leak that <spanx style='emph'>may</spanx> occur when encrypting the |
| 219 | compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is |
| 220 | appropriate for encrypted audio communications. In the case where an existing |
| 221 | VBR stream needs to be converted to CBR for security reasons, then the Opus padding |
| 222 | mechanism described in [Opus] is the RECOMMENDED way to achieve padding |
| 223 | because the RTP padding bit is unencrypted.</t> |
| 224 | |
| 225 | <t> |
| 226 | The bitrate can be adjusted at any point in time. To avoid congestion, |
| 227 | the average bitrate SHOULD be adjusted to the available |
| 228 | network capacity. If no target bitrate is specified the average bitrate |
| 229 | may go up to the highest bitrate specified in |
| 230 | <xref target='bitrate_by_bandwidth'/>. |
| 231 | </t> |
| 232 | |
| 233 | </section> |
| 234 | |
| 235 | <section title='Discontinuous Transmission (DTX)'> |
| 236 | |
| 237 | <t> |
| 238 | The Opus codec may, as described in <xref target='variable-vs-constant-bitrate'/>, |
| 239 | be operated with an adaptive bitrate. In that case, the bitrate |
| 240 | will automatically be reduced for certain input signals like periods |
| 241 | of silence. During continuous transmission the bitrate will be |
| 242 | reduced, when the input signal allows to do so, but the transmission |
| 243 | to the receiver itself will never be interrupted. Therefore, the |
| 244 | received signal will maintain the same high level of quality over the |
| 245 | full duration of a transmission while minimizing the average bit |
| 246 | rate over time. |
| 247 | </t> |
| 248 | |
| 249 | <t> |
| 250 | In cases where the bitrate of Opus needs to be reduced even |
| 251 | further or in cases where only constant bitrate is available, |
| 252 | the Opus encoder may be set to use discontinuous |
| 253 | transmission (DTX), where parts of the encoded signal that |
| 254 | correspond to periods of silence in the input speech or audio signal |
| 255 | are not transmitted to the receiver. |
| 256 | </t> |
| 257 | |
| 258 | <t> |
| 259 | On the receiving side, the non-transmitted parts will be handled by a |
| 260 | frame loss concealment unit in the Opus decoder which generates a |
| 261 | comfort noise signal to replace the non transmitted parts of the |
| 262 | speech or audio signal. |
| 263 | </t> |
| 264 | |
| 265 | <t> |
| 266 | The DTX mode of Opus will have a slightly lower speech or audio |
| 267 | quality than the continuous mode. Therefore, it is RECOMMENDED to |
| 268 | use Opus in the continuous mode unless restraints on network |
| 269 | capacity are severe. The DTX mode can be engaged for operation |
| 270 | in both adaptive or constant bitrate. |
| 271 | </t> |
| 272 | |
| 273 | </section> |
| 274 | |
| 275 | </section> |
| 276 | |
| 277 | <section title='Complexity'> |
| 278 | |
| 279 | <t> |
| 280 | Complexity can be scaled to optimize for CPU resources in real-time, mostly as |
| 281 | a trade-off between audio quality and bitrate. Also, different modes of Opus have different complexity. |
| 282 | </t> |
| 283 | |
| 284 | </section> |
| 285 | |
| 286 | <section title="Forward Error Correction (FEC)"> |
| 287 | |
| 288 | <t> |
| 289 | The voice mode of Opus allows for "in-band" forward error correction (FEC) |
| 290 | data to be embedded into the bit stream of Opus. This FEC scheme adds |
| 291 | redundant information about the previous packet (n-1) to the current |
| 292 | output packet n. For |
| 293 | each frame, the encoder decides whether to use FEC based on (1) an |
| 294 | externally-provided estimate of the channel's packet loss rate; (2) an |
| 295 | externally-provided estimate of the channel's capacity; (3) the |
| 296 | sensitivity of the audio or speech signal to packet loss; (4) whether |
| 297 | the receiving decoder has indicated it can take advantage of "in-band" |
| 298 | FEC information. The decision to send "in-band" FEC information is |
| 299 | entirely controlled by the encoder and therefore no special precautions |
| 300 | for the payload have to be taken. |
| 301 | </t> |
| 302 | |
| 303 | <t> |
| 304 | On the receiving side, the decoder can take advantage of this |
| 305 | additional information when, in case of a packet loss, the next packet |
| 306 | is available. In order to use the FEC data, the jitter buffer needs |
| 307 | to provide access to payloads with the FEC data. The decoder API function |
| 308 | has a flag to indicate that a FEC frame rather than a regular frame should |
| 309 | be decoded. If no FEC data is available for the current frame, the decoder |
| 310 | will consider the frame lost and invokes the frame loss concealment. |
| 311 | </t> |
| 312 | |
| 313 | <t> |
| 314 | If the FEC scheme is not implemented on the receiving side, FEC |
| 315 | SHOULD NOT be used, as it leads to an inefficient usage of network |
| 316 | resources. Decoder support for FEC SHOULD be indicated at the time a |
| 317 | session is set up. |
| 318 | </t> |
| 319 | |
| 320 | </section> |
| 321 | |
| 322 | <section title='Stereo Operation'> |
| 323 | |
| 324 | <t> |
| 325 | Opus allows for transmission of stereo audio signals. This operation |
| 326 | is signaled in-band in the Opus payload and no special arrangement |
| 327 | is required in the payload format. Any implementation of the Opus |
| 328 | decoder MUST be capable of receiving stereo signals. |
| 329 | </t> |
| 330 | <t> |
| 331 | If a decoder can not take advantage of the benefits of a stereo signal |
| 332 | this SHOULD be indicated at the time a session is set up. In that case |
| 333 | the sending side SHOULD NOT send stereo signals as it leads to an |
| 334 | inefficient usage of the network. |
| 335 | </t> |
| 336 | |
| 337 | </section> |
| 338 | |
| 339 | </section> |
| 340 | |
| 341 | <section title='Opus RTP Payload Format' anchor='opus-rtp-payload-format'> |
| 342 | <t>The payload format for Opus consists of the RTP header and Opus payload |
| 343 | data.</t> |
| 344 | <section title='RTP Header Usage'> |
| 345 | <t>The format of the RTP header is specified in <xref target="RFC3550"/>. The Opus |
| 346 | payload format uses the fields of the RTP header consistent with this |
| 347 | specification.</t> |
| 348 | |
| 349 | <t>The payload length of Opus is a multiple number of octets and |
| 350 | therefore no padding is required. The payload MAY be padded by an |
| 351 | integer number of octets according to <xref target="RFC3550"/>.</t> |
| 352 | |
| 353 | <t>The marker bit (M) of the RTP header has no function in combination |
| 354 | with Opus and MAY be ignored.</t> |
| 355 | |
| 356 | <t>The RTP payload type for Opus has not been assigned statically and is |
| 357 | expected to be assigned dynamically.</t> |
| 358 | |
| 359 | <t>The receiving side MUST be prepared to receive duplicates of RTP |
| 360 | packets. Only one of those payloads MUST be provided to the Opus decoder |
| 361 | for decoding and others MUST be discarded.</t> |
| 362 | |
| 363 | <t>Opus supports 5 different audio bandwidths which may be adjusted during |
| 364 | the duration of a call. The RTP timestamp clock frequency is defined as |
| 365 | the highest supported sampling frequency of Opus, i.e. 48000 Hz, for all |
| 366 | modes and sampling rates of Opus. The unit |
| 367 | for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the |
| 368 | sample time of the first encoded sample in the encoded frame. For sampling |
| 369 | rates lower than 48000 Hz the number of samples has to be multiplied with |
| 370 | a multiplier according to <xref target="fs-upsample-factors"/> to determine |
| 371 | the RTP timestamp.</t> |
| 372 | |
| 373 | <texttable anchor='fs-upsample-factors'> |
| 374 | <ttcol align='center'>fs (Hz)</ttcol> |
| 375 | <ttcol align='center'>Multiplier</ttcol> |
| 376 | <c>8000</c> |
| 377 | <c>6</c> |
| 378 | <c>12000</c> |
| 379 | <c>4</c> |
| 380 | <c>16000</c> |
| 381 | <c>3</c> |
| 382 | <c>24000</c> |
| 383 | <c>2</c> |
| 384 | <c>48000</c> |
| 385 | <c>1</c> |
| 386 | <postamble> |
| 387 | fs specifies the audio sampling frequency in Hertz (Hz); Multiplier is the |
| 388 | value that the number of samples have to be multiplied with to calculate |
| 389 | the RTP timestamp. |
| 390 | </postamble> |
| 391 | </texttable> |
| 392 | </section> |
| 393 | |
| 394 | <section title='Payload Structure'> |
| 395 | <t> |
| 396 | The Opus encoder can be set to output encoded frames representing 2.5, 5, 10, 20, |
| 397 | 40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be |
| 398 | combined into a packet. The maximum packet length is limited to the amount of encoded |
| 399 | data representing 120 ms of speech or audio data. The packetization of encoded data |
| 400 | is purely done by the Opus encoder and therefore only one packet output from the Opus |
| 401 | encoder MUST be used as a payload. |
| 402 | </t> |
| 403 | |
| 404 | <t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t> |
| 405 | |
| 406 | <figure anchor="payload-structure" |
| 407 | title="Payload Structure with RTP header"> |
| 408 | <artwork> |
| 409 | <![CDATA[ |
| 410 | +----------+--------------+ |
| 411 | |RTP Header| Opus Payload | |
| 412 | +----------+--------------+ |
| 413 | ]]> |
| 414 | </artwork> |
| 415 | </figure> |
| 416 | |
| 417 | <t> |
| 418 | <xref target='opus-packetization'/> shows supported frame sizes for different modes |
| 419 | and sampling rates of Opus and how the timestamp needs to be incremented for |
| 420 | packetization. |
| 421 | </t> |
| 422 | |
| 423 | <texttable anchor='opus-packetization'> |
| 424 | <ttcol align='center'>Mode</ttcol> |
| 425 | <ttcol align='center'>fs</ttcol> |
| 426 | <ttcol align='center'>2.5</ttcol> |
| 427 | <ttcol align='center'>5</ttcol> |
| 428 | <ttcol align='center'>10</ttcol> |
| 429 | <ttcol align='center'>20</ttcol> |
| 430 | <ttcol align='center'>40</ttcol> |
| 431 | <ttcol align='center'>60</ttcol> |
| 432 | <c>ts incr</c> |
| 433 | <c>all</c> |
| 434 | <c>120</c> |
| 435 | <c>240</c> |
| 436 | <c>480</c> |
| 437 | <c>960</c> |
| 438 | <c>1920</c> |
| 439 | <c>2880</c> |
| 440 | <c>voice</c> |
| 441 | <c>nb/mb/wb/swb/fb</c> |
| 442 | <c></c> |
| 443 | <c></c> |
| 444 | <c>x</c> |
| 445 | <c>x</c> |
| 446 | <c>x</c> |
| 447 | <c>x</c> |
| 448 | <c>audio</c> |
| 449 | <c>nb/wb/swb/fb</c> |
| 450 | <c>x</c> |
| 451 | <c>x</c> |
| 452 | <c>x</c> |
| 453 | <c>x</c> |
| 454 | <c></c> |
| 455 | <c></c> |
| 456 | <postamble> |
| 457 | Mode specifies the Opus mode of operation; fs specifies the audio sampling |
| 458 | frequency in Hertz (Hz); 2.5, 5, 10, 20, 40, and 60 represent the duration of |
| 459 | encoded speech or audio data in a packet; ts incr specifies the |
| 460 | value the timestamp needs to be incremented for the representing packet size. |
| 461 | For multiple frames in a packet these values have to be multiplied with the |
| 462 | respective number of frames. |
| 463 | </postamble> |
| 464 | </texttable> |
| 465 | |
| 466 | </section> |
| 467 | |
| 468 | </section> |
| 469 | |
| 470 | <section title='Congestion Control'> |
| 471 | |
| 472 | <t>The adaptive nature of the Opus codec allows for an efficient |
| 473 | congestion control.</t> |
| 474 | |
| 475 | <t>The target bitrate of Opus can be adjusted at any point in time and |
| 476 | thus allowing for an efficient congestion control. Furthermore, the amount |
| 477 | of encoded speech or audio data encoded in a |
| 478 | single packet can be used for congestion control since the transmission |
| 479 | rate is inversely proportional to these frame sizes. A lower packet |
| 480 | transmission rate reduces the amount of header overhead but at the same |
| 481 | time increases latency and error sensitivity and should be done with care.</t> |
| 482 | |
| 483 | <t>It is RECOMMENDED that congestion control is applied during the |
| 484 | transmission of Opus encoded data.</t> |
| 485 | </section> |
| 486 | |
| 487 | <section title='IANA Considerations'> |
| 488 | <t>One media subtype (audio/opus) has been defined and registered as |
| 489 | described in the following section.</t> |
| 490 | |
| 491 | <section title='Opus Media Type Registration'> |
| 492 | <t>Media type registration is done according to <xref |
| 493 | target="RFC4288"/> and <xref target="RFC4855"/>.<vspace |
| 494 | blankLines='1'/></t> |
| 495 | |
| 496 | <t>Type name: audio<vspace blankLines='1'/></t> |
| 497 | <t>Subtype name: opus<vspace blankLines='1'/></t> |
| 498 | |
| 499 | <t>Required parameters:</t> |
| 500 | <t><list style="hanging"> |
| 501 | <t hangText="rate:"> RTP timestamp clock rate is incremented with |
| 502 | 48000 Hz clock rate for all modes of Opus and all sampling |
| 503 | frequencies. For audio sampling rates other than 48000 Hz the rate |
| 504 | has to be adjusted to 48000 Hz according to <xref target="fs-upsample-factors"/>. |
| 505 | </t> |
| 506 | </list></t> |
| 507 | |
| 508 | <t>Optional parameters:</t> |
| 509 | |
| 510 | <t><list style="hanging"> |
| 511 | <t hangText="maxcodedaudiobandwidth:"> |
| 512 | a hint about the maximum audio bandwidth that the receiver is capable of rendering. |
| 513 | The decoder MUST be capable of decoding |
| 514 | any audio bandwidth but due to hardware limitations only signals |
| 515 | up to the specified audio bandwidth can be processed. Sending signals |
| 516 | with higher audio bandwidth results in higher than necessary network |
| 517 | usage and encoding complexity, so an encoder SHOULD NOT encode |
| 518 | frequencies above the audio bandwidth specified by maxcodedaudiobandwidth. |
| 519 | Possible values are nb, mb, wb, swb, fb. By default, the receiver |
| 520 | is assumed to have no limitations, i.e. fb. |
| 521 | <vspace blankLines='1'/> |
| 522 | </t> |
| 523 | |
| 524 | <t hangText="maxptime:"> the decoder's maximum length of time in |
| 525 | milliseconds rounded up to the next full integer value represented |
| 526 | by the media in a packet that can be |
| 527 | encapsulated in a received packet according to Section 6 of |
| 528 | <xref target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, |
| 529 | and 60 or an arbitrary multiple of Opus frame sizes rounded up to |
| 530 | the next full integer value up to a maximum value of 120 as |
| 531 | defined in <xref target='opus-rtp-payload-format'/>. If no value is |
| 532 | specified, 120 is assumed as default. This value is a recommendation |
| 533 | by the decoding side to ensure the best |
| 534 | performance for the decoder. The decoder MUST be |
| 535 | capable of accepting any allowed packet sizes to |
| 536 | ensure maximum compatibility. |
| 537 | <vspace blankLines='1'/></t> |
| 538 | |
| 539 | <t hangText="ptime:"> the decoder's recommended length of time in |
| 540 | milliseconds rounded up to the next full integer value represented |
| 541 | by the media in a packet according to |
| 542 | Section 6 of <xref target="RFC4566"/>. Possible values are |
| 543 | 3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes |
| 544 | rounded up to the next full integer value up to a maximum |
| 545 | value of 120 as defined in <xref |
| 546 | target='opus-rtp-payload-format'/>. If no value is |
| 547 | specified, 20 is assumed as default. If ptime is greater than |
| 548 | maxptime, ptime MUST be ignored. This parameter MAY be changed |
| 549 | during a session. This value is a recommendation by the decoding |
| 550 | side to ensure the best |
| 551 | performance for the decoder. The decoder MUST be |
| 552 | capable of accepting any allowed packet sizes to |
| 553 | ensure maximum compatibility. |
| 554 | <vspace blankLines='1'/></t> |
| 555 | |
| 556 | <t hangText="minptime:"> the decoder's minimum length of time in |
| 557 | milliseconds rounded up to the next full integer value represented |
| 558 | by the media in a packet that SHOULD |
| 559 | be encapsulated in a received packet according to Section 6 of <xref |
| 560 | target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, and 60 |
| 561 | or an arbitrary multiple of Opus frame sizes rounded up to the next |
| 562 | full integer value up to a maximum value of 120 |
| 563 | as defined in <xref target='opus-rtp-payload-format'/>. If no value is |
| 564 | specified, 3 is assumed as default. This value is a recommendation |
| 565 | by the decoding side to ensure the best |
| 566 | performance for the decoder. The decoder MUST be |
| 567 | capable to accept any allowed packet sizes to |
| 568 | ensure maximum compatibility. |
| 569 | <vspace blankLines='1'/></t> |
| 570 | |
| 571 | <t hangText="maxaveragebitrate:"> specifies the maximum average |
| 572 | receive bitrate of a session in bits per second (b/s). The actual |
| 573 | value of the bitrate may vary as it is dependent on the |
| 574 | characteristics of the media in a packet. Note that the maximum |
| 575 | average bitrate MAY be modified dynamically during a session. Any |
| 576 | positive integer is allowed but values outside the range between |
| 577 | 6000 and 510000 SHOULD be ignored. If no value is specified, the |
| 578 | maximum value specified in <xref target='bitrate_by_bandwidth'/> |
| 579 | for the corresponding mode of Opus and corresponding maxcodedaudiobandwidth: |
| 580 | will be the default.<vspace blankLines='1'/></t> |
| 581 | |
| 582 | <t hangText="stereo:"> |
| 583 | specifies whether the decoder prefers receiving stereo or mono signals. |
| 584 | Possible values are 1 and 0 where 1 specifies that stereo signals are preferred |
| 585 | and 0 specifies that only mono signals are preferred. |
| 586 | Independent of the stereo parameter every receiver MUST be able to receive and |
| 587 | decode stereo signals but sending stereo signals to a receiver that signaled a |
| 588 | preference for mono signals may result in higher than necessary network |
| 589 | utilisation and encoding complexity. If no value is specified, mono |
| 590 | is assumed (stereo=0).<vspace blankLines='1'/> |
| 591 | </t> |
| 592 | |
| 593 | <t hangText="cbr:"> |
| 594 | specifies if the decoder prefers the use of a constant bitrate versus |
| 595 | variable bitrate. Possible values are 1 and 0 where 1 specifies constant |
| 596 | bitrate and 0 specifies variable bitrate. If no value is specified, cbr |
| 597 | is assumed to be 0. Note that the maximum average bitrate may still be |
| 598 | changed, e.g. to adapt to changing network conditions.<vspace blankLines='1'/> |
| 599 | </t> |
| 600 | |
| 601 | <t hangText="useinbandfec:"> specifies that Opus in-band FEC is |
| 602 | supported by the decoder and MAY be used during a |
| 603 | session. Possible values are 1 and 0. It is RECOMMENDED to provide |
| 604 | 0 in case FEC is not implemented on the receiving side. If no |
| 605 | value is specified, useinbandfec is assumed to be 1.<vspace blankLines='1'/></t> |
| 606 | |
| 607 | <t hangText="usedtx:"> specifies if the decoder prefers the use of |
| 608 | DTX. Possible values are 1 and 0. If no value is specified, usedtx |
| 609 | is assumed to be 0.<vspace blankLines='1'/></t> |
| 610 | </list></t> |
| 611 | |
| 612 | <t>Encoding considerations:<vspace blankLines='1'/></t> |
| 613 | <t><list style="hanging"> |
| 614 | <t>Opus media type is framed and consists of binary data according |
| 615 | to Section 4.8 in <xref target="RFC4288"/>.</t> |
| 616 | </list></t> |
| 617 | |
| 618 | <t>Security considerations: </t> |
| 619 | <t><list style="hanging"> |
| 620 | <t>See <xref target='security-considerations'/> of this document.</t> |
| 621 | </list></t> |
| 622 | |
| 623 | <t>Interoperability considerations: none<vspace blankLines='1'/></t> |
| 624 | <t>Published specification: none<vspace blankLines='1'/></t> |
| 625 | |
| 626 | <t>Applications that use this media type: </t> |
| 627 | <t><list style="hanging"> |
| 628 | <t>Any application that requires the transport of |
| 629 | speech or audio data may use this media type. Some examples are, |
| 630 | but not limited to, audio and video conferencing, Voice over IP, |
| 631 | media streaming.</t> |
| 632 | </list></t> |
| 633 | |
| 634 | <t>Person & email address to contact for further information:</t> |
| 635 | <t><list style="hanging"> |
| 636 | <t>SILK Support silksupport@skype.net</t> |
| 637 | <t>Jean-Marc Valin jmvalin@jmvalin.ca</t> |
| 638 | </list></t> |
| 639 | |
| 640 | <t>Intended usage: COMMON<vspace blankLines='1'/></t> |
| 641 | |
| 642 | <t>Restrictions on usage:<vspace blankLines='1'/></t> |
| 643 | |
| 644 | <t><list style="hanging"> |
| 645 | <t>For transfer over RTP, the RTP payload format (<xref |
| 646 | target='opus-rtp-payload-format'/> of this document) SHALL be |
| 647 | used.</t> |
| 648 | </list></t> |
| 649 | |
| 650 | <t>Author:</t> |
| 651 | <t><list style="hanging"> |
| 652 | <t>Julian Spittka julian.spittka@skype.net<vspace blankLines='1'/></t> |
| 653 | <t>Koen Vos koen.vos@skype.net<vspace blankLines='1'/></t> |
| 654 | <t>Jean-Marc Valin jmvalin@jmvalin.ca<vspace blankLines='1'/></t> |
| 655 | </list></t> |
| 656 | |
| 657 | <t> Change controller: TBD</t> |
| 658 | </section> |
| 659 | |
| 660 | <section title='Mapping to SDP Parameters'> |
| 661 | <t>The information described in the media type specification has a |
| 662 | specific mapping to fields in the Session Description Protocol (SDP) |
| 663 | <xref target="RFC4566"/>, which is commonly used to describe RTP |
| 664 | sessions. When SDP is used to specify sessions employing the Opus codec, |
| 665 | the mapping is as follows:</t> |
| 666 | |
| 667 | <t> |
| 668 | <list style="symbols"> |
| 669 | <t>The media type ("audio") goes in SDP "m=" as the media name.</t> |
| 670 | |
| 671 | <t>The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding |
| 672 | name. The RTP clock rate in "a=rtpmap" MUST be mapped to the required |
| 673 | media type parameter "rate".</t> |
| 674 | |
| 675 | <t>The optional media type parameters "ptime" and "maxptime" are |
| 676 | mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the |
| 677 | SDP.</t> |
| 678 | |
| 679 | <t>All remaining media type parameters are mapped to the "a=fmtp" |
| 680 | attribute in the SDP by copying them directly from the media type |
| 681 | parameter string as a semicolon-separated list of parameter=value |
| 682 | pairs (e.g. maxaveragebitrate=20000).</t> |
| 683 | </list> |
| 684 | </t> |
| 685 | |
| 686 | <t>Below are some examples of SDP session descriptions for Opus:</t> |
| 687 | |
| 688 | <t>Example 1: Standard session with 48000 Hz clock rate</t> |
| 689 | <figure> |
| 690 | <artwork> |
| 691 | <![CDATA[ |
| 692 | m=audio 54312 RTP/AVP 101 |
| 693 | a=rtpmap:101 opus/48000 |
| 694 | ]]> |
| 695 | </artwork> |
| 696 | </figure> |
| 697 | |
| 698 | |
| 699 | <t>Example 2: 16000 Hz clock rate, maximum packet size of 40 ms, |
| 700 | recommended packet size of 40 ms, maximum average bitrate of 20000 bps, |
| 701 | stereo signals are preferred, FEC is allowed, DTX is not allowed</t> |
| 702 | |
| 703 | <figure> |
| 704 | <artwork> |
| 705 | <![CDATA[ |
| 706 | m=audio 54312 RTP/AVP 101 |
| 707 | a=rtpmap:101 opus/48000 |
| 708 | a=fmtp:101 maxcodedaudiobandwidth=wb; maxaveragebitrate=20000; |
| 709 | stereo=1; useinbandfec=1; usedtx=0 |
| 710 | a=ptime:40 |
| 711 | a=maxptime:40 |
| 712 | ]]> |
| 713 | </artwork> |
| 714 | </figure> |
| 715 | |
| 716 | <section title='Offer-Answer Model Considerations for Opus'> |
| 717 | |
| 718 | <t>When using the offer-answer procedure described in <xref |
| 719 | target="RFC3264"/> to negotiate the use of Opus, the following |
| 720 | considerations apply:</t> |
| 721 | |
| 722 | <t><list style="symbols"> |
| 723 | |
| 724 | <t>Opus supports several clock rates. For signaling purposes only |
| 725 | the highest, i.e. 48000, is used. The actual clock rate of the |
| 726 | corresponding media is signaled inside the payload and is not |
| 727 | subject to this payload format description. The decoder MUST be |
| 728 | capable to decode every received clock rate. An example |
| 729 | is shown below: |
| 730 | |
| 731 | <figure> |
| 732 | <artwork> |
| 733 | <![CDATA[ |
| 734 | m=audio 54312 RTP/AVP 100 |
| 735 | a=rtpmap:100 opus/48000 |
| 736 | ]]> |
| 737 | </artwork> |
| 738 | </figure> |
| 739 | </t> |
| 740 | |
| 741 | <t>The parameters "ptime" and "maxptime" are unidirectional |
| 742 | receive-only parameters and typically will not compromise |
| 743 | interoperability; however, dependent on the set values of the |
| 744 | parameters the performance of the application may suffer. <xref |
| 745 | target="RFC3264"/> defines the SDP offer-answer handling of the |
| 746 | "ptime" parameter. The "maxptime" parameter MUST be handled in the |
| 747 | same way.</t> |
| 748 | |
| 749 | <t> |
| 750 | The parameter "minptime" is a unidirectional |
| 751 | receive-only parameters and typically will not compromise |
| 752 | interoperability; however, dependent on the set values of the |
| 753 | parameter the performance of the application may suffer and should be |
| 754 | set with care. |
| 755 | </t> |
| 756 | |
| 757 | <t> |
| 758 | The parameter "maxcodedaudiobandwidth" is a unidirectional receive-only |
| 759 | parameter that reflects limitations of the local receiver. The sender |
| 760 | of the other side SHOULD NOT send with an audio bandwidth higher than |
| 761 | "maxcodedaudiobandwidth" as this would lead to inefficient use of network resources. The "maxcodedaudiobandwidth" parameter does not |
| 762 | affect interoperability. Also, this parameter SHOULD NOT be used |
| 763 | to adjust the audio bandwidth as a function of the bitrates, as this |
| 764 | is the responsability of the Opus encoder implementation. |
| 765 | </t> |
| 766 | |
| 767 | <t>The parameter "maxaveragebitrate" is a unidirectional receive-only |
| 768 | parameter that reflects limitations of the local receiver. The sender |
| 769 | of the other side MUST NOT send with an average bitrate higher than |
| 770 | "maxaveragebitrate" as it might overload the network and/or |
| 771 | receiver. The parameter "maxaveragebitrate" typically will not |
| 772 | compromise interoperability; however, dependent on the set value of |
| 773 | the parameter the performance of the application may suffer and should |
| 774 | be set with care.</t> |
| 775 | |
| 776 | <t>If the parameter "maxaveragebitrate" is below the range specified |
| 777 | in <xref target='bitrate_by_bandwidth'/> the session MUST be rejected.</t> |
| 778 | |
| 779 | <t> |
| 780 | The parameter "stereo" is a unidirectional receive-only |
| 781 | parameter. |
| 782 | </t> |
| 783 | |
| 784 | <t> |
| 785 | The parameter "cbr" is a unidirectional receive-only |
| 786 | parameter. |
| 787 | </t> |
| 788 | |
| 789 | <t>The parameter "useinbandfec" is a unidirectional receive-only |
| 790 | parameter.</t> |
| 791 | |
| 792 | <t>The parameter "usedtx" is a unidirectional receive-only |
| 793 | parameter.</t> |
| 794 | |
| 795 | <t>Any unknown parameter in an offer MUST be ignored by the receiver |
| 796 | and MUST be removed from the answer.</t> |
| 797 | |
| 798 | </list></t> |
| 799 | </section> |
| 800 | |
| 801 | <section title='Declarative SDP Considerations for Opus'> |
| 802 | |
| 803 | <t>For declarative use of SDP such as in Session Announcement Protocol |
| 804 | (SAP), <xref target="RFC2974"/>, and RTSP, <xref target="RFC2326"/>, for |
| 805 | Opus, the following needs to be considered:</t> |
| 806 | |
| 807 | <t><list style="symbols"> |
| 808 | |
| 809 | <t>The values for "maxptime", "ptime", "minptime", "maxcodedaudiobandwidth", and |
| 810 | "maxaveragebitrate" should be selected carefully to ensure that a |
| 811 | reasonable performance can be achieved for the participants of a session.</t> |
| 812 | |
| 813 | <t> |
| 814 | The values for "maxptime", "ptime", and "minptime" of the payload |
| 815 | format configuration are recommendations by the decoding side to ensure |
| 816 | the best performance for the decoder. The decoder MUST be |
| 817 | capable to accept any allowed packet sizes to |
| 818 | ensure maximum compatibility. |
| 819 | </t> |
| 820 | |
| 821 | <t>All other parameters of the payload format configuration are declarative |
| 822 | and a participant MUST use the configurations that are provided for |
| 823 | the session. More than one configuration may be provided if necessary |
| 824 | by declaring multiple RTP payload types; however, the number of types |
| 825 | should be kept small.</t> |
| 826 | </list></t> |
| 827 | </section> |
| 828 | </section> |
| 829 | </section> |
| 830 | |
| 831 | <section title='Security Considerations' anchor='security-considerations'> |
| 832 | |
| 833 | <t>All RTP packets using the payload format defined in this specification |
| 834 | are subject to the general security considerations discussed in the RTP |
| 835 | specification <xref target="RFC3550"/> and any profile from |
| 836 | e.g. <xref target="RFC3711"/> or <xref target="RFC3551"/>.</t> |
| 837 | |
| 838 | <t>This payload format transports Opus encoded speech or audio data, |
| 839 | hence, security issues include confidentiality, integrity protection, and |
| 840 | authentication of the speech or audio itself. The Opus payload format does |
| 841 | not have any built-in security mechanisms. Any suitable external |
| 842 | mechanisms, such as SRTP <xref target="RFC3711"/>, MAY be used.</t> |
| 843 | |
| 844 | <t>This payload format and the Opus encoding do not exhibit any |
| 845 | significant non-uniformity in the receiver-end computational load and thus |
| 846 | are unlikely to pose a denial-of-service threat due to the receipt of |
| 847 | pathological datagrams.</t> |
| 848 | </section> |
| 849 | |
| 850 | <section title='Acknowledgements'> |
| 851 | <t>TBD</t> |
| 852 | </section> |
| 853 | </middle> |
| 854 | |
| 855 | <back> |
| 856 | <references title="Normative References"> |
| 857 | &rfc2119; |
| 858 | &rfc3550; |
| 859 | &rfc3711; |
| 860 | &rfc3551; |
| 861 | &rfc4288; |
| 862 | &rfc4855; |
| 863 | &rfc4566; |
| 864 | &rfc3264; |
| 865 | &rfc2974; |
| 866 | &rfc2326; |
| 867 | </references> |
| 868 | |
| 869 | |
| 870 | <section title='Informational References'> |
| 871 | <t><list style="hanging"> |
| 872 | <t>[codec] http://datatracker.ietf.org/wg/codec/</t> |
| 873 | <t>[Opus] http://datatracker.ietf.org/doc/draft-ietf-codec-opus/</t> |
| 874 | </list></t> |
| 875 | </section> |
| 876 | |
| 877 | </back> |
| 878 | </rfc> |