W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2017

Re: Review of May 15 WebRTC 1.0 draft

From: Randell Jesup <randell-ietf@jesup.org>
Date: Wed, 7 Jun 2017 09:53:37 -0400
To: public-webrtc@w3.org
Message-ID: <a74f643f-7303-826e-1a0a-2adb8d824264@jesup.org>
On 6/7/2017 4:14 AM, Taylor Brandstetter wrote:
>
>      F20           The browser must support the use of STUN and TURN
>                       servers that are supplied by entities other than
>                       the web application (i.e., the network provider).
>
> "defaultIceServers" somewhat accomplishes this. But the application 
> still must opt in to using the default ICE servers. This goes against 
> the spirit of the use case, which is “an enterprise wants allWebRTC 
> traffic to go through its TURN server.” Not just “traffic from 
> applications that opt in to using defaultIceServers”.
>

reTURN would provide this (depending on whether you feel this should 
replace/override TURN servers provided by the application, which given 
the above comment I imagine you would).
Firefox does provide a config option that admins could use to provide 
default ICE server(s), but I don't think it replaces 
application-provided servers.  However, this is a requirement on the 
browser to support it in some manner -- admin/pref type interfaces I 
don't think are commonly specced other than "the browser/user should be 
able to".

>      A1              The web API must provide means for the
>                       application to ask the browser for permission
>                       to use cameras and microphones as input devices
>                       and to have access to the local file system.
>
> Just a question about this requirement: why does the application need 
> access to the file system? Am I misinterpreting this?
>

Not sure where this came from... archaeology on the archives?

>      A19             The web API must provide means for the web
>                       application to indicate the type of audio signal
>                       (speech, audio) for audio stream(s) / stream
>                       component(s).
>
> Is this satisfied by the ability to disable voice activity detection? 
> This sounds a lot like MediaStreamTrack content hints 
> <https://wicg.github.io/mst-content-hint/>. Maybe we could consider 
> adding that feature to WebRTC 1.0.
>

We need either that and/or a hint on the RTPSender or transceiver. If 
it's on the track, you have to add controls/logic around WebAudio.  
Voice Activity doesn't cover this, IMHO, unless we overload that (which 
I don't advise) -- this was targeted at supporting voice vs non-voice 
inputs (such as music, or sound from a video that may have non-speech in 
it), with the idea that the browser can adjust the Opus/etc bandwidth 
settings.  Firefox doesn't even negotiate VAD/CN currently, BTW.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
Received on Wednesday, 7 June 2017 13:54:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC