Subject: Re: [rtcweb] Comments regarding draft-ietf-rtcweb-audio-09

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 1 Dec 2015 15:47:21 -0500

Hi Roman,

On 11/19/2015 12:14 PM, Roman Shpount wrote:
> My understanding was that G.711 and CN are primarily needed to
> legacy interop. If browser is communicating with a legacy end point
> through some sort of ICE/DTLS-SRTP gateway, then it needs to
> support the same codecs as legacy endpoint. There are plenty of
> legacy endpoints that support G.711 but do not support CN. Also, if
> browser is communicating with some sort of non-browser service,
> such as conference bridge, and if this bridge implements Opus
> codec, there is no real reason to implement CN. So, what I want is
> to see is that CN a MUST(or a SHOULD) for browsers only, with
> gateways and non-browsers allowed to implement G.711 only, only
> G.711 + CN, Opus + G.711, or all three codecs.

The current text says that CN is required only for "WebRTC endpoints",
i.e. the same as those who currently need to support Opus. Any legacy
equipment is already excluded from the requirement.

> Finally, if CN is not supported and not negotiated during call
> setup, nothing bad will happen. I am not aware of any scenario
> where audio call will fail to setup if CN fails to get negotiated.
> So, this probably makes CN a SHOULD, not a MUST even for browsers.

Lack of CN would not make call setup fail, but it seems like
guaranteed presence would make it less likely to end up wasting
bandwidth. Anyone else has an opinion on this?

	Jean-Marc