Re: Requirements review notes

On 5/3/2017 6:26 PM, Bernard Aboba wrote:
>
> 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 
> andhttps://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?
>

Yes.

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

This sounds like it could use some minor reference-smithing to resolve.

>    ----------------------------------------------------------------
>    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?

Well... only if such a separate API does or is believed will exist. If 
this didn't go any further than the discussion, then we don't have an 
actual answer for this, just "there could be an answer, someday, 
maybe".  If you argue that RETURN (or user-level STUN/TURN config) 
covers this, you may have a point as it doesn't speak to who or how 
they're provided.

>    ----------------------------------------------------------------
>    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 
> <https://groups.google.com/forum/#%21topic/discuss-webrtc/KWo9VwIcBXA>

Yes, I consider this covered - the browser can do so, and nothing in the 
spec precludes it.

>    ----------------------------------------------------------------
>    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?

I'm not sure what this requirement was meant to imply.... direct 
modification in JS?  that it has voice activity level support?  That 
something (WebAudio) can affect the activity level?
Perhaps it becomes more clear from the context of discussion that led to 
this...

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam