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