Review of May 15 WebRTC 1.0 draft

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 and 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 all WebRTC 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."