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