Re: [rtcweb] Comments on draft-ietf-rtcweb-audio-03

[Jean-Marc Valin <[e-mail]>]

Hi Magnus,

We just posted a new version of the draft, see
http://tools.ietf.org/html/draft-ietf-rtcweb-audio-04

See more below.

On 01/22/2014 10:28 AM, Magnus Westerlund wrote:
> 1. Section 3:
>  o  G.711 PCMA and PCMU with one channel, a rate of 8000 Hz and a
>       ptime of 20 - see section 4.5.14 of [RFC3551]
> 
> Especially in regards to amount of data packetized in each RTP payload
> this is fairly narrow definition. Wouldn't the interoperability gain to
> at least require wider receiver capabilities?

Changed this to "any ptime up to 120 ms" to match Opus.

> 2. Section 3:
>  o  Telephone Event - [RFC4733]
> 
> Maybe one should be more explicit about which RTP payload format one is
> expected to support. As RFC 4733 contains two. Do I assume correctly
> that only audio/telephone-event is to be supported?
> 
> In addition considering that this payload format can carry any of the
> events listed in the event registry:
> http://www.iana.org/assignments/audio-telephone-event-registry/audio-telephone-event-registry.xhtml#audio-telephone-event-registry-1
> 
> I think the events that an endpoint shall be capable of generating and
> consume needs to be explicitly listed.

This part was clarified. Let us know if there's any more issue.

> 3. Section 4:
> 
>    AUTHORS' NOTE: The idea of using the same level as what the ITU-T
>    recommends is that it should improve inter-operability while at the
>    same time maintaining sufficient dynamic range and reducing the risk
>    of clipping.  The main drawbacks are that the resulting level is
>    about 12 dB lower than typical "commercial music" levels and it
>    leaves room for ill-behaved clients to be much louder than a normal
>    client.  While using music-type levels is not really an option (it
>    would require using the same compressor-limitors that studios use),
>    it would be possible to have a level slightly higher (e.g.  3 dB)
>    than what is recommended above without causing interoperability
>    problems.
> 
> The WG needs to resolve this Author's note before we can go to WG last
> call. I would hope that we would be able to go to WG last call after the
> next update. Thus, anyone have feedback on this? If no one have input, I
> would suggest that we remove the note and leave the recommendation as it
> is.

Note removed. I haven't heard of anyone disagreeing so far.

> 4. Section 8.
> 
> Can you please be more specific to what is relevant for this document in
> regards to the security considerations. I assume confidentiality, source
> authentication are the two main issues. Anything else that needs to be
> included?

Added a link to RFC6562 on the VBR issue and made it clear that
encryption and authentication were out of scope here.

> 5. Section 10.
> 
> [I-D.ekr-security-considerations-for-rtc-web] needs to be updated to the
> latest version.

Removed the reference since it wasn't relevant to this draft.

Cheers,

	Jean-Marc