Re: Review of May 15 WebRTC 1.0 draft

Thanks Taylor for your review.

Stefan

On 07/06/17 10:19, Taylor Brandstetter wrote:
> Apologies for being late, but I finished reviewing this WebRTC draft as
> requested: https://w3c.github.io/webrtc-pc/archives/20170515/webrtc.html
>
>
> I reviewed the spec in its entirety, and was also reviewing it against
> the requirements provided in the following IETF documents:
>
> __
>
> https://tools.ietf.org/html/rfc7478
> <https://tools.ietf.org/html/rfc7478> and https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch>
>
>
> Overall, the major issues I see right now are:
>
>   * There's ambiguity around exactly what "setLocalDescription" and
>     "setRemoteDescription" do, with regards to
>     transceivers/senders/receivers/transports. When exactly are the
>     transport objects created? What parameters do the senders/receivers
>     end up with, and when? If a sender was already present with
>     application-modified parameters, how do they change in response to
>     SRD/SLD? Things like that. We also don't cover all the
>     transceiver-related effects.
>   * It's unclear how tracks/senders/receivers relate to each other now,
>     and when track-related events fire. The problem is described very
>     well by Jan-Ivar's blog
>     post: https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/
>
> None of these are new issues though. And we're discussing that last
> issue at the virtual interim tomorrow.
>
> I also found around ~100 small or editorial issues, but I'm putting off
> reporting them on GitHub for now since so many are duplicates of issues
> other people are filing. I'll work on sorting through them and reporting
> the non-duplicates in the coming weeks, but none seemed too concerning.
>
> From reviewing the requirements, here are the ones that appeared
> potentially problematic to me (mostly the same things Bernard also noticed):
>
>
>
>      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”.
>
>
>
>      F17             The communication session must survive across a
>                       change of the network interface used by the
>                       session.
>
>
>
> The application can always do an ICE restart when this occurs. But I
> don't know if that counts. To really consider this requirement
> satisfied, I feel we’d need some of the proposed extensions to ICE such
> as “continual gathering”, “candidate removal”, “renomination”, etc. And
> these could end up requiring API changes.
>
>
>
>      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?
>
>
>
>      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.
>
>
>     API Requirement: The API MUST provide a mechanism for the requesting
>     JS to indicate which of these forms of permissions it is requesting.
>
>
> "Forms of permission" here is referring to "one-time" vs "persistent"
> permissions. The GUM spec doesn't provide a mechanism for JS to control
> this though; it leaves it at the browser's discretion. Right? "This
> specification does not dictate whether or not granting permission
> results in a stored permission."

Received on Wednesday, 7 June 2017 14:10:44 UTC