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