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

RE: Requirements review notes

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 4 May 2017 09:04:37 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <VI1PR0701MB27332B291B29B912AB25F5C7C9EA0@VI1PR0701MB2733.eurprd07.prod.outlook.com>
For some unknown reason I did not get this mail (or the response from 
Randell), however I found it in the public-webrtc archive.

Some comments from the perspective of being one of the authors of 
https://tools.ietf.org/html/rfc7478 and https://tools.ietf.org:

I agree to most things. When we wrote the requirement spec we considered 
that all available web api's can be used not only the ones we define 
(and we would not be able to set up any webrtc session without being 
able to load a page, or send and receive seesion descriptions and ICE 
candidates). So use of the audio api for spatialization (F27) is fine in 
my view. Likewise that echo cancellation (F7) is part of 
mediacapture-main (in fact the req document was largely developed before 
we split out mediacapture-main into its own document).

For F21 the fact that ICE is supported is enough.

I'd say ICE restart will be enough for F17.

F29 is clearly not captured in the right way. What was intended was to 
enable the app to scale up/down samples of the different audio streams 
before mixing (to compensate if one participant has a very sensitive 
mike for example).

Also, I think a review versus the API requirements (A1 - A26) would be 
good. After all that's the focus in this group.

Br,
Stefan



From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Wed, 3 May 2017 22:26:28 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: 
<BY2PR21MB003514C89483CB28A73919CCEC160@BY2PR21MB0035.namprd21.prod.outlook.com>

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?

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

Received on Wednesday, 3 May 2017 22:27:04 UTC

     This message: [ Message body ]
     Next message: Bernard Aboba via GitHub: "[webrtc-pc] Issue 1: Key 
shortening"
     Previous message: Roman Shpount: "Re: Suggested resolution of Issue 
849: Specify an AllowUnverifiedMedia RTCConfiguration property"
     Next in thread: Randell Jesup: "Re: Requirements review notes"
     Reply: Randell Jesup: "Re: Requirements review notes"

     Mail actions: [ respond to this message ] [ mail a new topic ]
     Contemporary messages sorted: [ by date ] [ by thread ] [ by 
subject ] [ by author ]
     Help: [ How to use the archives ] [ Search in the archives ]

This archive was generated by hypermail 2.3.1 : Wednesday, 3 May 2017 
22:27:05 UTC
Received on Thursday, 4 May 2017 09:05:45 UTC

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