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