Subject: [rtcweb] Proposed resolution on comfort noise

From: Ted Hardie <[email-masked]>
Date: Thu, 10 Dec 2015 14:14:15 -0800

After reading the discussion on the comfort noise issue, it appears that
one way forward might be to adjust this language:

"comfort noise (CN).  Receivers MUST support RFC3389 CN for streams encoded
with G.711 or any other supported codec that  does not provide its own CN.”

to say instead

"comfort noise (CN).  WebRTC endpoints MUST support RFC3389 CN for streams
encoded with G.711 or any other supported codec that  does not provide its
own CN.”

This would still allow non-WebRTC endpoints to omit CN support, while
retaining the mandate for WebRTC endpoints.

Does this resolve the issue?

regards,

Ted

---

From: Roman Shpount <[email-masked]>
Date: Thu, 10 Dec 2015 17:25:54 -0500

This resolves the CN issue for me.

_____________
Roman Shpount

On Thu, Dec 10, 2015 at 5:14 PM, Ted Hardie <[email-masked]> wrote:

> "comfort noise (CN).  Receivers MUST support RFC3389 CN for streams
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: "Wyss, Felix" <[email-masked]>
Date: Fri, 11 Dec 2015 04:42:40 +0000

I really don’t see why this needs to be a MUST.  As offerer I should be able to not offer CN and also reject it as answerer.  Whether to support and/or enable CN should be at the each endpoint’s discretion—usually based on system configuration/user preference.  DTX tends to result in a poorer user experience due to noticeable discontinuities and artifacts at the transition between genuine background noise and comfort noise and may miss speech onset.  So an endpoint that doesn’t want to provide CN support because of user preference should not automatically be non-conforming.  I frankly think there is little value to CN and would rather make it optional or leave it out altogether.  Should the WebRTC spec really be burdened with this kind of legacy cruft?  If somebody is concerned about bandwidth, they should be using Opus and not G.711.

Thanks,
--Felix

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Thursday, December 10, 2015 17:14
To: [email-masked]
Subject: [rtcweb] Proposed resolution on comfort noise

After reading the discussion on the comfort noise issue, it appears that one way forward might be to adjust this language:

"comfort noise (CN).  Receivers MUST support RFC3389 CN for streams encoded with G.711 or any other supported codec that  does not provide its own CN.”

to say instead

"comfort noise (CN).  WebRTC endpoints MUST support RFC3389 CN for streams encoded with G.711 or any other supported codec that  does not provide its own CN.”
This would still allow non-WebRTC endpoints to omit CN support, while retaining the mandate for WebRTC endpoints.
Does this resolve the issue?
regards,
Ted

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 11 Dec 2015 00:13:44 -0500

I agree with the proposed text.

Cheers,

	Jean-Marc

On 12/10/2015 05:14 PM, Ted Hardie wrote:
> After reading the discussion on the comfort noise issue, it appears
> that one way forward might be to adjust this language:
> 
> "comfort noise (CN).  Receivers MUST support RFC3389 CN for
> streams encoded with G.711 or any other supported codec that  does
> not provide its own CN.”
> 
> to say instead
> 
> "comfort noise (CN).  WebRTC endpoints MUST support RFC3389 CN for 
> streams encoded with G.711 or any other supported codec that  does
> not provide its own CN.”
> 
> This would still allow non-WebRTC endpoints to omit CN support,
> while retaining the mandate for WebRTC endpoints.
> 
> _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Dec 2015 09:36:15 -0700

Felix, just as background on this... one of the reasons people wanted CN is that for many audio only calls, it roughly halfs the bandwidth. And for conference calls it often cuts the upstream bandwidth by much more than that. The text proposed here does not require and conference bridge, endpoint, or GW to support this as they don't have to RTCWeb Endpoints.

> On Dec 10, 2015, at 9:42 PM, Wyss, Felix <[email-masked]> wrote:
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Dec 2015 14:45:22 -0500

As a bit more background, CN is needed for legacy interop. I know of at
least several VoIP PSTN providers who will only generate G.711 with CN. So,
the options to interoperate with such providers would be to transcode or to
support CN. Essentially each additional codec improves chances for someone
to interoperate. CN helps here. Beyond that CN can be safely ignored. For
any new application Opus without CN should be used which audio draft
already recommends.

Regards,
_____________
Roman Shpount

On Fri, Dec 11, 2015 at 11:36 AM, Cullen Jennings <[email-masked]> wrote:

>
> Felix, just as background on this... one of the reasons people wanted CN
> is that for many audio only calls, it roughly halfs the bandwidth. And for
> conference calls it often cuts the upstream bandwidth by much more than
> that. The text proposed here does not require and conference bridge,
> endpoint, or GW to support this as they don't have to RTCWeb Endpoints.
>
>
> > I really don’t see why this needs to be a MUST.  As offerer I should be
> able to not offer CN and also reject it as answerer.  Whether to support
> and/or enable CN should be at the each endpoint’s discretion—usually based
> on system configuration/user preference.  DTX tends to result in a poorer
> user experience due to noticeable discontinuities and artifacts at the
> transition between genuine background noise and comfort noise and may miss
> speech onset.  So an endpoint that doesn’t want to provide CN support
> because of user preference should not automatically be non-conforming.  I
> frankly think there is little value to CN and would rather make it optional
> or leave it out altogether.  Should the WebRTC spec really be burdened with
> this kind of legacy cruft?  If somebody is concerned about bandwidth, they
> should be using Opus and not G.711.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Dec 2015 13:31:17 +0100

I support this resolution.

I note that there's material in this discussion for an extensive
treatise on the pros and cons of offering CN at gateways. If someone
wishes to extract this as a PR against the -gateways draft, the draft is
at https://github.com/rtcweb-wg/gateways.

On 12/10/2015 11:14 PM, Ted Hardie wrote:
> encoded with G.711 or any other supported codec that  does not provide
> its own CN.”
>
> to say instead
>
> streams encoded with G.711 or any other supported codec that  does not
> provide its own CN.”
>

-- 
Surveillance is pervasive. Go Dark.