Requirements review notes

At the WebRTC WG virtual interim yesterday, I volunteered to review the current WebRTC-PC draft (https://rawgit.com/w3c/webrtc-pc/master/webrtc.html ) 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

In general, most of the requirements appear to be satisfied by the current WebRTC-PC draft, with some handled in other documents such as Media Capture & Streams, WebAudio or various IETF documents.
Some notes below:

  ----------------------------------------------------------------
   F7      When there are both incoming and outgoing audio
           streams, echo cancellation must be made
           available to avoid disturbing echo during
           conversation.
[BA] Currently echo cancellation is supported in Media Capture
(see: https://www.w3.org/TR/mediacapture-streams/#def-constraint-echoCancellation ).
Is this sufficient?

   ----------------------------------------------------------------


  F17             The communication session must survive across a

                   change of the network interface used by the

                   session.



[BA] The WebRTC-PC specification supports ICE restart, so could

be said to support this requirement from an API perspective.

However, performance against this requirement is largely determined by

IETF STUN/TURN/ICE specifications.  Looking over the STUN/TURN/ICE

references, some updates might be appropriate: RFC 5245 is referenced,

but not RFC 5245bis, there is no reference to TURN mobility (RFC 8016), etc.



   ----------------------------------------------------------------

   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).



[BA] One aspect of this (STUN/TURN server discovery) was discussed

in https://github.com/w3c/webrtc-pc/issues/941 . However, rather

than adding API surface for STUN/TURN server discovery, it

was noted that WebRTC-PC could permit STUN/TURN servers supplied by

a separate API to be added. So can we say this is satisfied?



   ----------------------------------------------------------------

   F21             The browser must be able to send streams and

                   data to a peer in the presence of firewalls that only

                   allow traffic via an HTTP Proxy, when firewall policy

                   allows WebRTC traffic.



[BA] WebRTC-PC references

https://tools.ietf.org/html/draft-ietf-rtcweb-transports , which includes

HTTP Proxy support as an optional capability.  While the ICE WG has been

discussing TLS candidates (e.g.

https://tools.ietf.org/html/draft-martinsen-ice-tls-candidates ) that

work is not yet an IETF WG work item so it would be somewhat

premature to add support for it in WebRTC-PC.



   ----------------------------------------------------------------

   F27     The browser must be able to apply spatialization

           effects to audio streams.



[BA] Though there is no API surface in WebRTC-PC, applications

appear to be supporting this by combining WebAudio and WebRTC:

http://smus.com/copresence-webvr/

https://groups.google.com/forum/#!topic/discuss-webrtc/KWo9VwIcBXA



   ----------------------------------------------------------------



   F29     The browser must be able to change the

           voice activity level in audio streams.



[BA] WebRTC-PC supports the voiceActivityDetection

flag. We also have audioLevel and voiceActivityFlag attributes (both

read-only) and the dtx attribute in RTCRtpEncodingParameters.

Does that cover everything implied by this requirement?

   ----------------------------------------------------------------