Subject: [rtcweb] Few comments on draft-ietf-rtcweb-audio-07

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 16 Apr 2015 18:28:26 +0000

Some comments on draft-ietf-rtcweb-audio from a mixture of Magnus, Sean, Cullen, and Ted. Please consider these as WGLC comments. 

1a) It would be best to use the same terminology from rtcweb-overview

Right now the abstract says:

This document outlines the audio codec and processing requirements
for WebRTC client application and endpoint devices.

This should probably change to (and then it’ll match in the intro section):

This document outlines the audio codec and processing requirements
for WebRTC endpoints.

1b) In Section 3:

WebRTC clients are REQUIRED to implement the following audio codecs:

I think this should use the Overview definitions. Thus, I think this
applies to an "WebRTC endpoint"

2) Need to tweak Sec 2 to include NOT RECOMMENDED:

OLD:

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 RFC 2119 [RFC2119].

NEW:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in RFC 2119 [RFC2119].

3) To avoid a sec considerations comment, I’d probably bolster them by adding something like:

For security considerations regarding the codes themselves please refer their specifications.  Likewise, consult the RTP base specification for security RTP-based security considerations.

4) The last sentence in the sec cons is likely to attract flies.  Can we point to the two security drafts instead?

5) I’d probably the refer to the opus rtp payload draft from -03 to -08 (it’s in IESG eval - yippie) and the reference to the audio codecs for interop from -00 to -01.

6) The draft has "Because of this, clients MAY increase the gain before playback." To make consistent sound levels across browsers, I wonder if this should continue to say something like - "many browsers increase it by X db" and insert whatever value of X that chrome and FF think they should be using. I don't feel strongly about adding this one way or the other but can the authors give it a little thought and see if they think it is needed or not.

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 30 Apr 2015 18:10:21 -0400

Hi Cullen, Magnus, Colin,

Thanks for the review. I just updated the draft. As some of you
pointed out, I changed all instances of "client" to "endpoint" to
match the terminology. See below for more:

> 2) Need to tweak Sec 2 to include NOT RECOMMENDED:

Done.

> For security considerations regarding the codes themselves please 
> refer their specifications.  Likewise, consult the RTP base 
> specification for security RTP-based security considerations.

Added that text, along with references.

> 4) The last sentence in the sec cons is likely to attract flies.
> Can we point to the two security drafts instead?

Added many security references. I didn't delete the sentence itself,
but I can do that too if you think it should go.

> 5) I’d probably the refer to the opus rtp payload draft from -03
> to -08 (it’s in IESG eval - yippie) and the reference to the audio
>  codecs for interop from -00 to -01.

Done.

> 6) The draft has "Because of this, clients MAY increase the gain 
> before playback." To make consistent sound levels across browsers,
> I wonder if this should continue to say something like - "many
> browsers increase it by X db" and insert whatever value of X that
> chrome and FF think they should be using. I don't feel strongly
> about adding this one way or the other but can the authors give it
> a little thought and see if they think it is needed or not.

I don't know that browsers are doing that yet and I'm not exactly sure
what would be a good value there. I suspect it's more of a W3C discussio
n.

On 20/04/15 03:40 PM, Colin Perkins wrote:
> - Section 3 says "Clients MAY use the offer/answer mechanism to 
> signal a preference for a particular mode or ptime". Is this just
> of Opus, or in general? It might be worthwhile saying something
> explicit about acceptable ptime values in general.

There was some discussion on acceptable ptime values in the past, but
there was no consensus achieved.

> - Security considerations ought to explicitly point to the
> security considerations of RFCs 3389, 4733, 6716, and 
> draft-ietf-payload-rtp-opus. It should possibly also point to the 
> draft-ietf-rtcweb-security-arch-11, and the security
> considerations for RTP use in WebRTC in
> draft-ietf-rtcweb-rtp-usage-22

Done.

Cheers,

	Jean-Marc