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 rfc3389 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3389.xml'> 5 <!ENTITY rfc3550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'> 6 <!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'> 7 <!ENTITY rfc3551 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml'> 8 <!ENTITY rfc6838 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6838.xml'> 9 <!ENTITY rfc4855 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml'> 10 <!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'> 11 <!ENTITY rfc4585 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml'> 12 <!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'> 13 <!ENTITY rfc2974 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml'> 14 <!ENTITY rfc2326 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml'> 15 <!ENTITY rfc3555 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3555.xml'> 16 <!ENTITY rfc5124 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml'> 17 <!ENTITY rfc5405 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5405.xml'> 18 <!ENTITY rfc5576 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5576.xml'> 19 <!ENTITY rfc6562 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6562.xml'> 20 <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> 21 <!ENTITY rfc7202 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7202.xml'> 22 <!ENTITY nbsp " "> 23 ]> 24 25 <rfc category="std" ipr="trust200902" docName="draft-ietf-payload-rtp-opus-11"> 26 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 27 28 <?rfc strict="yes" ?> 29 <?rfc toc="yes" ?> 30 <?rfc tocdepth="3" ?> 31 <?rfc tocappendix='no' ?> 32 <?rfc tocindent='yes' ?> 33 <?rfc symrefs="yes" ?> 34 <?rfc sortrefs="yes" ?> 35 <?rfc compact="no" ?> 36 <?rfc subcompact="yes" ?> 37 <?rfc iprnotified="yes" ?> 38 39 <front> 40 <title abbrev="RTP Payload Format for Opus"> 41 RTP Payload Format for the Opus Speech and Audio Codec 42 </title> 43 44 <author fullname="Julian Spittka" initials="J." surname="Spittka"> 45 <address> 46 <email>jspittka (a] gmail.com</email> 47 </address> 48 </author> 49 50 <author initials='K.' surname='Vos' fullname='Koen Vos'> 51 <organization>vocTone</organization> 52 <address> 53 <postal> 54 <street></street> 55 <code></code> 56 <city></city> 57 <region></region> 58 <country></country> 59 </postal> 60 <email>koenvos74 (a] gmail.com</email> 61 </address> 62 </author> 63 64 <author initials="JM" surname="Valin" fullname="Jean-Marc Valin"> 65 <organization>Mozilla</organization> 66 <address> 67 <postal> 68 <street>331 E. Evelyn Avenue</street> 69 <city>Mountain View</city> 70 <region>CA</region> 71 <code>94041</code> 72 <country>USA</country> 73 </postal> 74 <email>jmvalin (a] jmvalin.ca</email> 75 </address> 76 </author> 77 78 <date day='14' month='April' year='2015' /> 79 80 <abstract> 81 <t> 82 This document defines the Real-time Transport Protocol (RTP) payload 83 format for packetization of Opus encoded 84 speech and audio data necessary to integrate the codec in the 85 most compatible way. It also provides an applicability statement 86 for the use of Opus over RTP. Further, it describes media type registrations 87 for the RTP payload format. 88 </t> 89 </abstract> 90 </front> 91 92 <middle> 93 <section title='Introduction'> 94 <t> 95 Opus <xref target="RFC6716"/> is a speech and audio codec developed within the 96 IETF Internet Wideband Audio Codec working group. The codec 97 has a very low algorithmic delay and it 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 necessary to 107 integrate Opus in the 108 most compatible way. It also provides an applicability statement 109 for the use of Opus over RTP. 110 Further, it describes media type registrations for 111 the RTP payload format. 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="audio bandwidth:"> The range of audio frequecies being coded</t> 122 <t hangText="CBR:"> Constant bitrate</t> 123 <t hangText="CPU:"> Central Processing Unit</t> 124 <t hangText="DTX:"> Discontinuous transmission</t> 125 <t hangText="FEC:"> Forward error correction</t> 126 <t hangText="IP:"> Internet Protocol</t> 127 <t hangText="samples:"> Speech or audio samples (per channel)</t> 128 <t hangText="SDP:"> Session Description Protocol</t> 129 <t hangText="VBR:"> Variable bitrate</t> 130 </list> 131 </t> 132 <t> 133 Throughout this document, we refer to the following definitions: 134 </t> 135 <texttable anchor='bandwidth_definitions'> 136 <ttcol align='center'>Abbreviation</ttcol> 137 <ttcol align='center'>Name</ttcol> 138 <ttcol align='center'>Audio Bandwidth (Hz)</ttcol> 139 <ttcol align='center'>Sampling Rate (Hz)</ttcol> 140 <c>NB</c> 141 <c>Narrowband</c> 142 <c>0 - 4000</c> 143 <c>8000</c> 144 145 <c>MB</c> 146 <c>Mediumband</c> 147 <c>0 - 6000</c> 148 <c>12000</c> 149 150 <c>WB</c> 151 <c>Wideband</c> 152 <c>0 - 8000</c> 153 <c>16000</c> 154 155 <c>SWB</c> 156 <c>Super-wideband</c> 157 <c>0 - 12000</c> 158 <c>24000</c> 159 160 <c>FB</c> 161 <c>Fullband</c> 162 <c>0 - 20000</c> 163 <c>48000</c> 164 165 <postamble> 166 Audio bandwidth naming 167 </postamble> 168 </texttable> 169 </section> 170 171 <section title='Opus Codec'> 172 <t> 173 Opus encodes speech 174 signals as well as general audio signals. Two different modes can be 175 chosen, a voice mode or an audio mode, to allow the most efficient coding 176 depending on the type of the input signal, the sampling frequency of the 177 input signal, and the intended application. 178 </t> 179 180 <t> 181 The voice mode allows efficient encoding of voice signals at lower bit 182 rates while the audio mode is optimized for general audio signals at medium and 183 higher bitrates. 184 </t> 185 186 <t> 187 Opus is highly scalable in terms of audio 188 bandwidth, bitrate, and complexity. Further, Opus allows 189 transmitting stereo signals with in-band signaling in the bit-stream. 190 </t> 191 192 <section title='Network Bandwidth'> 193 <t> 194 Opus supports bitrates from 6 kb/s to 510 kb/s. 195 The bitrate can be changed dynamically within that range. 196 All 197 other parameters being 198 equal, higher bitrates result in higher audio quality. 199 </t> 200 <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'> 201 <t> 202 For a frame size of 203 20 ms, these 204 are the bitrate "sweet spots" for Opus in various configurations: 205 206 <list style="symbols"> 207 <t>8-12 kb/s for NB speech,</t> 208 <t>16-20 kb/s for WB speech,</t> 209 <t>28-40 kb/s for FB speech,</t> 210 <t>48-64 kb/s for FB mono music, and</t> 211 <t>64-128 kb/s for FB stereo music.</t> 212 </list> 213 </t> 214 </section> 215 <section title='Variable versus Constant Bitrate' anchor='variable-vs-constant-bitrate'> 216 <t> 217 For the same average bitrate, variable bitrate (VBR) can achieve higher audio quality 218 than constant bitrate (CBR). For the majority of voice transmission applications, VBR 219 is the best choice. One reason for choosing CBR is the potential 220 information leak that <spanx style='emph'>might</spanx> occur when encrypting the 221 compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is 222 appropriate for encrypted audio communications. In the case where an existing 223 VBR stream needs to be converted to CBR for security reasons, then the Opus padding 224 mechanism described in <xref target="RFC6716"/> is the RECOMMENDED way to achieve padding 225 because the RTP padding bit is unencrypted.</t> 226 227 <t> 228 The bitrate can be adjusted at any point in time. To avoid congestion, 229 the average bitrate SHOULD NOT exceed the available 230 network bandwidth. If no target bitrate is specified, the bitrates specified in 231 <xref target='bitrate_by_bandwidth'/> are RECOMMENDED. 232 </t> 233 234 </section> 235 236 <section title='Discontinuous Transmission (DTX)'> 237 238 <t> 239 Opus can, as described in <xref target='variable-vs-constant-bitrate'/>, 240 be operated with a variable bitrate. In that case, the encoder will 241 automatically reduce the bitrate for certain input signals, like periods 242 of silence. When using continuous transmission, it will reduce the 243 bitrate when the characteristics of the input signal permit, but 244 will never interrupt the transmission to the receiver. Therefore, the 245 received signal will maintain the same high level of audio quality over the 246 full duration of a transmission while minimizing the average bit 247 rate over time. 248 </t> 249 250 <t> 251 In cases where the bitrate of Opus needs to be reduced even 252 further or in cases where only constant bitrate is available, 253 the Opus encoder can use discontinuous 254 transmission (DTX), where parts of the encoded signal that 255 correspond to periods of silence in the input speech or audio signal 256 are not transmitted to the receiver. A receiver can distinguish 257 between DTX and packet loss by looking for gaps in the sequence 258 number, as described by Section 4.1 259 of <xref target="RFC3551"/>. 260 </t> 261 262 <t> 263 On the receiving side, the non-transmitted parts will be handled by a 264 frame loss concealment unit in the Opus decoder which generates a 265 comfort noise signal to replace the non transmitted parts of the 266 speech or audio signal. Use of <xref target="RFC3389"/> Comfort 267 Noise (CN) with Opus is discouraged. 268 The transmitter MUST drop whole frames only, 269 based on the size of the last transmitted frame, 270 to ensure successive RTP timestamps differ by a multiple of 120 and 271 to allow the receiver to use whole frames for concealment. 272 </t> 273 274 <t> 275 DTX can be used with both variable and constant bitrate. 276 It will have a slightly lower speech or audio 277 quality than continuous transmission. Therefore, using continuous 278 transmission is RECOMMENDED unless constraints on available network bandwidth 279 are severe. 280 </t> 281 282 </section> 283 284 </section> 285 286 <section title='Complexity'> 287 288 <t> 289 Complexity of the encoder can be scaled to optimize for CPU resources in real-time, mostly as 290 a trade-off between audio quality and bitrate. Also, different modes of Opus have different complexity. 291 </t> 292 293 </section> 294 295 <section title="Forward Error Correction (FEC)"> 296 297 <t> 298 The voice mode of Opus allows for embedding "in-band" forward error correction (FEC) 299 data into the Opus bit stream. This FEC scheme adds 300 redundant information about the previous packet (N-1) to the current 301 output packet N. For 302 each frame, the encoder decides whether to use FEC based on (1) an 303 externally-provided estimate of the channel's packet loss rate; (2) an 304 externally-provided estimate of the channel's capacity; (3) the 305 sensitivity of the audio or speech signal to packet loss; (4) whether 306 the receiving decoder has indicated it can take advantage of "in-band" 307 FEC information. The decision to send "in-band" FEC information is 308 entirely controlled by the encoder and therefore no special precautions 309 for the payload have to be taken. 310 </t> 311 312 <t> 313 On the receiving side, the decoder can take advantage of this 314 additional information when it loses a packet and the next packet 315 is available. In order to use the FEC data, the jitter buffer needs 316 to provide access to payloads with the FEC data. 317 Instead of performing loss concealment for a missing packet, the 318 receiver can then configure its decoder to decode the FEC data from the next packet. 319 </t> 320 321 <t> 322 Any compliant Opus decoder is capable of ignoring 323 FEC information when it is not needed, so encoding with FEC cannot cause 324 interoperability problems. 325 However, if FEC cannot be used on the receiving side, then FEC 326 SHOULD NOT be used, as it leads to an inefficient usage of network 327 resources. Decoder support for FEC SHOULD be indicated at the time a 328 session is set up. 329 </t> 330 331 </section> 332 333 <section title='Stereo Operation'> 334 335 <t> 336 Opus allows for transmission of stereo audio signals. This operation 337 is signaled in-band in the Opus bit-stream and no special arrangement 338 is needed in the payload format. An 339 Opus decoder is capable of handling a stereo encoding, but an 340 application might only be capable of consuming a single audio 341 channel. 342 </t> 343 <t> 344 If a decoder cannot take advantage of the benefits of a stereo signal 345 this SHOULD be indicated at the time a session is set up. In that case 346 the sending side SHOULD NOT send stereo signals as it leads to an 347 inefficient usage of network resources. 348 </t> 349 350 </section> 351 352 </section> 353 354 <section title='Opus RTP Payload Format' anchor='opus-rtp-payload-format'> 355 <t>The payload format for Opus consists of the RTP header and Opus payload 356 data.</t> 357 <section title='RTP Header Usage'> 358 <t>The format of the RTP header is specified in <xref target="RFC3550"/>. 359 The use of the fields of the RTP header by the Opus payload format is 360 consistent with that specification.</t> 361 362 <t>The payload length of Opus is an integer number of octets and 363 therefore no padding is necessary. The payload MAY be padded by an 364 integer number of octets according to <xref target="RFC3550"/>, 365 although the Opus internal padding is preferred.</t> 366 367 <t>The timestamp, sequence number, and marker bit (M) of the RTP header 368 are used in accordance with Section 4.1 369 of <xref target="RFC3551"/>.</t> 370 371 <t>The RTP payload type for Opus is to be assigned dynamically.</t> 372 373 <t>The receiving side MUST be prepared to receive duplicate RTP 374 packets. The receiver MUST provide at most one of those payloads to the 375 Opus decoder for decoding, and MUST discard the others.</t> 376 377 <t>Opus supports 5 different audio bandwidths, which can be adjusted during 378 a stream. 379 The RTP timestamp is incremented with a 48000 Hz clock rate 380 for all modes of Opus and all sampling rates. 381 The unit 382 for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the 383 sample time of the first encoded sample in the encoded frame. 384 For data encoded with sampling rates other than 48000 Hz, 385 the sampling rate has to be adjusted to 48000 Hz.</t> 386 387 </section> 388 389 <section title='Payload Structure'> 390 <t> 391 The Opus encoder can output encoded frames representing 2.5, 5, 10, 20, 392 40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be 393 combined into a packet, up to a maximum packet duration representing 394 120 ms of speech or audio data. The grouping of one or more Opus 395 frames into a single Opus packet is defined in Section 3 of 396 <xref target="RFC6716"/>. An RTP payload MUST contain exactly one 397 Opus packet as defined by that document. 398 </t> 399 400 <t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t> 401 402 <figure anchor="payload-structure" 403 title="Packet structure with RTP header"> 404 <artwork align="center"> 405 <![CDATA[ 406 +----------+--------------+ 407 |RTP Header| Opus Payload | 408 +----------+--------------+ 409 ]]> 410 </artwork> 411 </figure> 412 413 <t> 414 <xref target='opus-packetization'/> shows supported frame sizes in 415 milliseconds of encoded speech or audio data for the speech and audio modes 416 (Mode) and sampling rates (fs) of Opus and shows how the timestamp is 417 incremented for packetization (ts incr). If the Opus encoder 418 outputs multiple encoded frames into a single packet, the timestamp 419 increment is the sum of the increments for the individual frames. 420 </t> 421 422 <texttable anchor='opus-packetization' title="Supported Opus frame 423 sizes and timestamp increments marked with an o. Unsupported marked with an x."> 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>x</c> 443 <c>x</c> 444 <c>o</c> 445 <c>o</c> 446 <c>o</c> 447 <c>o</c> 448 <c>audio</c> 449 <c>NB/WB/SWB/FB</c> 450 <c>o</c> 451 <c>o</c> 452 <c>o</c> 453 <c>o</c> 454 <c>x</c> 455 <c>x</c> 456 </texttable> 457 458 </section> 459 460 </section> 461 462 <section title='Congestion Control'> 463 464 <t>The target bitrate of Opus can be adjusted at any point in time, thus 465 allowing efficient congestion control. Furthermore, the amount 466 of encoded speech or audio data encoded in a 467 single packet can be used for congestion control, since the transmission 468 rate is inversely proportional to the packet duration. A lower packet 469 transmission rate reduces the amount of header overhead, but at the same 470 time increases latency and loss sensitivity, so it ought to be used with 471 care.</t> 472 473 <t>Since UDP does not provide congestion control, applications that use 474 RTP over UDP SHOULD implement their own congestion control above the 475 UDP layer <xref target="RFC5405"/>. Work in the rmcat working group 476 <xref target="rmcat"/> describes the 477 interactions and conceptual interfaces necessary between the application 478 components that relate to congestion control, including the RTP layer, 479 the higher-level media codec control layer, and the lower-level 480 transport interface, as well as components dedicated to congestion 481 control functions.</t> 482 </section> 483 484 <section title='IANA Considerations'> 485 <t>One media subtype (audio/opus) has been defined and registered as 486 described in the following section.</t> 487 488 <section title='Opus Media Type Registration'> 489 <t>Media type registration is done according to <xref 490 target="RFC6838"/> and <xref target="RFC4855"/>.<vspace 491 blankLines='1'/></t> 492 493 <t>Type name: audio<vspace blankLines='1'/></t> 494 <t>Subtype name: opus<vspace blankLines='1'/></t> 495 496 <t>Required parameters:</t> 497 <t><list style="hanging"> 498 <t hangText="rate:"> the RTP timestamp is incremented with a 499 48000 Hz clock rate for all modes of Opus and all sampling 500 rates. For data encoded with sampling rates other than 48000 Hz, 501 the sampling rate has to be adjusted to 48000 Hz. 502 </t> 503 </list></t> 504 505 <t>Optional parameters:</t> 506 507 <t><list style="hanging"> 508 <t hangText="maxplaybackrate:"> 509 a hint about the maximum output sampling rate that the receiver is 510 capable of rendering in Hz. 511 The decoder MUST be capable of decoding 512 any audio bandwidth but due to hardware limitations only signals 513 up to the specified sampling rate can be played back. Sending signals 514 with higher audio bandwidth results in higher than necessary network 515 usage and encoding complexity, so an encoder SHOULD NOT encode 516 frequencies above the audio bandwidth specified by maxplaybackrate. 517 This parameter can take any value between 8000 and 48000, although 518 commonly the value will match one of the Opus bandwidths 519 (<xref target="bandwidth_definitions"/>). 520 By default, the receiver is assumed to have no limitations, i.e. 48000. 521 <vspace blankLines='1'/> 522 </t> 523 524 <t hangText="sprop-maxcapturerate:"> 525 a hint about the maximum input sampling rate that the sender is likely to produce. 526 This is not a guarantee that the sender will never send any higher bandwidth 527 (e.g. it could send a pre-recorded prompt that uses a higher bandwidth), but it 528 indicates to the receiver that frequencies above this maximum can safely be discarded. 529 This parameter is useful to avoid wasting receiver resources by operating the audio 530 processing pipeline (e.g. echo cancellation) at a higher rate than necessary. 531 This parameter can take any value between 8000 and 48000, although 532 commonly the value will match one of the Opus bandwidths 533 (<xref target="bandwidth_definitions"/>). 534 By default, the sender is assumed to have no limitations, i.e. 48000. 535 <vspace blankLines='1'/> 536 </t> 537 538 <t hangText="maxptime:"> the maximum duration of media represented 539 by a packet (according to Section 6 of 540 <xref target="RFC4566"/>) that a decoder wants to receive, in 541 milliseconds rounded up to the next full integer value. 542 Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary 543 multiple of an Opus frame size rounded up to the next full integer 544 value, up to a maximum value of 120, as 545 defined in <xref target='opus-rtp-payload-format'/>. If no value is 546 specified, the default is 120. 547 <vspace blankLines='1'/></t> 548 549 <t hangText="ptime:"> the preferred duration of media represented 550 by a packet (according to Section 6 of 551 <xref target="RFC4566"/>) that a decoder wants to receive, in 552 milliseconds rounded up to the next full integer value. 553 Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary 554 multiple of an Opus frame size rounded up to the next full integer 555 value, up to a maximum value of 120, as defined in <xref 556 target='opus-rtp-payload-format'/>. If no value is 557 specified, the default is 20. 558 <vspace blankLines='1'/></t> 559 560 <t hangText="maxaveragebitrate:"> specifies the maximum average 561 receive bitrate of a session in bits per second (b/s). The actual 562 value of the bitrate can vary, as it is dependent on the 563 characteristics of the media in a packet. Note that the maximum 564 average bitrate MAY be modified dynamically during a session. Any 565 positive integer is allowed, but values outside the range 566 6000 to 510000 SHOULD be ignored. If no value is specified, the 567 maximum value specified in <xref target='bitrate_by_bandwidth'/> 568 for the corresponding mode of Opus and corresponding maxplaybackrate 569 is the default.<vspace blankLines='1'/></t> 570 571 <t hangText="stereo:"> 572 specifies whether the decoder prefers receiving stereo or mono signals. 573 Possible values are 1 and 0 where 1 specifies that stereo signals are preferred, 574 and 0 specifies that only mono signals are preferred. 575 Independent of the stereo parameter every receiver MUST be able to receive and 576 decode stereo signals but sending stereo signals to a receiver that signaled a 577 preference for mono signals may result in higher than necessary network 578 utilization and encoding complexity. If no value is specified, 579 the default is 0 (mono).<vspace blankLines='1'/> 580 </t> 581 582 <t hangText="sprop-stereo:"> 583 specifies whether the sender is likely to produce stereo audio. 584 Possible values are 1 and 0, where 1 specifies that stereo signals are likely to 585 be sent, and 0 specifies that the sender will likely only send mono. 586 This is not a guarantee that the sender will never send stereo audio 587 (e.g. it could send a pre-recorded prompt that uses stereo), but it 588 indicates to the receiver that the received signal can be safely downmixed to mono. 589 This parameter is useful to avoid wasting receiver resources by operating the audio 590 processing pipeline (e.g. echo cancellation) in stereo when not necessary. 591 If no value is specified, the default is 0 592 (mono).<vspace blankLines='1'/> 593 </t> 594 595 <t hangText="cbr:"> 596 specifies if the decoder prefers the use of a constant bitrate versus 597 variable bitrate. Possible values are 1 and 0, where 1 specifies constant 598 bitrate and 0 specifies variable bitrate. If no value is specified, 599 the default is 0 (vbr). When cbr is 1, the maximum average bitrate can still 600 change, e.g. to adapt to changing network conditions.<vspace blankLines='1'/> 601 </t> 602 603 <t hangText="useinbandfec:"> specifies that the decoder has the capability to 604 take advantage of the Opus in-band FEC. Possible values are 1 and 0. 605 Providing 0 when FEC cannot be used on the receiving side is 606 RECOMMENDED. If no 607 value is specified, useinbandfec is assumed to be 0. 608 This parameter is only a preference and the receiver MUST be able to process 609 packets that include FEC information, even if it means the FEC part is discarded. 610 <vspace blankLines='1'/></t> 611 612 <t hangText="usedtx:"> specifies if the decoder prefers the use of 613 DTX. Possible values are 1 and 0. If no value is specified, the 614 default is 0.<vspace blankLines='1'/></t> 615 </list></t> 616 617 <t>Encoding considerations:<vspace blankLines='1'/></t> 618 <t><list style="hanging"> 619 <t>The Opus media type is framed and consists of binary data according 620 to Section 4.8 in <xref target="RFC6838"/>.</t> 621 </list></t> 622 623 <t>Security considerations: </t> 624 <t><list style="hanging"> 625 <t>See <xref target='security-considerations'/> of this document.</t> 626 </list></t> 627 628 <t>Interoperability considerations: none<vspace blankLines='1'/></t> 629 <t>Published specification: RFC [XXXX]</t> 630 <t>Note to the RFC Editor: Replace [XXXX] with the number of the published 631 RFC.<vspace blankLines='1'/></t> 632 633 <t>Applications that use this media type: </t> 634 <t><list style="hanging"> 635 <t>Any application that requires the transport of 636 speech or audio data can use this media type. Some examples are, 637 but not limited to, audio and video conferencing, Voice over IP, 638 media streaming.</t> 639 </list></t> 640 641 <t>Fragment identifier considerations: N/A<vspace blankLines='1'/></t> 642 643 <t>Person & email address to contact for further information:</t> 644 <t><list style="hanging"> 645 <t>SILK Support silksupport (a] skype.net</t> 646 <t>Jean-Marc Valin jmvalin (a] jmvalin.ca</t> 647 </list></t> 648 649 <t>Intended usage: COMMON<vspace blankLines='1'/></t> 650 651 <t>Restrictions on usage:<vspace blankLines='1'/></t> 652 653 <t><list style="hanging"> 654 <t>For transfer over RTP, the RTP payload format (<xref 655 target='opus-rtp-payload-format'/> of this document) SHALL be 656 used.</t> 657 </list></t> 658 659 <t>Author:</t> 660 <t><list style="hanging"> 661 <t>Julian Spittka jspittka (a] gmail.com<vspace blankLines='1'/></t> 662 <t>Koen Vos koenvos74 (a] gmail.com<vspace blankLines='1'/></t> 663 <t>Jean-Marc Valin jmvalin (a] jmvalin.ca<vspace blankLines='1'/></t> 664 </list></t> 665 666 <t> Change controller: IETF Payload Working Group delegated from the IESG</t> 667 </section> 668 </section> 669 670 <section title='SDP Considerations'> 671 <t>The information described in the media type specification has a 672 specific mapping to fields in the Session Description Protocol (SDP) 673 <xref target="RFC4566"/>, which is commonly used to describe RTP 674 sessions. When SDP is used to specify sessions employing Opus, 675 the mapping is as follows:</t> 676 677 <t> 678 <list style="symbols"> 679 <t>The media type ("audio") goes in SDP "m=" as the media name.</t> 680 681 <t>The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding 682 name. The RTP clock rate in "a=rtpmap" MUST be 48000 and the number of 683 channels MUST be 2.</t> 684 685 <t>The OPTIONAL media type parameters "ptime" and "maxptime" are 686 mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the 687 SDP.</t> 688 689 <t>The OPTIONAL media type parameters "maxaveragebitrate", 690 "maxplaybackrate", "stereo", "cbr", "useinbandfec", and 691 "usedtx", when present, MUST be included in the "a=fmtp" attribute 692 in the SDP, expressed as a media type string in the form of a 693 semicolon-separated list of parameter=value pairs (e.g., 694 maxplaybackrate=48000). They MUST NOT be specified in an 695 SSRC-specific "fmtp" source-level attribute (as defined in 696 Section 6.3 of <xref target="RFC5576"/>).</t> 697 698 <t>The OPTIONAL media type parameters "sprop-maxcapturerate", 699 and "sprop-stereo" MAY be mapped to the "a=fmtp" SDP attribute by 700 copying them directly from the media type parameter string as part 701 of the semicolon-separated list of parameter=value pairs (e.g., 702 sprop-stereo=1). These same OPTIONAL media type parameters MAY also 703 be specified using an SSRC-specific "fmtp" source-level attribute 704 as described in Section 6.3 of <xref target="RFC5576"/>. 705 They MAY be specified in both places, in which case the parameter 706 in the source-level attribute overrides the one found on the 707 "a=fmtp" line. The value of any parameter which is not specified in 708 a source-level source attribute MUST be taken from the "a=fmtp" 709 line, if it is present there.</t> 710 711 </list> 712 </t> 713 714 <t>Below are some examples of SDP session descriptions for Opus:</t> 715 716 <t>Example 1: Standard mono session with 48000 Hz clock rate</t> 717 <figure> 718 <artwork> 719 <![CDATA[ 720 m=audio 54312 RTP/AVP 101 721 a=rtpmap:101 opus/48000/2 722 ]]> 723 </artwork> 724 </figure> 725 726 727 <t>Example 2: 16000 Hz clock rate, maximum packet size of 40 ms, 728 recommended packet size of 40 ms, maximum average bitrate of 20000 bps, 729 prefers to receive stereo but only plans to send mono, FEC is desired, 730 DTX is not desired</t> 731 732 <figure> 733 <artwork> 734 <![CDATA[ 735 m=audio 54312 RTP/AVP 101 736 a=rtpmap:101 opus/48000/2 737 a=fmtp:101 maxplaybackrate=16000; sprop-maxcapturerate=16000; 738 maxaveragebitrate=20000; stereo=1; useinbandfec=1; usedtx=0 739 a=ptime:40 740 a=maxptime:40 741 ]]> 742 </artwork> 743 </figure> 744 745 <t>Example 3: Two-way full-band stereo preferred</t> 746 747 <figure> 748 <artwork> 749 <![CDATA[ 750 m=audio 54312 RTP/AVP 101 751 a=rtpmap:101 opus/48000/2 752 a=fmtp:101 stereo=1; sprop-stereo=1 753 ]]> 754 </artwork> 755 </figure> 756 757 758 <section title='SDP Offer/Answer Considerations'> 759 760 <t>When using the offer-answer procedure described in <xref 761 target="RFC3264"/> to negotiate the use of Opus, the following 762 considerations apply:</t> 763 764 <t><list style="symbols"> 765 766 <t>Opus supports several clock rates. For signaling purposes only 767 the highest, i.e. 48000, is used. The actual clock rate of the 768 corresponding media is signaled inside the payload and is not 769 restricted by this payload format description. The decoder MUST be 770 capable of decoding every received clock rate. An example 771 is shown below: 772 773 <figure> 774 <artwork> 775 <![CDATA[ 776 m=audio 54312 RTP/AVP 100 777 a=rtpmap:100 opus/48000/2 778 ]]> 779 </artwork> 780 </figure> 781 </t> 782 783 <t>The "ptime" and "maxptime" parameters are unidirectional 784 receive-only parameters and typically will not compromise 785 interoperability; however, some values might cause application 786 performance to suffer. <xref 787 target="RFC3264"/> defines the SDP offer-answer handling of the 788 "ptime" parameter. The "maxptime" parameter MUST be handled in the 789 same way.</t> 790 791 <t> 792 The "maxplaybackrate" parameter is a unidirectional receive-only 793 parameter that reflects limitations of the local receiver. When 794 sending to a single destination, a sender MUST NOT use an audio 795 bandwidth higher than necessary to make full use of audio sampled at 796 a sampling rate of "maxplaybackrate". Gateways or senders that 797 are sending the same encoded audio to multiple destinations 798 SHOULD NOT use an audio bandwidth higher than necessary to 799 represent audio sampled at "maxplaybackrate", as this would lead 800 to inefficient use of network resources. 801 The "maxplaybackrate" parameter does not 802 affect interoperability. Also, this parameter SHOULD NOT be used 803 to adjust the audio bandwidth as a function of the bitrate, as this 804 is the responsibility of the Opus encoder implementation. 805 </t> 806 807 <t>The "maxaveragebitrate" parameter is a unidirectional receive-only 808 parameter that reflects limitations of the local receiver. The sender 809 of the other side MUST NOT send with an average bitrate higher than 810 "maxaveragebitrate" as it might overload the network and/or 811 receiver. The "maxaveragebitrate" parameter typically will not 812 compromise interoperability; however, some values might cause 813 application performance to suffer, and ought to be set with 814 care.</t> 815 816 <t>The "sprop-maxcapturerate" and "sprop-stereo" parameters are 817 unidirectional sender-only parameters that reflect limitations of 818 the sender side. 819 They allow the receiver to set up a reduced-complexity audio 820 processing pipeline if the sender is not planning to use the full 821 range of Opus's capabilities. 822 Neither "sprop-maxcapturerate" nor "sprop-stereo" affect 823 interoperability and the receiver MUST be capable of receiving any signal. 824 </t> 825 826 <t> 827 The "stereo" parameter is a unidirectional receive-only 828 parameter. When sending to a single destination, a sender MUST 829 NOT use stereo when "stereo" is 0. Gateways or senders that are 830 sending the same encoded audio to multiple destinations SHOULD 831 NOT use stereo when "stereo" is 0, as this would lead to 832 inefficient use of network resources. The "stereo" parameter does 833 not affect interoperability. 834 </t> 835 836 <t> 837 The "cbr" parameter is a unidirectional receive-only 838 parameter. 839 </t> 840 841 <t>The "useinbandfec" parameter is a unidirectional receive-only 842 parameter.</t> 843 844 <t>The "usedtx" parameter is a unidirectional receive-only 845 parameter.</t> 846 847 <t>Any unknown parameter in an offer MUST be ignored by the receiver 848 and MUST be removed from the answer.</t> 849 850 </list></t> 851 852 <t> 853 The Opus parameters in an SDP Offer/Answer exchange are completely 854 orthogonal, and there is no relationship between the SDP Offer and 855 the Answer. 856 </t> 857 </section> 858 859 <section title='Declarative SDP Considerations for Opus'> 860 861 <t>For declarative use of SDP such as in Session Announcement Protocol 862 (SAP), <xref target="RFC2974"/>, and RTSP, <xref target="RFC2326"/>, for 863 Opus, the following needs to be considered:</t> 864 865 <t><list style="symbols"> 866 867 <t>The values for "maxptime", "ptime", "maxplaybackrate", and 868 "maxaveragebitrate" ought to be selected carefully to ensure that a 869 reasonable performance can be achieved for the participants of a session.</t> 870 871 <t> 872 The values for "maxptime", "ptime", and of the payload 873 format configuration are recommendations by the decoding side to ensure 874 the best performance for the decoder. 875 </t> 876 877 <t>All other parameters of the payload format configuration are declarative 878 and a participant MUST use the configurations that are provided for 879 the session. More than one configuration can be provided if necessary 880 by declaring multiple RTP payload types; however, the number of types 881 ought to be kept small.</t> 882 </list></t> 883 </section> 884 </section> 885 886 <section title='Security Considerations' anchor='security-considerations'> 887 888 <t>Use of variable bitrate (VBR) is subject to the security considerations in 889 <xref target="RFC6562"/>.</t> 890 891 <t>RTP packets using the payload format defined in this specification 892 are subject to the security considerations discussed in the RTP 893 specification <xref target="RFC3550"/>, and in any applicable RTP profile such as 894 RTP/AVP <xref target="RFC3551"/>, RTP/AVPF <xref target="RFC4585"/>, 895 RTP/SAVP <xref target="RFC3711"/> or RTP/SAVPF <xref target="RFC5124"/>. 896 However, as "Securing the RTP Protocol Framework: 897 Why RTP Does Not Mandate a Single Media Security Solution" 898 <xref target="RFC7202"/> discusses, it is not an RTP payload 899 format's responsibility to discuss or mandate what solutions are used 900 to meet the basic security goals like confidentiality, integrity and 901 source authenticity for RTP in general. This responsibility lays on 902 anyone using RTP in an application. They can find guidance on 903 available security mechanisms and important considerations in Options 904 for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. 905 Applications SHOULD use one or more appropriate strong security 906 mechanisms.</t> 907 908 <t>This payload format and the Opus encoding do not exhibit any 909 significant non-uniformity in the receiver-end computational load and thus 910 are unlikely to pose a denial-of-service threat due to the receipt of 911 pathological datagrams.</t> 912 </section> 913 914 <section title='Acknowledgements'> 915 <t>Many people have made useful comments and suggestions contributing to this document. 916 In particular, we would like to thank 917 Tina le Grand, Cullen Jennings, Jonathan Lennox, Gregory Maxwell, Colin Perkins, Jan Skoglund, 918 Timothy B. Terriberry, Martin Thompson, Justin Uberti, Magnus Westerlund, and Mo Zanaty.</t> 919 </section> 920 </middle> 921 922 <back> 923 <references title="Normative References"> 924 &rfc2119; 925 &rfc3389; 926 &rfc3550; 927 &rfc3711; 928 &rfc3551; 929 &rfc6838; 930 &rfc4855; 931 &rfc4566; 932 &rfc3264; 933 &rfc2326; 934 &rfc5576; 935 &rfc6562; 936 &rfc6716; 937 </references> 938 939 <references title="Informative References"> 940 &rfc2974; 941 &rfc4585; 942 &rfc5124; 943 &rfc5405; 944 &rfc7202; 945 946 <reference anchor='rmcat' target='https://datatracker.ietf.org/wg/rmcat/documents/'> 947 <front> 948 <title>rmcat documents</title> 949 <author/> 950 <date/> 951 <abstract> 952 <t></t> 953 </abstract></front> 954 </reference> 955 956 957 </references> 958 959 </back> 960 </rfc> 961
