Subject: [payload] Review of draft-ietf-payload-rtp-opus-02

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 28 Jul 2014 09:02:13 -0700

I have reviewed draft-itef-payload-rtp-opus-02. After the issues below 
are addressed, I think this draft is ready for WGLC.

The following suggestions/corrections are not meant to change the 
meaning of any text, merely clarify or improve the wording.

Abstract:

"that is essential to" -> "necessary to" (fewer words is better)

"Further, media type registrations are described" -> "Further, it 
describes media type registrations" (remove passive voice)

1. Introduction

" (codec)" -> "" (this WG is never referred to again, so defining the 
short name is unnecessary)

"thus, making" -> "thus making"

The same suggestions made for the abstract also apply to the text from 
it that is repeated here.

2. Conventions, Definitions and Acronyms used in this document

"usually " -> "" (the term is used a total of 3 times in the document, 
all in the same paragraph, which also makes it clear that it means "per 
channel"... no reason to suggest to the reader that it might be 
ambiguous here)

2.1 Audio Bandwidth

"Bandwidth" -> "Audio Bandwidth (Hz)"

"Sampling" -> "Sampling Rate (Hz)"

Although the section is called "Audio Bandwidth", there's no reason not 
to give units in these column headers to make it clear we're not talking 
about network bandwidth (bits per second).

The abbreviations should also probably be capitalized (the document uses 
capitalization for these abbreviations inconsistently, but I think the 
capitalized version should be preferred).

3. Opus Codec

The first couple of sentences use "speech and audio" quite a few times, 
but never distinguish how "speech" is not also "audio". Suggest 
replacing them with the following text:

     The Opus [RFC6716] codec encodes speech signals as well as general
     audio signals.  Two different modes can be chosen, a voice mode or an
     audio mode, to allow the most efficient coding depending on the type
     of the input signal, the sampling frequency of the input signal, and
     the intended application.

The next sentence should also say "general audio signals" instead of 
just "audio signals".

3.1 Network Bandwidth

"a higher bitrate results in higher quality" -> "higher bitrates result 
in higher quality"

3.1.2 Variable versus Constant Bit Rate

"Bit Rate" -> "Bitrate" (for consistency with the rest of the document)

"application" -> "applications"

"One potential reason ... is the potential..." -> "One reason ... is the 
potential..."

"_may_" -> "_might_"

The document uses "may", "should", and "required" in a number of 
non-2119 contexts. These should all be changed to "might"/"can", "ought 
to", and "needed"/"necessary" as appropriate.

3.1.3 Discontinuous Transmission (DTX)

"may" -> "can"

"an adaptive bitrate" -> "a variable bitrate" (the referenced section 
describes "variable bitrate", but never defines "adaptive bitrate")

"In that case, the bitrate will automatically be reduced for certain 
input signals like periods of silence.  During continuous transmission 
the bitrate will be reduced, when the input signal allows to do so, but 
the transmission to the receiver itself will never be interrupted." -> 
"In that case, the encoder will automatically reduce the bitrate for 
certain input signals, like periods of silence.  When using continuous 
transmission, it will reduce the bitrate when the characteristics of the 
input signal permit, but will never interrupt the transmission to the 
receiver." (remove passive voice and the ungrammatical "allows to do 
so"; also change "During" to "When using" to clarify that this is a choice)

"may be set to" -> "can"

The last paragraph in the section should also remove references to a DTX 
"mode", to avoid ambiguity with the speech mode or audio mode. RFC 6716 
is very careful to define a "mode" of operation as only the choice of 
SILK or CELT, and refer to other parameter choices as a "configuration", 
to avoid making the word "mode" ambiguous. This document should take the 
same care. It should also move the last sentence of this paragraph to 
the front, so that the conclusion is last (and replace "adaptive" with 
"variable" again, for consistency). Proposed alternative text:

     DTX can be used with both variable and constant bitrate.  It will
     have a slightly lower speech or audio quality than continuous
     transmission.  Therefore, using continuous transmission is
     RECOMMENDED unless restraints on network capacity are severe.

3.3 Forward Error Correction (FEC)

"allows for "in-band" forward error correction data to be embedded" -> 
"allows for embedding "in-band" forward error correction data" (remove 
passive voice)

"the bit stream of Opus" -> "the Opus bit stream"

"(n-1)" -> "(N-1)"

"n" -> "N"

"when, in case of a packet loss, the next packet is available" -> "when 
it loses a packet and the next packet is available" (remove 
ungrammatical use of "in case of")

"will consider ... and invokes the frame loss concealment." -> "will 
consider ... and invoke frame loss concealment." (avoid tense change and 
remove an inappropriate article)

3.4 Stereo Operation

"required" -> "needed"

"usage of the network" -> "usage of network resources" (for consistency 
with the wording in Section 3.3)

4.1 RTP Header Usage

"The Opus payload format uses the fields of the RTP header consistent 
with this specification." -> "The use of the fields of the RTP header by 
the Opus payload format is consistent with that specification." (avoid 
awkward use of the adverb "consistently", which would be required to 
make the original sentence correct; also "this specification" would be 
the current draft, use "that specification" to refer to RFC3550)

"is a multiple number of octets" -> "is an integer number of octets"

"required" -> "necessary"

"duplicates of RTP packets" -> "duplicate RTP packets"

"Only one of those payloads MUST be provided to the Opus decoder for 
decoding and others MUST be discarded." -> "The receiver MUST provide 
only one of those payloads to the Opus decoder for decoding, and MUST 
discard the others." (remove passive voice, particularly in a sentence 
that places normative requirements on an actor without naming that actor)

"bandwidths which may" -> "bandwidths, which can" (the clause is 
non-restrictive, and non-normative)

The language in this paragraph should also be made consistent with the 
language in Section 6.1 (when describing the rate: parameter). Proposed 
text:

     Opus supports 5 different audio bandwidths, which can be adjusted
     during a call.  The RTP timestamp is incremented with a 48000 Hz
     clock rate for all modes of Opus and all sampling rates.  The unit
     for the timestamp is samples per single (mono) channel.  The RTP
     timestamp corresponds to the sample time of the first encoded sample
     in the encoded frame.  For data encoded with sampling rates other
     than 48000 Hz, the sampling rate has to be adjusted to 48000 Hz using
     the corresponding multiplier in Table 2.

"fs" -> "Sampling Rate" (fs is not yet a defined term; recommend 
"Sampling Rate" for consistency with the text and with Table 1)

4.2 Payload Structure

"can be set to" -> "can"

"...combined into a packet. The maximum packet length is limited to the 
amount of encoded data representing 120 ms of speech or audi odata." -> 
"...combined into a packet, up to a maximum packet duration representing 
120 ms of speech or audio data." (keeping these in the same sentence 
prevents a reader from stopping at the end of the first sentence and not 
realizing the next imposes an additional restriction; also, replace 
"length" with the less ambiguous "duration", to be clear we're not 
talking about a restriction on the number of bytes)

"... encoder and therefore only one packet output from the Opus encoder 
MUST be used as a payload" -> "...encoder, and therefore an RTP payload 
MUST contain exactly one packet output from the Opus encoder." (remove 
passive voice from normative requirements; a change in subject requires 
a comma before "and")

Figure 1 should be centered instead of left-justified.

"and how" -> "and shows how" (repeat the verb to provide a better 
indication what clause the "and" here applies to)

"the timestamps have to be added up according to the combined frames" -> 
"the timestamp increment is the sum of the increments for the individual 
frames" (we aren't adding timestamps, and "according to" is ambiguous)

nb, mb, etc. in Table 3 should be capitalized.

5. Congestion Control

"The adaptive nature of the Opus codec allows for an efficient 
congestion control." -> "" (this is redundant with the sentence right 
after it)

"time and thus" -> "time, thus"

"allowing for an efficient" -> "allowing efficient"

"control since" -> "control, since" (unrestrictive clause)

"these frame sizes" -> "the packet duration" (the previous part of the 
sentence talks about a packet, not frames)

"overhead but" -> "overhead, but"

"error sensitivity" -> "loss sensitivity" (let's be clear about the kind 
of errors we're worried about)

"sensitivity and should be done" -> "sensitivity, so it ought to be 
used" (non-normative should; also, it is not clear how to "do" a lower 
packet transmission rate)

"It is RECOMMENDED that congestion control is applied during the 
transmission of Opus encoded data." -> "It is RECOMMENDED that senders 
of Opus encoded data apply congestion control." (remove passive voice 
from normative requirements)

6.1 Opus Media Type Registration

"RTP timestamp clock rate" -> "the RTP timestamp" (clock rate appears 
redundantly elsewhere in the same sentence; missing article)

"with 48000 Hz clock rate" -> "with a 48000 Hz clock rate" (missing article)

"sampling frequencies" -> "sampling rates" (for consistency with the 
rest of the document)

"For audio sampling rates other than 48000 Hz the rate has to be 
adjusted to 48000 Hz according to Table 2." -> "For data encoded with 
sampling rates other than 48000 Hz, the sampling rate has to be adjusted 
to 48000 Hz using the corresponding multiplier in Table 2." (for 
consistency with proposed text in Section 4.1)

"the decoder's maximum length of time in milliseconds rounded up to the 
next full integer value represented by the media in a packet that can be 
encapsulated in a received packet according to Section 6 of RFC4566."

This is quite the mouthful, and it is quite ambiguous which clauses 
refer to which (especially the reference to RFC4566). It is also phrased 
as an absolute requirement, when several sentences later the document 
clearly states it is not one. How about

"the maximum duration of media represented by a packet (according to 
Section 6 of RFC4566) that a decoder wants to receive, in milliseconds 
rounded up to the next full integer value."

I am inferring here that RFC4566 is being invoked solely to define the 
duration of a packet, since the same phrase appears in the definition of 
minptime, which is not defined by RFC4566.

"...40, and 60 or an arbitrary multiple of Opus frame sizes rounded up 
to the next full integer value up to a maximum value of 120 as 
defined..." -> "...40, 50, or an arbitrary multiple of an Opus frame 
size rounded up to the next full integer value, up to a maximum of 120, 
as defined..." (both using and omitting a serial comma in the same 
sentence; it is unclear what "a" multiple of several "frame sizes" might 
be... in practice it must be a multiple of _one_ frame size, though 
since all frame sizes are themselves a multiple of a 2.5 ms frame size, 
this does not impose any additional restrictions; also added some 
missing commas)

"120 is assumed as default" -> "the default is 120" (no reason not to be 
direct)

The corresponding text for ptime and minptime should be changed in the 
same ways.

"may vary as it" -> "can vary, as it" (non-nomrative may, 
non-restrictive clause)

"allowed but" -> "allowed, but"

"range between 6000 and 510000" -> "range 6000 to 510000" (I assume this 
was meant to be inclusive)

"maxplaybackrate:" -> "maxplaybackrate"

"will be the default" -> 'is the default"

"utilisation" -> "utilization" (for consistency with the American 
spelling in the rest of the document)

"mono is assumed (stereo=0)" -> "the default is 0 (mono)"

"1 and 0 where" -> "1 and 0, where"

"preferred and 0 specifies" -> "preferred, and 0 specifies" (comma for 
new subject)

"mono is assumed (sprop-stereo=0)" -> "the default is 0 (mono)"

"1 and 0 where" -> "1 and 0, where"

"bitrate and 0 specifies" -> "bitrate, and 0 specifies" (comma for new 
subject)

"cbr is assumed to be 0" -> "the default is 0 (vbr)"

"Note that the maximum average bitrate may still be changed..." -> "When 
cbr is 1, the maximum average bitrate can still change..." (the phrase 
"Note that" is always superfluous; this is only surprising when cbr is 
enabled, so let's call out that case; also, remove the non-normative may).

"It is RECOMMENDED to provide 0 in case FEC cannot be utilized..." -> 
"Providing 0 when FEC cannot be used... is RECOMMENDED." (less awkward 
phrasing; "used" is always preferable to "utilized")

"usedtx is assumed to be 0" -> "the default is 0"

"Opus media type is..." -> "The Opus media type is..."

"may use this media type" -> "can use this media type"

6.2.1 Offer-Answer Model Considerations for Opus

"is not subject to this payload format description" -> "is not 
restricted by this payload format description" (it is unclear what 
"subject to" actually means)

"capable to decode" -> "capable of decoding"

"dependent on the set values of the parameters the performance of the 
application may suffer" -> "some values might cause application 
performance to suffer" (non-normative may, indirect phrasing)

"and should be set with care" -> "and ought to be used with care" 
(non-normative should; subject-verb disagreement)

"as a function of the bitrates" -> "as a function of the bitrate"

6.2.2 Declarative SDP Considerations for Opus

"should be selected" -> "ought to be selected" (non-normative should)

"capable to accept" -> "capable of accepting"

"may be provided" -> "can be provided" (non-normative may)

"should be kept small" -> "ought to be kept small" (non-normative should)

7. Security Considerations

"from e.g., RFC3711" -> "from, e.g., RFC3711"

"audio data, hence, ..." -> "audio data. Hence, ..."

I have a few more proposals that do change the meaning of the text:

3.1.2 Variable versus Constant Bitrate

"the average bitrate SHOULD be adjusted to the available network 
capacity" -> "the average bitrate SHOULD NOT exceed the available 
network capacity"

We shouldn't encourage people to fill up the pipe just because it's 
available.

3.3 Forward Error Correction (FEC)

This section talks about "the decoder API", which presupposes a specific 
implementation of Opus. There's no reason not to be 
implementation-independent here. Proposed text:

"The decoder API function has a flag to indicate that a FEC frame rather 
than a regular frame should be decoded." -> "The receiver can then 
configure its decoder to decode the FEC data from the packet rather than 
the regular audio data."

4.2 Payload Structure

The current encoder API has limited support for creating packets 
containing multiple frames, and a separate repacketizer API is provided 
to construct such multi-frame packets. The current text suggests the 
latter is forbidden, but I don't believe that's the intent. Proposed text:

"The packetization of encoded data is purely done by the Opus encoder, 
and therefore an RTP payload MUST contain exactly one packet output from 
the Opus encoder." -> "The grouping of one or more Opus frames into a 
single Opus packet is defined in Section 3 of RFC6716. An RTP payload 
MUST contain exactly one Opus packet as defined by that document."

6.2.1 Offer-Answer Model Considerations for Opus

Based on off-list feedback I got recently, I propose the following text 
for maxplaybackrate:

    o  The "maxplaybackrate" parameter is a unidirectional receive-only
       parameter that reflects limitations of the local receiver.  When
       sending to a single destination, a sender MUST NOT use an audio
       bandwidth higher than necessary to represent audio sampled at a
       sampling rate of "maxplaybackrate".  Gateways or senders that are
       sending the same encoded audio to multiple destinations SHOULD NOT
       use an audio bandwidth higher than necessary to represent audio
       sampled at "maxplaybackrate", as this would lead to inefficient
       use of network resources.  The "maxplaybackrate" parameter does
       not affect interoperability.  Also, this parameter SHOULD NOT be
       used to adjust the audio bandwidth as a function of the bitrate,
       as this is the responsibility of the Opus encoder implementation.

The change from "an audio bandwidth higher than 'maxplaybackrate'" to 
"an audio bandwidth higher than necessary to represent audio sampled at 
a sampling rate of 'maxplaybackrate'" was done to handle the fact that 
maxplaybackrate is a sampling rate, which is typically at least twice 
the value of the corresponding audio bandwidth, and to handle the case 
where maxplaybackrate does not correspond exactly to one of the sampling 
rates supported by Opus (e.g., fully representing audio sampled at 32 
kHz would require using Opus in a fullband configuration... given 
typical rate allocations of the encoder, the waste from using 48 kHz 
instead of 32 kHz would only be a handful of bits per frame).

Similarly, for stereo:

    o  The "stereo" parameter is a unidirectional receive-only parameter.
       When sending to a single destination, a sender MUST NOT use stereo
       when "stereo" is 0.  Gateways or senders that are sending the same
       encoded audio to multiple destinations SHOULD NOT use stereo when
       "stereo" is 0, as this would lead to inefficient use of network
       resources.  The "stereo" parameter does not affect
       interoperability.

I think this strikes the right balance between giving receivers the 
leverage they need to keep senders from wasting their network resources 
while allowing gateways to avoid transcoding. If others have advice to 
implementers on how to handle multiparty situations (e.g., a 3-way mesh 
call where someone joins from the PSTN), feel free to propose text on 
the list.

I've attached git patches for both sets of changes.
>From 2ce26299b264a5a190bae21fd59e5f51f37d8b3d Mon Sep 17 00:00:00 2001
From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 25 Jul 2014 21:45:46 -0700
Subject: [PATCH 1/2] RTP draft edits (no normative changes).

This is the result of an editing pass for clarity and consistency.
---
 doc/draft-ietf-payload-rtp-opus.xml | 396 ++++++++++++++++++------------------
 1 file changed, 198 insertions(+), 198 deletions(-)

diff --git a/doc/draft-ietf-payload-rtp-opus.xml b/doc/draft-ietf-payload-rtp-opus.xml
index 89a980c..afa7284 100644
--- a/doc/draft-ietf-payload-rtp-opus.xml
+++ b/doc/draft-ietf-payload-rtp-opus.xml
@@ -71,203 +71,203 @@
     </author>
 
     <date day='14' month='January' year='2014' />
 
     <abstract>
       <t>
         This document defines the Real-time Transport Protocol (RTP) payload
         format for packetization of Opus encoded
-        speech and audio data that is essential to integrate the codec in the
-        most compatible way. Further, media type registrations
-        are described for the RTP payload format.
+        speech and audio data necessary to integrate the codec in the
+        most compatible way. Further, it describes media type registrations
+        for the RTP payload format.
       </t>
     </abstract>
   </front>
 
   <middle>
     <section title='Introduction'>
       <t>
         The Opus codec is a speech and audio codec developed within the
-        IETF Internet Wideband Audio Codec working group (codec). The codec
+        IETF Internet Wideband Audio Codec working group. The codec
         has a very low algorithmic delay and it
         is highly scalable in terms of audio bandwidth, bitrate, and
         complexity. Further, it provides different modes to efficiently encode speech signals
-        as well as music signals, thus, making it the codec of choice for
+        as well as music signals, thus making it the codec of choice for
         various applications using the Internet or similar networks.
       </t>
       <t>
         This document defines the Real-time Transport Protocol (RTP)
         <xref target="RFC3550"/> payload format for packetization
-        of Opus encoded speech and audio data that is essential to
+        of Opus encoded speech and audio data necessary to
         integrate the Opus codec in the
-        most compatible way. Further, media type registrations are described for
+        most compatible way. Further, it describes media type registrations for
         the RTP payload format. More information on the Opus
         codec can be obtained from <xref target="RFC6716"/>.
       </t>
     </section>
 
     <section title='Conventions, Definitions and Acronyms used in this document'>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119"/>.</t>
       <t>
       <list style='hanging'>
           <t hangText="CBR:"> Constant bitrate</t>
           <t hangText="CPU:"> Central Processing Unit</t>
           <t hangText="DTX:"> Discontinuous transmission</t>
           <t hangText="FEC:"> Forward error correction</t>
-	      <t hangText="IP:"> Internet Protocol</t>
-	      <t hangText="samples:"> Speech or audio samples (usually per channel)</t>
-	      <t hangText="SDP:"> Session Description Protocol</t>
+          <t hangText="IP:"> Internet Protocol</t>
+          <t hangText="samples:"> Speech or audio samples (per channel)</t>
+          <t hangText="SDP:"> Session Description Protocol</t>
           <t hangText="VBR:"> Variable bitrate</t>
       </list>
       </t>
       <section title='Audio Bandwidth'>
-	<t>
-	  Throughout this document, we refer to the following definitions:
-	</t>
+        <t>
+          Throughout this document, we refer to the following definitions:
+        </t>
           <texttable anchor='bandwidth_definitions'>
-	    <ttcol align='center'>Abbreviation</ttcol>
+            <ttcol align='center'>Abbreviation</ttcol>
             <ttcol align='center'>Name</ttcol>
-            <ttcol align='center'>Bandwidth</ttcol>
-            <ttcol align='center'>Sampling</ttcol>
-            <c>nb</c>
+            <ttcol align='center'>Audio Bandwidth (Hz)</ttcol>
+            <ttcol align='center'>Sampling Rate (Hz)</ttcol>
+            <c>NB</c>
             <c>Narrowband</c>
             <c>0 - 4000</c>
             <c>8000</c>
 
-            <c>mb</c>
+            <c>MB</c>
             <c>Mediumband</c>
             <c>0 - 6000</c>
             <c>12000</c>
 
-            <c>wb</c>
+            <c>WB</c>
             <c>Wideband</c>
             <c>0 - 8000</c>
             <c>16000</c>
 
-            <c>swb</c>
+            <c>SWB</c>
             <c>Super-wideband</c>
             <c>0 - 12000</c>
             <c>24000</c>
 
-            <c>fb</c>
+            <c>FB</c>
             <c>Fullband</c>
             <c>0 - 20000</c>
             <c>48000</c>
 
             <postamble>
               Audio bandwidth naming
             </postamble>
           </texttable>
       </section>
     </section>
 
     <section title='Opus Codec'>
       <t>
-        The Opus <xref target="RFC6716"/> speech and audio codec has been developed to encode speech
-        signals as well as audio signals. Two different modes, a voice mode
-        or an audio mode, may be chosen to allow the most efficient coding
-        dependent on the type of input signal, the sampling frequency of the
-        input signal, and the specific application.
+        The Opus <xref target="RFC6716"/> codec encodes speech
+        signals as well as general audio signals. Two different modes can be
+        chosen, a voice mode or an audio mode, to allow the most efficient coding
+        depending on the type of the input signal, the sampling frequency of the
+        input signal, and the intended application.
       </t>
 
       <t>
         The voice mode allows efficient encoding of voice signals at lower bit
-        rates while the audio mode is optimized for audio signals at medium and
+        rates while the audio mode is optimized for general audio signals at medium and
         higher bitrates.
       </t>
 
       <t>
         The Opus speech and audio codec is highly scalable in terms of audio
         bandwidth, bitrate, and complexity. Further, Opus allows
         transmitting stereo signals.
       </t>
 
       <section title='Network Bandwidth'>
           <t>
-	    Opus supports all bitrates from 6&nbsp;kb/s to 510&nbsp;kb/s.
-	    The bitrate can be changed dynamically within that range.
-	    All
-	    other parameters being
-	    equal, higher bitrate results in higher quality.
-	  </t>
-	  <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'>
-	  <t>
-	    For a frame size of
-	    20&nbsp;ms, these
-	    are the bitrate "sweet spots" for Opus in various configurations:
+            Opus supports all bitrates from 6&nbsp;kb/s to 510&nbsp;kb/s.
+            The bitrate can be changed dynamically within that range.
+            All
+            other parameters being
+            equal, higher bitrates result in higher quality.
+          </t>
+          <section title='Recommended Bitrate' anchor='bitrate_by_bandwidth'>
+          <t>
+            For a frame size of
+            20&nbsp;ms, these
+            are the bitrate "sweet spots" for Opus in various configurations:
 
           <list style="symbols">
-	    <t>8-12 kb/s for NB speech,</t>
-	    <t>16-20 kb/s for WB speech,</t>
-	    <t>28-40 kb/s for FB speech,</t>
-	    <t>48-64 kb/s for FB mono music, and</t>
-	    <t>64-128 kb/s for FB stereo music.</t>
-	  </list>
-	</t>
+            <t>8-12 kb/s for NB speech,</t>
+            <t>16-20 kb/s for WB speech,</t>
+            <t>28-40 kb/s for FB speech,</t>
+            <t>48-64 kb/s for FB mono music, and</t>
+            <t>64-128 kb/s for FB stereo music.</t>
+          </list>
+        </t>
       </section>
-        <section title='Variable versus Constant Bit Rate'  anchor='variable-vs-constant-bitrate'>
+        <section title='Variable versus Constant Bitrate'  anchor='variable-vs-constant-bitrate'>
+          <t>
+            For the same average bitrate, variable bitrate (VBR) can achieve higher quality
+            than constant bitrate (CBR). For the majority of voice transmission applications, VBR
+            is the best choice. One reason for choosing CBR is the potential
+            information leak that <spanx style='emph'>might</spanx> occur when encrypting the
+            compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is
+            appropriate for encrypted audio communications. In the case where an existing
+            VBR stream needs to be converted to CBR for security reasons, then the Opus padding
+            mechanism described in <xref target="RFC6716"/> is the RECOMMENDED way to achieve padding
+            because the RTP padding bit is unencrypted.</t>
+
           <t>
-	    For the same average bitrate, variable bitrate (VBR) can achieve higher quality
-	    than constant bitrate (CBR). For the majority of voice transmission application, VBR
-	    is the best choice. One potential reason for choosing CBR is the potential
-	    information leak that <spanx style='emph'>may</spanx> occur when encrypting the
-	    compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is
-	    appropriate for encrypted audio communications. In the case where an existing
-	    VBR stream needs to be converted to CBR for security reasons, then the Opus padding
-	    mechanism described in <xref target="RFC6716"/> is the RECOMMENDED way to achieve padding
-	    because the RTP padding bit is unencrypted.</t>
-
-	    <t>
             The bitrate can be adjusted at any point in time. To avoid congestion,
             the average bitrate SHOULD be adjusted to the available
             network capacity. If no target bitrate is specified, the bitrates specified in
             <xref target='bitrate_by_bandwidth'/> are RECOMMENDED.
           </t>
 
         </section>
 
         <section title='Discontinuous Transmission (DTX)'>
 
           <t>
-            The Opus codec may, as described in <xref target='variable-vs-constant-bitrate'/>,
-            be operated with an adaptive bitrate. In that case, the bitrate
-            will automatically be reduced for certain input signals like periods
-            of silence. During continuous transmission the bitrate will be
-            reduced, when the input signal allows to do so, but the transmission
-            to the receiver itself will never be interrupted. Therefore, the
+            The Opus codec can, as described in <xref target='variable-vs-constant-bitrate'/>,
+            be operated with a variable bitrate. In that case, the encoder will
+            automatically reduce the bitrate for certain input signals, like periods
+            of silence. When using continuous transmission, it will reduce the
+            bitrate when the characteristics of the input signal permit, but
+            will never interrupt the transmission to the receiver. Therefore, the
             received signal will maintain the same high level of quality over the
             full duration of a transmission while minimizing the average bit
             rate over time.
           </t>
 
           <t>
             In cases where the bitrate of Opus needs to be reduced even
             further or in cases where only constant bitrate is available,
-            the Opus encoder may be set to use discontinuous
+            the Opus encoder can use discontinuous
             transmission (DTX), where parts of the encoded signal that
             correspond to periods of silence in the input speech or audio signal
             are not transmitted to the receiver.
           </t>
 
           <t>
             On the receiving side, the non-transmitted parts will be handled by a
             frame loss concealment unit in the Opus decoder which generates a
             comfort noise signal to replace the non transmitted parts of the
             speech or audio signal.
           </t>
 
           <t>
-            The DTX mode of Opus will have a slightly lower speech or audio
-            quality than the continuous mode. Therefore, it is RECOMMENDED to
-            use Opus in the continuous mode unless restraints on network
-            capacity are severe. The DTX mode can be engaged for operation
-            in both adaptive or constant bitrate.
+            DTX can be used with both variable and constant bitrate.
+            It will have a slightly lower speech or audio
+            quality than continuous transmission. Therefore, using continuous
+            transmission is RECOMMENDED unless restraints on network capacity
+            are severe.
           </t>
 
         </section>
 
         </section>
 
       <section title='Complexity'>
 
@@ -276,147 +276,148 @@
           a trade-off between audio quality and bitrate. Also, different modes of Opus have different complexity.
         </t>
 
       </section>
 
       <section title="Forward Error Correction (FEC)">
 
         <t>
-          The voice mode of Opus allows for "in-band" forward error correction (FEC)
-          data to be embedded into the bit stream of Opus. This FEC scheme adds
-          redundant information about the previous packet (n-1) to the current
-          output packet n. For
+          The voice mode of Opus allows for embedding "in-band" forward error correction (FEC)
+          data into the Opus bit stream. This FEC scheme adds
+          redundant information about the previous packet (N-1) to the current
+          output packet N. For
           each frame, the encoder decides whether to use FEC based on (1) an
           externally-provided estimate of the channel's packet loss rate; (2) an
           externally-provided estimate of the channel's capacity; (3) the
           sensitivity of the audio or speech signal to packet loss; (4) whether
           the receiving decoder has indicated it can take advantage of "in-band"
           FEC information. The decision to send "in-band" FEC information is
           entirely controlled by the encoder and therefore no special precautions
           for the payload have to be taken.
         </t>
 
         <t>
           On the receiving side, the decoder can take advantage of this
-          additional information when, in case of a packet loss, the next packet
+          additional information when it loses a packet and the next packet
           is available.  In order to use the FEC data, the jitter buffer needs
           to provide access to payloads with the FEC data.  The decoder API function
           has a flag to indicate that a FEC frame rather than a regular frame should
           be decoded.  If no FEC data is available for the current frame, the decoder
-          will consider the frame lost and invokes the frame loss concealment.
+          will consider the frame lost and invoke frame loss concealment.
         </t>
 
         <t>
           If the FEC scheme is not implemented on the receiving side, FEC
           SHOULD NOT be used, as it leads to an inefficient usage of network
           resources. Decoder support for FEC SHOULD be indicated at the time a
           session is set up.
         </t>
 
       </section>
 
       <section title='Stereo Operation'>
 
         <t>
           Opus allows for transmission of stereo audio signals. This operation
           is signaled in-band in the Opus payload and no special arrangement
-          is required in the payload format. Any implementation of the Opus
+          is needed in the payload format. Any implementation of the Opus
           decoder MUST be capable of receiving stereo signals, although it MAY
-	  decode those signals as mono.
+          decode those signals as mono.
         </t>
         <t>
           If a decoder can not take advantage of the benefits of a stereo signal
           this SHOULD be indicated at the time a session is set up. In that case
           the sending side SHOULD NOT send stereo signals as it leads to an
-          inefficient usage of the network.
+          inefficient usage of network resources.
         </t>
 
       </section>
 
     </section>
 
     <section title='Opus RTP Payload Format' anchor='opus-rtp-payload-format'>
       <t>The payload format for Opus consists of the RTP header and Opus payload
       data.</t>
       <section title='RTP Header Usage'>
-        <t>The format of the RTP header is specified in <xref target="RFC3550"/>. The Opus
-        payload format uses the fields of the RTP header consistent with this
-        specification.</t>
+        <t>The format of the RTP header is specified in <xref target="RFC3550"/>.
+        The use of the fields of the RTP header by the Opus payload format is
+        consistent with that specification.</t>
 
-        <t>The payload length of Opus is a multiple number of octets and
-        therefore no padding is required. The payload MAY be padded by an
+        <t>The payload length of Opus is an integer number of octets and
+        therefore no padding is necessary. The payload MAY be padded by an
         integer number of octets according to <xref target="RFC3550"/>.</t>
 
         <t>The marker bit (M) of the RTP header is used in accordance with
-	Section 4.1 of <xref target="RFC3551"/>.</t>
+        Section 4.1 of <xref target="RFC3551"/>.</t>
 
         <t>The RTP payload type for Opus has not been assigned statically and is
         expected to be assigned dynamically.</t>
 
-        <t>The receiving side MUST be prepared to receive duplicates of RTP
-        packets. Only one of those payloads MUST be provided to the Opus decoder
-        for decoding and others MUST be discarded.</t>
+        <t>The receiving side MUST be prepared to receive duplicate RTP
+        packets. The receiver MUST provide only one of those payloads to the
+        Opus decoder for decoding, and MUST discard the others.</t>
 
-        <t>Opus supports 5 different audio bandwidths which may be adjusted during
-        the duration of a call. The RTP timestamp clock frequency is defined as
-        the highest supported sampling frequency of Opus, i.e. 48000 Hz, for all
-        modes and sampling rates of Opus. The unit
+        <t>Opus supports 5 different audio bandwidths, which can be adjusted during
+        a call.
+        The RTP timestamp is incremented with a 48000 Hz clock rate
+        for all modes of Opus and all sampling rates.
+        The unit
         for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the
-        sample time of the first encoded sample in the encoded frame. For sampling
-        rates lower than 48000 Hz the number of samples has to be multiplied with
-        a multiplier according to <xref target="fs-upsample-factors"/> to determine
-        the RTP timestamp.</t>
+        sample time of the first encoded sample in the encoded frame.
+        For data encoded with sampling rates other than 48000 Hz,
+        the sampling rate has to be adjusted to 48000 Hz using the
+        corresponding multiplier in <xref target="fs-upsample-factors"/>.</t>
 
         <texttable anchor='fs-upsample-factors' title="Timestamp multiplier">
-          <ttcol align='center'>fs (Hz)</ttcol>
+          <ttcol align='center'>Sampling Rate (Hz)</ttcol>
           <ttcol align='center'>Multiplier</ttcol>
           <c>8000</c>
           <c>6</c>
           <c>12000</c>
           <c>4</c>
           <c>16000</c>
           <c>3</c>
           <c>24000</c>
           <c>2</c>
           <c>48000</c>
           <c>1</c>
         </texttable>
       </section>
 
       <section title='Payload Structure'>
         <t>
-          The Opus encoder can be set to output encoded frames representing 2.5, 5, 10, 20,
-          40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be
-          combined into a packet. The maximum packet length is limited to the amount of encoded
-          data representing 120 ms of speech or audio data. The packetization of encoded data
-          is purely done by the Opus encoder and therefore only one packet output from the Opus
-          encoder MUST be used as a payload.
+          The Opus encoder can output encoded frames representing 2.5, 5, 10, 20,
+          40, or 60&nbsp;ms of speech or audio data. Further, an arbitrary number of frames can be
+          combined into a packet, up to a maximum packet duration representing
+          120&nbsp;ms of speech or audio data. The packetization of encoded data
+          is purely done by the Opus encoder, and therefore an RTP payload MUST
+          contain exactly one packet output from the Opus encoder.
         </t>
 
         <t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t>
 
         <figure anchor="payload-structure"
                 title="Payload Structure with RTP header">
-          <artwork>
+          <artwork align="center">
             <![CDATA[
 +----------+--------------+
 |RTP Header| Opus Payload |
 +----------+--------------+
            ]]>
           </artwork>
         </figure>
 
         <t>
           <xref target='opus-packetization'/> shows supported frame sizes in 
-          milliseconds of encoded speech or audio data for speech and audio mode 
-          (Mode) and sampling rates (fs) of Opus and how the timestamp needs to
-          be incremented for packetization (ts incr). If the Opus encoder
-          outputs multiple encoded frames into a single packet the timestamps
-          have to be added up according to the combined frames.
+          milliseconds of encoded speech or audio data for the speech and audio modes
+          (Mode) and sampling rates (fs) of Opus and shows how the timestamp is
+          incremented for packetization (ts incr). If the Opus encoder
+          outputs multiple encoded frames into a single packet, the timestamp
+          increment is the sum of the increments for the individual frames.
         </t>
 
         <texttable anchor='opus-packetization' title="Supported Opus frame 
          sizes and timestamp increments">
             <ttcol align='center'>Mode</ttcol>
             <ttcol align='center'>fs</ttcol>
             <ttcol align='center'>2.5</ttcol>
             <ttcol align='center'>5</ttcol>
@@ -428,72 +429,71 @@
             <c>all</c>
             <c>120</c>
             <c>240</c>
             <c>480</c>
             <c>960</c>
             <c>1920</c>
             <c>2880</c>
             <c>voice</c>
-            <c>nb/mb/wb/swb/fb</c>
+            <c>NB/MB/WB/SWB/FB</c>
             <c></c>
             <c></c>
             <c>x</c>
             <c>x</c>
             <c>x</c>
             <c>x</c>
             <c>audio</c>
-            <c>nb/wb/swb/fb</c>
+            <c>NB/WB/SWB/FB</c>
             <c>x</c>
             <c>x</c>
             <c>x</c>
             <c>x</c>
             <c></c>
             <c></c>
           </texttable>
 
       </section>
 
     </section>
 
     <section title='Congestion Control'>
 
-      <t>The adaptive nature of the Opus codec allows for an efficient
-      congestion control.</t>
-
-      <t>The target bitrate of Opus can be adjusted at any point in time and
-      thus allowing for an efficient congestion control. Furthermore, the amount
+      <t>The target bitrate of Opus can be adjusted at any point in time, thus
+      allowing efficient congestion control. Furthermore, the amount
       of encoded speech or audio data encoded in a
-      single packet can be used for congestion control since the transmission
-      rate is inversely proportional to these frame sizes. A lower packet
-      transmission rate reduces the amount of header overhead but at the same
-      time increases latency and error sensitivity and should be done with care.</t>
-
-      <t>It is RECOMMENDED that congestion control is applied during the
-      transmission of Opus encoded data.</t>
+      single packet can be used for congestion control, since the transmission
+      rate is inversely proportional to the packet duration. A lower packet
+      transmission rate reduces the amount of header overhead, but at the same
+      time increases latency and loss sensitivity, so it ought to be used with
+      care.</t>
+
+      <t>It is RECOMMENDED that senders of Opus encoded data apply congestion
+      control.</t>
     </section>
 
     <section title='IANA Considerations'>
       <t>One media subtype (audio/opus) has been defined and registered as
       described in the following section.</t>
 
       <section title='Opus Media Type Registration'>
         <t>Media type registration is done according to <xref
         target="RFC4288"/> and <xref target="RFC4855"/>.<vspace
         blankLines='1'/></t>
 
           <t>Type name: audio<vspace blankLines='1'/></t>
           <t>Subtype name: opus<vspace blankLines='1'/></t>
 
           <t>Required parameters:</t>
           <t><list style="hanging">
-            <t hangText="rate:"> RTP timestamp clock rate is incremented with
+            <t hangText="rate:"> the RTP timestamp is incremented with a
             48000 Hz clock rate for all modes of Opus and all sampling
-            frequencies. For audio sampling rates other than 48000 Hz the rate
-            has to be adjusted to 48000 Hz according to <xref target="fs-upsample-factors"/>.
+            rates. For data encoded with sampling rates other than 48000 Hz,
+            the sampling rate has to be adjusted to 48000 Hz using the
+            corresponding multiplier in <xref target="fs-upsample-factors"/>.
           </t>
           </list></t>
 
           <t>Optional parameters:</t>
 
           <t><list style="hanging">
             <t hangText="maxplaybackrate:">
               a hint about the maximum output sampling rate that the receiver is
@@ -520,137 +520,138 @@
               processing pipeline (e.g. echo cancellation) at a higher rate than necessary.
               This parameter can take any value between 8000 and 48000, although
               commonly the value will match one of the Opus bandwidths 
               (<xref target="bandwidth_definitions"/>).
               By default, the sender is assumed to have no limitations, i.e. 48000.
               <vspace blankLines='1'/>
             </t>
 
-            <t hangText="maxptime:"> the decoder's maximum length of time in
-            milliseconds rounded up to the next full integer value represented
-            by the media in a packet that can be
-            encapsulated in a received packet according to Section 6 of
-            <xref target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40,
-            and 60 or an arbitrary multiple of Opus frame sizes rounded up to
-            the next full integer value up to a maximum value of 120 as
+            <t hangText="maxptime:"> the maximum duration of media represented
+            by a packet (according to Section&nbsp;6 of
+            <xref target="RFC4566"/>) that a decoder wants to receive, in
+            milliseconds rounded up to the next full integer value.
+            Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary
+            multiple of an Opus frame size rounded up to the next full integer
+            value, up to a maximum value of 120, as
             defined in <xref target='opus-rtp-payload-format'/>. If no value is
-              specified, 120 is assumed as default. This value is a recommendation
+              specified, the default is 120. This value is a recommendation
               by the decoding side to ensure the best
               performance for the decoder. The decoder MUST be
               capable of accepting any allowed packet sizes to
               ensure maximum compatibility.
               <vspace blankLines='1'/></t>
 
-            <t hangText="ptime:"> the decoder's recommended length of time in
-            milliseconds rounded up to the next full integer value represented
-            by the media in a packet according to
-            Section 6 of <xref target="RFC4566"/>. Possible values are
-            3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes
-            rounded up to the next full integer value up to a maximum
-            value of 120 as defined in <xref
+            <t hangText="ptime:"> the preferred duration of media represented
+            by a packet (according to Section&nbsp;6 of
+            <xref target="RFC4566"/>) that a decoder wants to receive, in
+            milliseconds rounded up to the next full integer value.
+            Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary
+            multiple of an Opus frame size rounded up to the next full integer
+            value, up to a maximum value of 120, as defined in <xref
             target='opus-rtp-payload-format'/>. If no value is
-              specified, 20 is assumed as default. If ptime is greater than
+              specified, the default is 20. If ptime is greater than
               maxptime, ptime MUST be ignored. This parameter MAY be changed
               during a session. This value is a recommendation by the decoding
               side to ensure the best
               performance for the decoder. The decoder MUST be
               capable of accepting any allowed packet sizes to
               ensure maximum compatibility.
               <vspace blankLines='1'/></t>
 
-            <t hangText="minptime:"> the decoder's minimum length of time in
-            milliseconds rounded up to the next full integer value represented
-            by the media in a packet that SHOULD
-            be encapsulated in a received packet according to Section 6 of <xref
-            target="RFC4566"/>. Possible values are 3, 5, 10, 20, 40, and 60
+            <t hangText="minptime:"> the minimum duration of media represented
+            by a packet (according to Section&nbsp;6 of
+            <xref target="RFC4566"/>) that SHOULD be encapsulated in a received
+            packet, in milliseconds rounded up to the next full integer value.
+            Possible values are 3, 5, 10, 20, 40, and 60
             or an arbitrary multiple of Opus frame sizes rounded up to the next
             full integer value up to a maximum value of 120
             as defined in <xref target='opus-rtp-payload-format'/>. If no value is
-              specified, 3 is assumed as default. This value is a recommendation
+              specified, the default is 3. This value is a recommendation
               by the decoding side to ensure the best
               performance for the decoder. The decoder MUST be
               capable to accept any allowed packet sizes to
               ensure maximum compatibility.
               <vspace blankLines='1'/></t>
 
             <t hangText="maxaveragebitrate:"> specifies the maximum average
-	    receive bitrate of a session in bits per second (b/s). The actual
-            value of the bitrate may vary as it is dependent on the
+            receive bitrate of a session in bits per second (b/s). The actual
+            value of the bitrate can vary, as it is dependent on the
             characteristics of the media in a packet. Note that the maximum
             average bitrate MAY be modified dynamically during a session. Any
-            positive integer is allowed but values outside the range between
-            6000 and 510000 SHOULD be ignored. If no value is specified, the
+            positive integer is allowed, but values outside the range
+            6000 to 510000 SHOULD be ignored. If no value is specified, the
             maximum value specified in <xref target='bitrate_by_bandwidth'/>
-            for the corresponding mode of Opus and corresponding maxplaybackrate:
-            will be the default.<vspace blankLines='1'/></t>
+            for the corresponding mode of Opus and corresponding maxplaybackrate
+            is the default.<vspace blankLines='1'/></t>
 
             <t hangText="stereo:">
               specifies whether the decoder prefers receiving stereo or mono signals.
-              Possible values are 1 and 0 where 1 specifies that stereo signals are preferred
+              Possible values are 1 and 0 where 1 specifies that stereo signals are preferred,
               and 0 specifies that only mono signals are preferred.
               Independent of the stereo parameter every receiver MUST be able to receive and
               decode stereo signals but sending stereo signals to a receiver that signaled a
               preference for mono signals may result in higher than necessary network
-              utilisation and encoding complexity. If no value is specified, mono
-              is assumed (stereo=0).<vspace blankLines='1'/>
+              utilization and encoding complexity. If no value is specified,
+              the default is 0 (mono).<vspace blankLines='1'/>
             </t>
 
             <t hangText="sprop-stereo:">
               specifies whether the sender is likely to produce stereo audio.
-              Possible values are 1 and 0 where 1 specifies that stereo signals are likely to
-	      be sent, and 0 speficies that the sender will likely only send mono.
-	      This is not a guarantee that the sender will never send stereo audio
-	      (e.g. it could send a pre-recorded prompt that uses stereo), but it
-	      indicates to the receiver that the received signal can be safely downmixed to mono.
-	      This parameter is useful to avoid wasting receiver resources by operating the audio
-	      processing pipeline (e.g. echo cancellation) in stereo when not necessary.
-              If no value is specified, mono
-              is assumed (sprop-stereo=0).<vspace blankLines='1'/>
+              Possible values are 1 and 0, where 1 specifies that stereo signals are likely to
+              be sent, and 0 specifies that the sender will likely only send mono.
+              This is not a guarantee that the sender will never send stereo audio
+              (e.g. it could send a pre-recorded prompt that uses stereo), but it
+              indicates to the receiver that the received signal can be safely downmixed to mono.
+              This parameter is useful to avoid wasting receiver resources by operating the audio
+              processing pipeline (e.g. echo cancellation) in stereo when not necessary.
+              If no value is specified, the default is 0
+              (mono).<vspace blankLines='1'/>
             </t>
 
             <t hangText="cbr:">
               specifies if the decoder prefers the use of a constant bitrate versus
-              variable bitrate. Possible values are 1 and 0 where 1 specifies constant
-              bitrate and 0 specifies variable bitrate. If no value is specified, cbr
-              is assumed to be 0. Note that the maximum average bitrate may still be
-              changed, e.g. to adapt to changing network conditions.<vspace blankLines='1'/>
+              variable bitrate. Possible values are 1 and 0, where 1 specifies constant
+              bitrate and 0 specifies variable bitrate. If no value is specified,
+              the default is 0 (vbr). When cbr is 1, the maximum average bitrate can still
+              change, e.g. to adapt to changing network conditions.<vspace blankLines='1'/>
             </t>
 
             <t hangText="useinbandfec:"> specifies that the decoder has the capability to
-            take advantage of the Opus in-band FEC. Possible values are 1 and 0. It is RECOMMENDED to provide
-            0 in case FEC cannot be utilized on the receiving side. If no
+            take advantage of the Opus in-band FEC. Possible values are 1 and 0.
+            Providing 0 when FEC cannot be used on the receiving side is
+            RECOMMENDED. If no
             value is specified, useinbandfec is assumed to be 0.
             This parameter is only a preference and the receiver MUST be able to process
             packets that include FEC information, even if it means the FEC part is discarded.
             <vspace blankLines='1'/></t>
 
             <t hangText="usedtx:"> specifies if the decoder prefers the use of
-            DTX. Possible values are 1 and 0. If no value is specified, usedtx
-            is assumed to be 0.<vspace blankLines='1'/></t>
+            DTX. Possible values are 1 and 0. If no value is specified, the
+            default is 0.<vspace blankLines='1'/></t>
           </list></t>
 
           <t>Encoding considerations:<vspace blankLines='1'/></t>
           <t><list style="hanging">
-            <t>Opus media type is framed and consists of binary data according
-            to Section 4.8 in <xref target="RFC4288"/>.</t>
+            <t>The Opus media type is framed and consists of binary data according
+            to Section&nbsp;4.8 in <xref target="RFC4288"/>.</t>
           </list></t>
 
           <t>Security considerations: </t>
           <t><list style="hanging">
             <t>See <xref target='security-considerations'/> of this document.</t>
           </list></t>
 
           <t>Interoperability considerations: none<vspace blankLines='1'/></t>
           <t>Published specification: none<vspace blankLines='1'/></t>
 
           <t>Applications that use this media type: </t>
           <t><list style="hanging">
             <t>Any application that requires the transport of
-            speech or audio data may use this media type. Some examples are,
+            speech or audio data can use this media type. Some examples are,
             but not limited to, audio and video conferencing, Voice over IP,
             media streaming.</t>
           </list></t>
 
           <t>Person &amp; email address to contact for further information:</t>
           <t><list style="hanging">
             <t>SILK Support [email-masked]</t>
             <t>Jean-Marc Valin [email-masked]</t>
@@ -684,17 +685,17 @@
         the mapping is as follows:</t>
 
         <t>
           <list style="symbols">
             <t>The media type ("audio") goes in SDP "m=" as the media name.</t>
 
             <t>The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding
             name. The RTP clock rate in "a=rtpmap" MUST be 48000 and the number of
-	    channels MUST be 2.</t>
+            channels MUST be 2.</t>
 
             <t>The OPTIONAL media type parameters "ptime" and "maxptime" are
             mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the
             SDP.</t>
 
             <t>The OPTIONAL media type parameters "maxaveragebitrate", 
             "maxplaybackrate", "minptime", "stereo", "cbr", "useinbandfec", and 
             "usedtx", when present, MUST be included in the "a=fmtp" attribute 
@@ -770,65 +771,64 @@
           target="RFC3264"/> to negotiate the use of Opus, the following
           considerations apply:</t>
 
           <t><list style="symbols">
 
             <t>Opus supports several clock rates. For signaling purposes only
             the highest, i.e. 48000, is used. The actual clock rate of the
             corresponding media is signaled inside the payload and is not
-            subject to this payload format description. The decoder MUST be
-            capable to decode every received clock rate. An example
+            restricted by this payload format description. The decoder MUST be
+            capable of decoding every received clock rate. An example
             is shown below:
 
             <figure>
               <artwork>
                 <![CDATA[
     m=audio 54312 RTP/AVP 100
     a=rtpmap:100 opus/48000/2
                 ]]>
               </artwork>
             </figure>
             </t>
 
             <t>The "ptime" and "maxptime" parameters are unidirectional
             receive-only parameters and typically will not compromise
-            interoperability; however, dependent on the set values of the
-            parameters the performance of the application may suffer.  <xref
+            interoperability; however, some values might cause application
+            performance to suffer. <xref
             target="RFC3264"/> defines the SDP offer-answer handling of the
             "ptime" parameter. The "maxptime" parameter MUST be handled in the
             same way.</t>
 
             <t>
               The "minptime" parameter is a unidirectional
               receive-only parameters and typically will not compromise
-              interoperability; however, dependent on the set values of the
-              parameter the performance of the application may suffer and should be
-              set with care.
+              interoperability; however, some values might cause application
+              performance to suffer and ought to be used with care.
             </t>
 
             <t>
               The "maxplaybackrate" parameter is a unidirectional receive-only
               parameter that reflects limitations of the local receiver. The sender
               of the other side SHOULD NOT send with an audio bandwidth higher than
               "maxplaybackrate" as this would lead to inefficient use of network resources.
               The "maxplaybackrate" parameter does not
-	      affect interoperability. Also, this parameter SHOULD NOT be used
-	      to adjust the audio bandwidth as a function of the bitrates, as this
-	      is the responsibility of the Opus encoder implementation.
+              affect interoperability. Also, this parameter SHOULD NOT be used
+              to adjust the audio bandwidth as a function of the bitrate, as this
+              is the responsibility of the Opus encoder implementation.
             </t>
 
             <t>The "maxaveragebitrate" parameter is a unidirectional receive-only
             parameter that reflects limitations of the local receiver. The sender
             of the other side MUST NOT send with an average bitrate higher than
             "maxaveragebitrate" as it might overload the network and/or
             receiver. The "maxaveragebitrate" parameter typically will not
-            compromise interoperability; however, dependent on the set value of
-            the parameter the performance of the application may suffer and should
-            be set with care.</t>
+            compromise interoperability; however, some values might cause 
+            application performance to suffer, and ought to be set with
+            care.</t>
 
             <t>The "sprop-maxcapturerate" and "sprop-stereo" parameters are
             unidirectional sender-only parameters that reflect limitations of
             the sender side.
             They allow the receiver to set up a reduced-complexity audio
             processing pipeline if the  sender is not planning to use the full
             range of Opus's capabilities.
             Neither "sprop-maxcapturerate" nor "sprop-stereo" affect
@@ -861,46 +861,46 @@
 
         <t>For declarative use of SDP such as in Session Announcement Protocol
         (SAP), <xref target="RFC2974"/>, and RTSP, <xref target="RFC2326"/>, for
         Opus, the following needs to be considered:</t>
 
         <t><list style="symbols">
 
           <t>The values for "maxptime", "ptime", "minptime", "maxplaybackrate", and
-          "maxaveragebitrate" should be selected carefully to ensure that a
+          "maxaveragebitrate" ought to be selected carefully to ensure that a
           reasonable performance can be achieved for the participants of a session.</t>
 
           <t>
             The values for "maxptime", "ptime", and "minptime" of the payload
             format configuration are recommendations by the decoding side to ensure
             the best performance for the decoder. The decoder MUST be
-            capable to accept any allowed packet sizes to
+            capable of accepting any allowed packet sizes to
             ensure maximum compatibility.
           </t>
 
           <t>All other parameters of the payload format configuration are declarative
           and a participant MUST use the configurations that are provided for
-          the session. More than one configuration may be provided if necessary
+          the session. More than one configuration can be provided if necessary
           by declaring multiple RTP payload types; however, the number of types
-          should be kept small.</t>
+          ought to be kept small.</t>
         </list></t>
       </section>
     </section>
   </section>
 
     <section title='Security Considerations' anchor='security-considerations'>
 
       <t>All RTP packets using the payload format defined in this specification
       are subject to the general security considerations discussed in the RTP
-      specification <xref target="RFC3550"/> and any profile from
-      e.g. <xref target="RFC3711"/> or <xref target="RFC3551"/>.</t>
+      specification <xref target="RFC3550"/> and any profile from,
+      e.g., <xref target="RFC3711"/> or <xref target="RFC3551"/>.</t>
 
-      <t>This payload format transports Opus encoded speech or audio data,
-      hence, security issues include confidentiality, integrity protection, and
+      <t>This payload format transports Opus encoded speech or audio data.
+      Hence, security issues include confidentiality, integrity protection, and
       authentication of the speech or audio itself. The Opus payload format does
       not have any built-in security mechanisms. Any suitable external
       mechanisms, such as SRTP <xref target="RFC3711"/>, MAY be used.</t>
 
       <t>This payload format and the Opus encoding do not exhibit any
       significant non-uniformity in the receiver-end computational load and thus
       are unlikely to pose a denial-of-service threat due to the receipt of
       pathological datagrams.</t>
-- 
1.8.3.2

>From d9e116bcbfd182ac63e2e2fa2daf407d326b6345 Mon Sep 17 00:00:00 2001
From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 25 Jul 2014 22:33:55 -0700
Subject: [PATCH 2/2] RTP draft edits (normative changes).

Here are my proposals to resolve a few issues with the current
 draft.
See the corresponding message to the list for details.
---
 doc/draft-ietf-payload-rtp-opus.xml | 34 +++++++++++++++++++++++-----------
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/doc/draft-ietf-payload-rtp-opus.xml b/doc/draft-ietf-payload-rtp-opus.xml
index afa7284..412ce0f 100644
--- a/doc/draft-ietf-payload-rtp-opus.xml
+++ b/doc/draft-ietf-payload-rtp-opus.xml
@@ -215,17 +215,17 @@
             compressed stream. See <xref target="RFC6562"/> for guidelines on when VBR is
             appropriate for encrypted audio communications. In the case where an existing
             VBR stream needs to be converted to CBR for security reasons, then the Opus padding
             mechanism described in <xref target="RFC6716"/> is the RECOMMENDED way to achieve padding
             because the RTP padding bit is unencrypted.</t>
 
           <t>
             The bitrate can be adjusted at any point in time. To avoid congestion,
-            the average bitrate SHOULD be adjusted to the available
+            the average bitrate SHOULD NOT exceed the available
             network capacity. If no target bitrate is specified, the bitrates specified in
             <xref target='bitrate_by_bandwidth'/> are RECOMMENDED.
           </t>
 
         </section>
 
         <section title='Discontinuous Transmission (DTX)'>
 
@@ -294,19 +294,20 @@
           entirely controlled by the encoder and therefore no special precautions
           for the payload have to be taken.
         </t>
 
         <t>
           On the receiving side, the decoder can take advantage of this
           additional information when it loses a packet and the next packet
           is available.  In order to use the FEC data, the jitter buffer needs
-          to provide access to payloads with the FEC data.  The decoder API function
-          has a flag to indicate that a FEC frame rather than a regular frame should
-          be decoded.  If no FEC data is available for the current frame, the decoder
+          to provide access to payloads with the FEC data.  The receiver can
+          then configure its decoder to decode the FEC data from the packet
+          rather than the regular audio data.
+          If no FEC data is available for the current frame, the decoder
           will consider the frame lost and invoke frame loss concealment.
         </t>
 
         <t>
           If the FEC scheme is not implemented on the receiving side, FEC
           SHOULD NOT be used, as it leads to an inefficient usage of network
           resources. Decoder support for FEC SHOULD be indicated at the time a
           session is set up.
@@ -383,19 +384,20 @@
         </texttable>
       </section>
 
       <section title='Payload Structure'>
         <t>
           The Opus encoder can output encoded frames representing 2.5, 5, 10, 20,
           40, or 60&nbsp;ms of speech or audio data. Further, an arbitrary number of frames can be
           combined into a packet, up to a maximum packet duration representing
-          120&nbsp;ms of speech or audio data. The packetization of encoded data
-          is purely done by the Opus encoder, and therefore an RTP payload MUST
-          contain exactly one packet output from the Opus encoder.
+          120&nbsp;ms of speech or audio data. The grouping of one or more Opus
+          frames into a single Opus packet is defined in Section&nbsp;3 of
+          <xref target="RFC6716"/>. An RTP payload MUST contain exactly one
+          Opus packet as defined by that document.
         </t>
 
         <t><xref target='payload-structure'/> shows the structure combined with the RTP header.</t>
 
         <figure anchor="payload-structure"
                 title="Payload Structure with RTP header">
           <artwork align="center">
             <![CDATA[
@@ -802,19 +804,24 @@
               The "minptime" parameter is a unidirectional
               receive-only parameters and typically will not compromise
               interoperability; however, some values might cause application
               performance to suffer and ought to be used with care.
             </t>
 
             <t>
               The "maxplaybackrate" parameter is a unidirectional receive-only
-              parameter that reflects limitations of the local receiver. The sender
-              of the other side SHOULD NOT send with an audio bandwidth higher than
-              "maxplaybackrate" as this would lead to inefficient use of network resources.
+              parameter that reflects limitations of the local receiver. When
+              sending to a single destination, a sender MUST NOT use an audio
+              bandwidth higher than necessary to represent audio sampled at
+              a sampling rate of "maxplaybackrate". Gateways or senders that
+              are sending the same encoded audio to multiple destinations
+              SHOULD NOT use an audio bandwidth higher than necessary to
+              represent audio sampled at "maxplaybackrate", as this would lead
+              to inefficient use of network resources.
               The "maxplaybackrate" parameter does not
               affect interoperability. Also, this parameter SHOULD NOT be used
               to adjust the audio bandwidth as a function of the bitrate, as this
               is the responsibility of the Opus encoder implementation.
             </t>
 
             <t>The "maxaveragebitrate" parameter is a unidirectional receive-only
             parameter that reflects limitations of the local receiver. The sender
@@ -832,17 +839,22 @@
             processing pipeline if the  sender is not planning to use the full
             range of Opus's capabilities.
             Neither "sprop-maxcapturerate" nor "sprop-stereo" affect
             interoperability and the receiver MUST be capable of receiving any signal.
             </t>
 
             <t>
               The "stereo" parameter is a unidirectional receive-only
-              parameter.
+              parameter. When sending to a single destination, a sender MUST
+              NOT use stereo when "stereo" is 0. Gateways or senders that are
+              sending the same encoded audio to multiple destinations SHOULD
+              NOT use stereo when "stereo" is 0, as this would lead to
+              inefficient use of network resources. The "stereo" parameter does
+              not affect interoperability.
             </t>
 
             <t>
               The "cbr" parameter is a unidirectional receive-only
               parameter.
             </t>
 
             <t>The "useinbandfec" parameter is a unidirectional receive-only
-- 
1.8.3.2

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 30 Jul 2014 20:06:24 -0400

Thanks Tim, these changes are all included in the latest version of
the draft I just posted.

	Jean-Marc

On 28/07/14 12:02 PM, Timothy B. Terriberry wrote:
> I have reviewed draft-itef-payload-rtp-opus-02. After the issues
> below are addressed, I think this draft is ready for WGLC.
> 
> " (codec)" -> "" (this WG is never referred to again, so defining
> the short name is unnecessary)
> 
> The same suggestions made for the abstract also apply to the text
> from it that is repeated here.
> 
> "usually " -> "" (the term is used a total of 3 times in the
> document, all in the same paragraph, which also makes it clear that
> it means "per channel"... no reason to suggest to the reader that
> it might be ambiguous here)
> 
> 2.1 Audio Bandwidth
> 
> Although the section is called "Audio Bandwidth", there's no reason
> not to give units in these column headers to make it clear we're
> not talking about network bandwidth (bits per second).
> 
> The abbreviations should also probably be capitalized (the document
> uses capitalization for these abbreviations inconsistently, but I
> think the capitalized version should be preferred).
> 
> 3. Opus Codec
> 
> The first couple of sentences use "speech and audio" quite a few
> times, but never distinguish how "speech" is not also "audio".
> Suggest replacing them with the following text:
> 
> audio signals.  Two different modes can be chosen, a voice mode or
> an audio mode, to allow the most efficient coding depending on the
> type of the input signal, the sampling frequency of the input
> signal, and the intended application.
> 
> The next sentence should also say "general audio signals" instead
> of just "audio signals".
> 
> 3.1 Network Bandwidth
> 
> "a higher bitrate results in higher quality" -> "higher bitrates
> result in higher quality"
> 
> "One potential reason ... is the potential..." -> "One reason ...
> is the potential..."
> 
> "_may_" -> "_might_"
> 
> non-2119 contexts. These should all be changed to "might"/"can",
> "ought to", and "needed"/"necessary" as appropriate.
> 
> "an adaptive bitrate" -> "a variable bitrate" (the referenced
> section describes "variable bitrate", but never defines "adaptive
> bitrate")
> 
> "In that case, the bitrate will automatically be reduced for
> certain input signals like periods of silence.  During continuous
> transmission the bitrate will be reduced, when the input signal
> allows to do so, but the transmission to the receiver itself will
> never be interrupted." -> "In that case, the encoder will
> automatically reduce the bitrate for certain input signals, like
> periods of silence.  When using continuous transmission, it will
> reduce the bitrate when the characteristics of the input signal
> permit, but will never interrupt the transmission to the receiver."
> (remove passive voice and the ungrammatical "allows to do so"; also
> change "During" to "When using" to clarify that this is a choice)
> 
> "may be set to" -> "can"
> 
> The last paragraph in the section should also remove references to
> a DTX "mode", to avoid ambiguity with the speech mode or audio
> mode. RFC 6716 is very careful to define a "mode" of operation as
> only the choice of SILK or CELT, and refer to other parameter
> choices as a "configuration", to avoid making the word "mode"
> ambiguous. This document should take the same care. It should also
> move the last sentence of this paragraph to the front, so that the
> conclusion is last (and replace "adaptive" with "variable" again,
> for consistency). Proposed alternative text:
> 
> "allows for "in-band" forward error correction data to be embedded"
> -> "allows for embedding "in-band" forward error correction data"
> (remove passive voice)
> 
> "when, in case of a packet loss, the next packet is available" ->
> "when it loses a packet and the next packet is available" (remove 
> "will consider ... and invokes the frame loss concealment." ->
> "will consider ... and invoke frame loss concealment." (avoid tense
> change and remove an inappropriate article)
> 
> 3.4 Stereo Operation
> 
> "required" -> "needed"
> 
> "usage of the network" -> "usage of network resources" (for
> consistency with the wording in Section 3.3)
> 
> 4.1 RTP Header Usage
> 
> "The Opus payload format uses the fields of the RTP header
> consistent with this specification." -> "The use of the fields of
> the RTP header by the Opus payload format is consistent with that
> specification." (avoid awkward use of the adverb "consistently",
> which would be required to make the original sentence correct; also
> "this specification" would be the current draft, use "that
> specification" to refer to RFC3550)
> 
> "Only one of those payloads MUST be provided to the Opus decoder
> for decoding and others MUST be discarded." -> "The receiver MUST
> provide only one of those payloads to the Opus decoder for
> decoding, and MUST discard the others." (remove passive voice,
> particularly in a sentence that places normative requirements on an
> actor without naming that actor)
> 
> The language in this paragraph should also be made consistent with
> the language in Section 6.1 (when describing the rate: parameter).
> Proposed text:
> 
> timestamp corresponds to the sample time of the first encoded
> sample in the encoded frame.  For data encoded with sampling rates
> other than 48000 Hz, the sampling rate has to be adjusted to 48000
> Hz using the corresponding multiplier in Table 2.
> 
> "...combined into a packet. The maximum packet length is limited to
> the amount of encoded data representing 120 ms of speech or audi
> odata." -> "...combined into a packet, up to a maximum packet
> duration representing 120 ms of speech or audio data." (keeping
> these in the same sentence prevents a reader from stopping at the
> end of the first sentence and not realizing the next imposes an
> additional restriction; also, replace "length" with the less
> ambiguous "duration", to be clear we're not talking about a
> restriction on the number of bytes)
> 
> "... encoder and therefore only one packet output from the Opus
> encoder MUST be used as a payload" -> "...encoder, and therefore an
> RTP payload MUST contain exactly one packet output from the Opus
> encoder." (remove passive voice from normative requirements; a
> change in subject requires a comma before "and")
> 
> "the timestamps have to be added up according to the combined
> frames" -> "the timestamp increment is the sum of the increments
> for the individual frames" (we aren't adding timestamps, and
> "according to" is ambiguous)
> 
> congestion control." -> "" (this is redundant with the sentence
> right after it)
> 
> "these frame sizes" -> "the packet duration" (the previous part of
> the sentence talks about a packet, not frames)
> 
> "error sensitivity" -> "loss sensitivity" (let's be clear about the
> kind of errors we're worried about)
> 
> "sensitivity and should be done" -> "sensitivity, so it ought to
> be used" (non-normative should; also, it is not clear how to "do" a
> lower packet transmission rate)
> 
> transmission of Opus encoded data." -> "It is RECOMMENDED that
> senders of Opus encoded data apply congestion control." (remove
> passive voice from normative requirements)
> 
> "RTP timestamp clock rate" -> "the RTP timestamp" (clock rate
> appears redundantly elsewhere in the same sentence; missing
> article)
> 
> "sampling frequencies" -> "sampling rates" (for consistency with
> the rest of the document)
> 
> adjusted to 48000 Hz according to Table 2." -> "For data encoded
> with sampling rates other than 48000 Hz, the sampling rate has to
> be adjusted to 48000 Hz using the corresponding multiplier in Table
> 2." (for consistency with proposed text in Section 4.1)
> 
> "the decoder's maximum length of time in milliseconds rounded up to
> the next full integer value represented by the media in a packet
> that can be encapsulated in a received packet according to Section
> 6 of RFC4566."
> 
> This is quite the mouthful, and it is quite ambiguous which
> clauses refer to which (especially the reference to RFC4566). It is
> also phrased as an absolute requirement, when several sentences
> later the document clearly states it is not one. How about
> 
> "the maximum duration of media represented by a packet (according
> to Section 6 of RFC4566) that a decoder wants to receive, in
> milliseconds rounded up to the next full integer value."
> 
> I am inferring here that RFC4566 is being invoked solely to define
> the duration of a packet, since the same phrase appears in the
> definition of minptime, which is not defined by RFC4566.
> 
> "...40, and 60 or an arbitrary multiple of Opus frame sizes rounded
> up to the next full integer value up to a maximum value of 120 as 
> defined..." -> "...40, 50, or an arbitrary multiple of an Opus
> frame size rounded up to the next full integer value, up to a
> maximum of 120, as defined..." (both using and omitting a serial
> comma in the same sentence; it is unclear what "a" multiple of
> several "frame sizes" might be... in practice it must be a multiple
> of _one_ frame size, though since all frame sizes are themselves a
> multiple of a 2.5 ms frame size, this does not impose any
> additional restrictions; also added some missing commas)
> 
> "120 is assumed as default" -> "the default is 120" (no reason not
> to be direct)
> 
> The corresponding text for ptime and minptime should be changed in
> the same ways.
> 
> "range between 6000 and 510000" -> "range 6000 to 510000" (I assume
> this was meant to be inclusive)
> 
> "preferred and 0 specifies" -> "preferred, and 0 specifies" (comma
> for new subject)
> 
> "bitrate and 0 specifies" -> "bitrate, and 0 specifies" (comma for
> new subject)
> 
> "Note that the maximum average bitrate may still be changed..." ->
> "When cbr is 1, the maximum average bitrate can still change..."
> (the phrase "Note that" is always superfluous; this is only
> surprising when cbr is enabled, so let's call out that case; also,
> remove the non-normative may).
> 
> "It is RECOMMENDED to provide 0 in case FEC cannot be utilized..."
> -> "Providing 0 when FEC cannot be used... is RECOMMENDED." (less
> awkward phrasing; "used" is always preferable to "utilized")
> 
> "dependent on the set values of the parameters the performance of
> the application may suffer" -> "some values might cause
> application performance to suffer" (non-normative may, indirect
> phrasing)
> 
> We shouldn't encourage people to fill up the pipe just because
> it's available.
> 
> This section talks about "the decoder API", which presupposes a
> specific implementation of Opus. There's no reason not to be 
> "The decoder API function has a flag to indicate that a FEC frame
> rather than a regular frame should be decoded." -> "The receiver
> can then configure its decoder to decode the FEC data from the
> packet rather than the regular audio data."
> 
> 4.2 Payload Structure
> 
> containing multiple frames, and a separate repacketizer API is
> provided to construct such multi-frame packets. The current text
> suggests the latter is forbidden, but I don't believe that's the
> intent. Proposed text:
> 
> "The packetization of encoded data is purely done by the Opus
> encoder, and therefore an RTP payload MUST contain exactly one
> packet output from the Opus encoder." -> "The grouping of one or
> more Opus frames into a single Opus packet is defined in Section 3
> of RFC6716. An RTP payload MUST contain exactly one Opus packet as
> defined by that document."
> 
> Based on off-list feedback I got recently, I propose the following
> text for maxplaybackrate:
> 
> o  The "maxplaybackrate" parameter is a unidirectional
> receive-only parameter that reflects limitations of the local
> receiver.  When sending to a single destination, a sender MUST NOT
> sampled at a sampling rate of "maxplaybackrate".  Gateways or
> senders that are sending the same encoded audio to multiple
> destinations SHOULD NOT use an audio bandwidth higher than
> necessary to represent audio sampled at "maxplaybackrate", as this
> would lead to inefficient use of network resources.  The
> "maxplaybackrate" parameter does not affect interoperability.
> Also, this parameter SHOULD NOT be used to adjust the audio
> bandwidth as a function of the bitrate, as this is the
> responsibility of the Opus encoder implementation.
> 
> The change from "an audio bandwidth higher than 'maxplaybackrate'"
> to "an audio bandwidth higher than necessary to represent audio
> sampled at a sampling rate of 'maxplaybackrate'" was done to handle
> the fact that maxplaybackrate is a sampling rate, which is
> typically at least twice the value of the corresponding audio
> bandwidth, and to handle the case where maxplaybackrate does not
> correspond exactly to one of the sampling rates supported by Opus
> (e.g., fully representing audio sampled at 32 kHz would require
> using Opus in a fullband configuration... given typical rate
> allocations of the encoder, the waste from using 48 kHz instead of
> 32 kHz would only be a handful of bits per frame).
> 
> Similarly, for stereo:
> 
> o  The "stereo" parameter is a unidirectional receive-only
> parameter. When sending to a single destination, a sender MUST NOT
> use stereo when "stereo" is 0.  Gateways or senders that are
> use stereo when "stereo" is 0, as this would lead to inefficient
> use of network resources.  The "stereo" parameter does not affect 
> interoperability.
> 
> I think this strikes the right balance between giving receivers
> the leverage they need to keep senders from wasting their network
> resources while allowing gateways to avoid transcoding. If others
> have advice to implementers on how to handle multiparty situations
> (e.g., a 3-way mesh call where someone joins from the PSTN), feel
> free to propose text on the list.
> 
> _______________________________________________ payload mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/payload
>