- 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