Subject: [rtcweb] JSEP: "VoiceActivityDetection" option and cient-mixer "vad" extension

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jan 2016 07:37:25 -0800

JSEP Section 5.2.3.4 discusses the implications of the
"VoiceActivityDetection" option for the offer.

One thing that is not covered is whether the "VoiceActivityDetection"
option determines whether the client-mixer "vad" extension is set to "on"
or "off".

For example, I believe that the W3C WEBRTC WG determined that the
client-mixer extension (support for which is required in RTP-Usage) should
always be advertised in the offer.  RFC 6464 Section 4 gives an example of
the a=extmap line:

a=extmap:6 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=on

So, my question is whether "vad=on" or "vad=off" is determined by the
"VoiceActivityDetection" option, or if not, whether there is a setting
(e.g. "vad=on") that is always present in the offer.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 8 Jan 2016 17:19:20 -0800

I don't think the VoiceActivityDetection setting would have any bearing on
the "vad" param. You could certainly imagine wanting to set the VAD bit in
client-mixer even when not using DTX.

IOW, I think that we should always send VAD in client-mixer. There's no
size penalty, and it's useful information for mixers.

On Thu, Jan 7, 2016 at 7:37 AM, Bernard Aboba <[email-masked]>
wrote:

> So, my question is whether "vad=on" or "vad=off" is determined by the "VoiceActivityDetection" option, or if not, whether there is a setting (e.g. "vad=on") that is always present in the offer.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Jan 2016 12:55:57 -0700

Bernard, 

Two things....

To answer your questions ... I think the controll of the V bit in rfc6464 is totally indepneded of this VoiceActivityDetection option in JS. 

We  probably need a PR for jsep to clarify this. The key thing to me is that if the VoiceActivityDetection is set to false by the JS, the browser MUST NOT do silence suppressions but must send all the audio for all packets like we would need for cases such as an E911 call or detecting modem, fax, other tones etc. I think file:///Volumes/Main2/fluffy/src/drafts/jsep/draft-ietf-rtcweb-jsep.html#rfc.section.5.2.3.4 could be clearer about that. That has nothing to do with the 

On the setting of the rfc6464 signaling for v bit, It seems to me the browser should always offer that and honor whatever is negotiated. I don't think the VoiceActivityDetection should effect this and the JS can munch the SDP to controls what happens if it wants. 

> On Jan 7, 2016, at 8:37 AM, Bernard Aboba <[email-masked]> wrote:
> 
> JSEP Section 5.2.3.4 discusses the implications of the "VoiceActivityDetection" option for the offer. 
> 
> One thing that is not covered is whether the "VoiceActivityDetection" option determines whether the client-mixer "vad" extension is set to "on" or "off".  
> 
> For example, I believe that the W3C WEBRTC WG determined that the client-mixer extension (support for which is required in RTP-Usage) should always be advertised in the offer.  RFC 6464 Section 4 gives an example of the a=extmap line: 
>