- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 23 Sep 2019 14:49:51 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes of our F2F meeting at TPAC last week are available at:
https://www.w3.org/2019/09/18-webrtc-minutes.html
https://www.w3.org/2019/09/19-webrtc-minutes.html
and copied as text below.
Dom
[1]W3C
[1] http://www.w3.org/
WebRTC TPAC F2F Day 1
19 Sep 2019
[2]Agenda
[2]
https://www.w3.org/2011/04/webrtc/wiki/September_19-20_2019#F2F_during_W3C_TPAC_2019
Attendees
Present
dom, jeff, Youenn, EricC, Harald, Orphis, Bernard,
Jan-Ivar, Henrik, Armando, Emad, Jared
Regrets
Chair
Bernard, Jan-Ivar, Harald
Scribe
youenn, steveanton, dom, dontcallmeDOM
Contents
* [3]Topics
1. [4]Agenda review
2. [5]State of the WebRTC WG
3. [6]WebRTC 1.0 Testing
4. [7]Next steps to PR for WebRTC-pc
5. [8]Issue 1764
6. [9]Issue 2121
7. [10]Screen capture
8. [11]Media capture and streams
9. [12]Media Recording
10. [13]WebRTC Stats
11. [14]issues 361/452
12. [15]issues 478/396
13. [16]issue-480/issue-472
14. [17]issue-479
15. [18]Content-Hints
16. [19]issue-2248
17. [20]issue-28
18. [21]issue-28 & issue-30
19. [22]disposing of content-hint
20. [23]DSCP API
21. [24]WebRTC-ICE
22. [25]Features at risk
23. [26]Developer feedback
24. [27]Mészáros Mihály’s Developer Feedback
25. [28]Sean’s Developer Feedback
26. [29]Silvia’s Developer Feedback
27. [30]Emil’s Developer Feedback
28. [31]“Others on the Line”: Max
* [32]Summary of Action Items
* [33]Summary of Resolutions
__________________________________________________________
<dom> [34]Meeting slides
[34]
https://docs.google.com/presentation/d/1Xprz0ElNTUWRDdX6kyp11cZ4ItTvUFUmzoXsKZdXxuU/edit#slide=id.p
<dom> ScribeNick: youenn
WebRTC F2F Thursday morning
Agenda review
State of the WebRTC WG
Slight difference between charter ending March 2020 and list of
deliverables.
Probably not able to deliver everything
Web developers want interop, it should just work
media capture main spec: 26 issues, 21 of them sticking around,
probably harder to fix.
community sense is that it works.
Going to PR requires closing bugs and validating testing.
screen capture spec
developer use it and sense is that it works.
We should get it to CR.
13 open bugs.
dom: need full horizontal review
Goal is to fix all CR blocking issues by ending of F2F
Need also to fill out TAG review.
Need an explainer for the TAG review
webrtc-pc!
32 open issues, still new ones coming in at a good pace
Bugs are smaller and smaller
<scribe> New PR target at the end of F2F
WebRTC-identity
Not much progress there
Other documents
Capture from DOM
Needs editor.
<dom> [35]https://github.com/w3c/mediacapture-fromelement/
[35] https://github.com/w3c/mediacapture-fromelement/
19 open issues, fairly old but heavy use.
Need TAG/privacy/security review and check open bugs whether
blocker or not
media recorder API
Need an editor and TAG review.
stat-identifier
scribe: spec: fairly active
depth spec: no more progress, shipped in chromium under a pref.
audio output devices: shipped in Chrome, Mozilla under a pref.
scribe: in CR
content hints: released in Chrome, works, WD
DSCP: origin trial showed mixed results, especially in private
networks
WebRTC-SVC: active interest, early in development cycle
WebRTC-ICE: Implemented in Chrome as part of QUIC experiment.
Basic stuff working.
No first WD yet.
Other W3C activity: media wg activity is relevant to WebRTC WG
WebRTC 1.0 Testing
Specs have links to tests, should allow to compute spec
coverage.
A lot of progress in tests passing in all 4 browsers.
DrAlex presenting the WPT and KITE dashboards
Simulcast testing big progress with IETF 104 and 105
hackathons.
Next steps to PR for WebRTC-pc
Chrome has mid and rid header extensions, Firefox supports rid
header extension.
Florent implemented the simulcast playground for unified plan.
Could be used as a basis for WPT.
<scribe> ACTION: Florent to investigate upstreaming his page as
WPT test
<trackbot> Created ACTION-124 - Investigate upstreaming his
page as wpt test [on Florent Castelli - due 2019-09-26].
<dom> [36]Confluence-based WebRTC Implementation tracker
[36] https://dontcallmedom.github.io/webrtc-impl-tracker/?webrtc
Plan: do a final CR containing all new changes, then no
substantive changes. Then validate testing is sufficient to go
in PR.
Goal is to go to PR by end of the year.
Issue 1764
Bernard summarizing the issue
Discussing Nils proposal.
Harald: are all codecs ok with sending, then not sending and
resending audio packets?
Opus: you need to process a few packets before outputting sound
Varun: what about doing like in mute case?
Bernard: send silence is not very clear, might change according
the negotiated parameters.
RESOLUTION: Accept Nils proposal for Issue 1764
Issue 2121
RESOLUTION: Proposal C: define retrieval of constraint
properties for getSettings but make them not modifiable
<jib> for width, height and frameRate, and aspectRatio
Issue 2230
<dom> trackbot, bye
<dom> Youenn: the host field in the ice error event exposes
private ip addresses
<dom> ... in theory it could expose private information; in
practice, it's exposing addresses that in general would have
already been exposed to the page
<dom> ... the spec opens up the possibility to use 0.0.0.0:0 if
filtering is needed
<dom> ... there is an odd case when you ask only for relay
candidates
<dom> ... we could maybe filter the host address in that case
<dom> ... returning 0.0.0.0:0 instead of null is a bit strange
<dom> ... and why is port and address in a single field?
<dom> jan-ivar: maybe either than null, an empty string?
<dom> harald: the advantage of 0.0.0.0:0 is that it is
parseable by an IP address parser
<dom> ... e.g. if you log the errors
<dom> dom: since it has been very recently deployed, this is
purely a cosmetic design decision at this point
<dom> jan-ivar: empty string sounds good to me
<dom> henrik: we should be consistent with what we have in
RTCIceCandidate
RESOLUTION: empty string for null value, split port separately
<dom> (make port nullable, find name for host)
<dom> ISSUE 2257
Same certificate for workers so postMessage is potentially
useful.
Bernard: for forking, same certificate for different endpoints,
potentially in a worker thread.
RESOLUTION: Keep the existing ability and put a note about the
security issue.
postMessaging a certificate might be useful in a data channel
context so it might be a useful feature.
Screen capture
Jan-Ivar is listing the list of improvements done in the past
year.
Issue 60: Define Tab Capture
RESOLUTION: Use 'browsing context' as tab capture
Need horizontal review, fill out privacy and security
questionnaire. Need explainer.
Discussion about tab capture. Mozilla might want to capture the
active tab (without the other tabs like a window would leak).
Potential clarification: make it clear that tab capture might
change the the tab dynamically.
Media capture and streams
Issue 554
Harald: lack of spec actually makes it harder to implement.
Definitely interested and would like to push implementation
when there is a spec.
Jan-Ivar: Would be good to have for our own testing.
<dom> Issue 565
RESOLUTION: allow browsers not to fire devicechange event if
the list of device is actually the same
<dom> make this mandatory behavior unless this can be
privacy-neutral
Issue 584
Safari has potential issues with downscale restriction in
multiple apps accessing to camera.
RESOLUTION: Remove upscale from the proposed sentence and merge
Issue 608
Media Recording
ISSUE 139
Proposal is to always re-encode when mimeType is set and not
reencode otherwise.
RESOLUTION: Consensus for Proposal B
Issue 167
RESOLUTION: Start with proposal B, Jan-Ivar to create a PR,
promise based.
Need to discuss multiple track change cases.
WebRTC Stats
<dom> henrik: [implementation status] - the gaps in
implementation reflects more structural changes in where the
stats are exposed rather than the lack of available metrics
<dom> ScribeNick: steveanton
youenn: wpt should be enough for simple counters
... WebKit has some basic wpt validation that can be upstreamed
hbos: chrome does not have detailed tests at the integration
level
<dom> ACTION: Youenn to upload simple validation tests from
webkit to WPT
vr000m: explore simple tests in wpt then go forward from there
bernard: new model better supports SVC
issues 361/452
general agreement to proceed
issues 478/396
youenn: can already get this information from the api
jib: opposed for stats reporting things that the app already
knows
hbos: need mid to correlate stats objects with the m= section
(proposal 2)
jib: adding transceiver stats requires adding transceiver id
bernard: snapshotting state would help correlate stats with
changes in signaling
jib: worried about bloat in stats objects
vr000m: two issues (1) do we need a transceiver dictionary (2)
once we have that do we need additional data e.g. direction
jib: could also just put a mid on sender/receiver
vr000m: stats are used largely for debugging
agreement that mid should be mti
jib: opposed to direction/currentDirection more than opposed to
transceiver stats
general agreement to add transceiver stats to with mid/sender
id/receiver id only
<vr000m> also codecIds?
issue-480/issue-472
bernard and jib sold on proposal 1
vr000m: like events since we then we don't have to shim
peerconnection
youenn: prefer that stats expose replace track info directly
rather than through events
jib: see that shimming replacetrack is not ideal, but does work
vr000m: not providing something like onstatsended leaves a gap
with replacetrack that has been known for 2 years
youenn: onreplacetrack should be a follow up and not in 1.0
RESOLUTION: remove onstatsended and continue discussion about
an event to notify when significant stats change
issue-479
RESOLUTION: consensus to remove track stats (moving it to
obsolete section)
Content-Hints
issue-2248
issue-28
issue-28 & issue-30
hta: more sympathetic to normative action than before
hbos: agree that we should only ship APIs that are well defined
jib: trying to be agnostic about what to do next, just want to
provide feedback
bernard: where to specify normative hints for content hints?
jib/hta/bernard: content hints should be a follow up spec that
covers the integrations with other specs
youenn: is a high level api that influences control knobs the
right design?
... if hints are crucial for an application then we should
specify the behavior
jib: hints can be useful since they are simpler than turning
all the knobs
disposing of content-hint
bernard: some advanced codecs have content capture tools (hevc,
av1)
... useful to expose this for e.g. screensharing
RESOLUTION: advance but not at high priority
DSCP API
RESOLUTION: proposal 1
(Move Priority to DSCP document, harmonize, keep experimenting)
WebRTC-ICE
youenn: not as opposed to adopt as last year, but not sure if
it's the right time (don't want to delay from finishing 1.0)
dom: shouldn't be a high cost to the working group
generally no opposition to adopting the spec
bernard: do the p2p mesh folks want datachannels in workers?
dom: does this expose new security & privacy risks?
peter: need to think through the risks more
bernard: forking has been thought through, but not in the
context of p2p mesh
... who is asking for ICE forking? just dht people?
hbos: why is ice forking hard?
bernard: each transport has different candidate pair statuses,
API changes (dtls transport) to facilitate forking, more ICE
optimizations that are more important for forking
... might not be that complex if you started from scratch and
knew what you wanted to do
peter: two code bases which would need to implement forking
no current plans for either to do it
hta: not hearing much enthusiasm in the room
jib: more use cases could motivate implementors
bernard: p2p mesh is an issue in the use cases repo
Features at risk
<dom> ScribeNick: dom
JIB: Overview of feature at risks: there are about 12 features
marked at risk
... I'll present some of our options to manage features at
risks
... if no implementation and no dev interest, we remove the
feature
... if no implementation but dev interest, we can leave the
spec if we expect imminent implementation
... if not, we can move to an extension
... We conducted an analysis of what was implemented where to
identify which features should be at risk
... focusing on things with fewer than 2 implementations and no
clear implementation commitment
... for instance, rollback has only 1 implementation, but there
is one ongoing
... [reviewing the list to check for possible mistakes]
... VoiceActivityDetection is at risk - only one (buggy)
implementation
Bernard: does it negotiate CN?
Henrik: checking it now
JIB: OauthCredential is not implemented anywhere
Henrik: re VoiceActivityDetection, what Chrome ships can be
done via setParameters
JIB: pranswer - 2 impl
Youenn: not sure our implementation should really count; this
may need to be marked at risk
JIB: we're interested in implementing, but it hasn't been a
priority
... QoS priority is at risk
... icecandidateerror?
Henrik: it's shipped in Chrome and old-Edge
Youenn: will need to be tested
JIB: RTCError isn't shipped yet anywhere
Henrik: we have the basic plumbing, but finalizing it is more
work than you would expect
Dom: how confident are we about this landing any time? any risk
of later interop?
Youenn: pages could break if they've started relying on
existing error names
... Should we instead specify what currently ships (if
interoperable)
Bernard: we designed RTCError to provide more details
... Errors in operational services occur at a very high rate
Dom: let's plan on discussing this tomorrow
JIB: simulcast-aware stats?
Henrik: spec is ready
JIB: commitment from Edge and Firefox to implement
... Are they MTI?
Henrik: adopting them means changing the behavior in a
backwards incompatible way
JIB: statsended we decided to remove
... setStreams?
Orphis: in Chrome
Youenn: planned for us
JIB: us too, by the end of the year
... RTCPeerConnectionIceEvent.url is only in Safari - any other
implementation commitment?
Bernard: I think we would want to do this for Edge/Chrome
JIB: planned for us, but probably not by EOY
... Identity - in Stockholm, we reached a compromise to split
identity into a separate spec
... there are still a few normative ref from -pc to -identity
... but still only one implementation
... are we ok with that situation?
Youenn: I think it should be marked at risk
JIB: getDefaultIceServices - not implemented should be marked
at risk
... we have 28 MTI stats that show as not implemented in WPT,
but probably just because they've moved recently and the tests
need to be updated
Youenn: Firefox and Chrome are the two main implementor for
stats
Armando: does the tests need an update?
JIB: no, but implementations need to catch up with stats
... I don't think they should be in jeopardy because they moved
... Firefox doesn't have track-stats yet
Dom: is the list of MTI stats in -pc correct?
Henrik: it will have to be updated to match the results of our
stats discussion tomorrow
JIB: OAuthCredentials?
RESOLUTION: move OAuthCredential to extension
JIB: negotiate for rtcpTransport? (issue 3 in spec)
Harald: impl got nuked, too confusing
RESOLUTION: negotiate for rtcpTransport to be removed
JIB: VoiceActivityDetection?
Henrik: over taken by events, let's remove
RESOLUTION: remove VoiceActivityDetection
JIB: getDefaultIceServers()?
Youenn: move to an extension and wait for a proponent to push
for an improved proposal
JIB: getSUpportedAlgorithms?
RESOLUTION: remove getSupportedAlgorithms
JIB: SendParameters.priority?
Orphis: remove
RESOLUTION: remove SendParameters.priority and prioritytype
enum
... remove ReceiveParameters.encodings
Orphis: (they're pointless)
JIB: EncodingParameters.dtx?
Bernard: nobody implements
Orphis: available via SDP munging for OPUS in Chrome
Harald: let's drop it
Orphis: this applies to ptime and codecpayloadtype should also
be at risk
Henrik: a large discussion: there would be a need to control
the codecs you sent beyond what to do with negotiation today
Orphis: right now, it's read-only
Henrik: codecpayloadtype could be removed and brought back
later if there is demand in an extension
Orphis: ptime isn't implemented, not clear demand
RESOLUTION: Remove .dtx, .ptime, .codecpayloadtype from
EncodingParameters
... datachannel priority to be removed
Dom: Identity - mozilla sole implementor?
JIB: we want to see it adopted
... the peerIdentity steps could perhaps be moved to -identity
Henrik: moving out is an editorial question
... but the real question is whether identity is part of 1.0
Youenn: no plan to implement in 1.0; interested in the field,
but not sure this is the right solution
... there may be other issues that need to be addressed with
higher priority
... we don't want to be tied to that particular solution at
this time
RESOLUTION: migrate the remaining identity steps to -identity
Dom: we also need to figure out how to re-integrate isolated
media streams into our normative sphere
Developer feedback
<inserted> ScribeNick: dontcallmeDOM
Mészáros Mihály’s Developer Feedback
Mészáros: TURN for NRENs, Higher education & research.
scribe: Global turn server, the goal is to keep media traffic
in their network.
... Multi-tenant TURN is not possible without Long Term
Credential.
... Working on co-located TURN, working on implementation in
Firefox and possibly Chrome.
... Why not just add these three attributes, it would require
little changes to mechanisms. Should be little effort.
... We should consider keeping OAuth until we have alternatives
for TURN.
Dom: Pressure to reach 1.0. Moving this out of the spec does
not mean it is not going to happen, but we will need people to
get involved to make sure spec and implementations are
maintained. And write tests. We will likely reach out to you
about future involvement.
Youenn: You say the existing API is not great, but is the
current API working as a hack?
Mészáros: We use short term credentials and the behave TURN
REST draft but I am not happy with this, there is a better way.
We rely on the non-standard.
Harald: Do any of the browsers implement the behave TURN REST?
How do you do this with current implementations of browsers?
Mészáros: It would be nice to have one authentication server
anywhere.
Sean’s Developer Feedback
Sean: I work on a go implementation of WebRTC. A lot of people
come with complaints about how they want their ICE to work.
There’s so much going on.
... Small businesses want to use WebRTC but they have to use
other things because they have restricted port ranges.
... Once a week someone complains about addIceCandidate before
setRemoteDescription. Can we catch them or throw them in a
queue? Re-order operations? It would save new developers a lot
of time.
Jan-Ivar: The reason you can’t do addIceCandidate in a
different order they could end up in the first offer.
Sean: That’s only an issue for the first offer.
Jan-Ivar: There’s no limitation you can only negotiate once.
There’s a race potential: If you get a remote offer you have to
set it before you await other operations.
Sean: In the real world this is a problem. People cache
candidates for example. Jan-Ivar: You shouldn’t cache.
... Closing (message+code) can be done by sending a final
message
... Ability to deny a data channel based on data channel name.
Not sure if enough value.
... Media via DataChannels is being more and more popular. Lack
of HW acceleration.
... Some people would be happy with more latency for less
packet loss? Both reliable and unreliable data channels. People
want more flexibility than they can get with the current APIs.
... People want setCodecPreferences; SDP munging is painful.
I’m tired of seeing people munge SDP and it blows up in their
face.
... Lack of CipherSuite choices: people want HW acceleration.
... addStream vs addTrack vs addTransceiver. Causes headaches,
people don’t understand what’s going on.
... Provisional offers/answer: Do we need them? I have to
answer questions about it all the time.
... Can we make API simpler for porting to other languages like
not having to use strings?
... Tor Snowflake uses DataChannels and spend a lot of time
removing the ability to fingerprint. Can we set ciphers?
Silvia’s Developer Feedback
Silvia: Mostly complaining about things from a WebRTC
Telemedicine developer’s point of view. We have to jump through
hoops to make things interoperable! Chrome, Firefox, Safari.
... We have to recommend people not to use Firefox due to worse
media quality. High-level report; don’t know why this is the
case.
... We use the new API, using multiple streams works well in
Chrome but not in Firefox. Interop problems.
... We sometimes hit decoding problems.
... Stats is a pain point: new getStats has much less
information than the old one. Plus different browsers have
different implementations of the standard getStats API as well.
... The API doesn’t really tell you whether or not media is
flowing. We look at time of the media elements, usually it
works but not always. It’s hard to detect playback issues. Any
suggestions on finding out if media disappeared? The browser
thinks the connection is there but we’re not receiving any
frames.
... Data channels for video: You don’t have to deal with a lot
of complexities. Interoperability is combinatorially more
complicated when you have to deal with all the different
versions of the specs.
Emil’s Developer Feedback
Emil: Will put in slides after the meeting. I have three items:
... One of the pain points: messiness around switching “plans”
(Plan B vs Unified Plan). This does not solve any problems for
us; it would be good to ensure this could be done gradually.
Like SSRCs vs RIDs: it would be good to have SSRCs in the
meantime while SFUs upgrade to RID support.
... We keep hearing not all windows are sharable on windows.
... As an SFU provider we want to assist call quality. Take
audio quality for example, there’s really no way for us to
improve audio quality. For video it’s simpler but limited. We
would like to be able to add our own FEC to PeerConnection.
Those hooks discussed a few years ago by Justin would be really
nice. We would like to do End-to-End Encryption. Harald’s
proposal is compatible with our goals. We would like hooks on
the client side at diff
erent points in the pipeline to add our own logic.
“Others on the Line”: Max
Max: Lack of granular port ranges.
... How do we add hooks on different parts of the stack. We are
excited about these things becoming part of the standard and
... Currently stuck on Plan B and is experiencing difficulties
shipping Unified Plan, especially around SSRCs vs RIDs, but
plan is to move to MID/RID multiplexing architecture.
Harald: Do you think we should revive SSRC signaling? Should we
revive the draft that I wrote?
Max: Yes. Loudly adding a plus one!
Summary of Action Items
[NEW] ACTION: Florent to investigate upstreaming his page as
WPT test
[NEW] ACTION: Youenn to upload simple validation tests from
webkit to WPT
Summary of Resolutions
1. [37]Accept Nils proposal for Issue 1764
2. [38]Proposal C: define retrieval of constraint properties
for getSettings but make them not modifiable
3. [39]empty string for null value, split port separately
4. [40]Keep the existing ability and put a note about the
security issue.
5. [41]Use 'browsing context' as tab capture
6. [42]allow browsers not to fire devicechange event if the
list of device is actually the same
7. [43]Remove upscale from the proposed sentence and merge
8. [44]Consensus for Proposal B
9. [45]Start with proposal B, Jan-Ivar to create a PR, promise
based.
10. [46]remove onstatsended and continue discussion about an
event to notify when significant stats change
11. [47]consensus to remove track stats (moving it to obsolete
section)
12. [48]advance but not at high priority
13. [49]proposal 1
14. [50]move OAuthCredential to extension
15. [51]negotiate for rtcpTransport to be removed
16. [52]remove VoiceActivityDetection
17. [53]remove getSupportedAlgorithms
18. [54]remove SendParameters.priority and prioritytype enum
19. [55]Remove .dtx, .ptime, .codecpayloadtype from
EncodingParameters
20. [56]migrate the remaining identity steps to -identity
[End of minutes]
--------------------
[1]W3C
[1] http://www.w3.org/
WebRTC TPAC F2F Day 2
20 Sep 2019
Attendees
Present
Emad, Aramando, Henrik, Jan-Ivar, Bernard, Youenn,
DrAlex, Orphis, Dom, Harald, EricC, weiler, tara,
Joshue108
Regrets
Chair
Harald, Bernard, Jan-Ivar
Scribe
hta1, hta, dom, dontcallmeDOM, dralex, dralex_,
steveanton
Contents
* [2]Topics
1. [3]WebRTC-SVC
2. [4]Privacy Issues
3. [5]WebRTC NV Use Cases
4. [6]Joint meeting with Accessible Platform Architecture
Working Group
5. [7]WebRTC stats
6. [8]Issue 398/PR 495
7. [9]issue-401
8. [10]issue-443
9. [11]issue-440
10. [12]issue-448
11. [13]issue-358
12. [14]issue-376
13. [15]issue-377
14. [16]Content-Hints API
15. [17]Conclusions and next steps
* [18]Summary of Action Items
* [19]Summary of Resolutions
__________________________________________________________
<hta1> scribenick: hta1
WebRTC-SVC
Starting with SVC structures.
Decision: Remove drawings from SVC spec; AV1 is normative for
drawings. SVC spec is normative for strings; make that clear.
Aboba - Presenting on custom scalability modes.
If a different mode is required, we could define a new mode
string. Assigning a new number in AV1 requires AOMedia
cooperation.
aboba: we could define strings that reference AV1 custom
scalability modes if we can define scalability structures using
SS.
could also define modes in prose in this spec.
<scribe> ACTION: aboba to Add a paragraph to the table to
describe considerations for adding new values to the table of
modes.
<scribe> "new modes can be added to this table by updating this
specification".
issue 14 - orphis: Encoding parameters for spatial layers
active, maxBitrate and maxFramerate probably make sense.
<hta> youenn: what's the usecase for active?
<hta> aboba: There's a difference between dropping a layer and
changing a mode.
<hta> amit: should we value consistency over conformance? Users
will use modes that they dont understand, and will be
surprised.
<hta> hta: People who don't understand the codec and mode they
are using are going to have a hard time anyway.
<hta> orphis: <shows list of possible proposals>
<hta> youenn: a mode would have a sensible default, used when
you don't specify anything.
<hta> scribenick:hta
<scribe> scribenick: hta
(discussing case of bitrate allocation - is percentage right,
or is numbers right?)
<weiler> where are minutes being taken?
here. writing slowly.
dr alex: scaleResolutionDownBy is independent for each layer in
simulcast? several: yes, it is relationship to source, not
between streams
This discussion will continue at 2PM.
Privacy Issues
<dontcallmeDOM> ScribeNick: dom
<dontcallmeDOM> ScribeNick: dontcallmeDOM
[welcoming PING representatives]
Youenn: we want good privacy reviews on our planned Proposed
Rec of WebRTC-PC and Media Capture
... Issue 612
... enumerateDevices is a way for Web pages to enumerate all
capture devices (camera, mics, speakers)
... it's meant to help implement a device picker to select a
particular camera and microphone
... that information is gated by device-info permission
... without that permission, you don't get labels, but you get
persistent device ids and that entails the exact number and
type of devices
... our proposal is to hide more info before device-info is
granted, only expose generic/low-fingerprint profile of devices
... In Safari, we've looked at Web pages - most device pickers
are only available after getUmserMedia was granted
... one proposal was to expose one device of each type - that's
what Safari ships; it is Web compatible
... (we haven't received negative feedback since we've shipped
this a month ago)
... this still exposes whether a given device has access to a
capture device of given type
... A second proposal is to lie: pretend there is one capture
device of each given type
... you get the truth after the gUM prompt
... this fixes the fingerprinting issue of the 1st proposal
... a 3rd proposal would be to push enumerateDevices() behind a
prompt
... but that feels difficult to implement (how to make it
meaningful to the user)
... also feels hard from a compat perspective
PeterSnyder: is this actually used for fingerprinting?
Youenn: yes
EricC: and it is used for that a lot more than for getting
cameras
Harald: hangout chat will display a camera icon only if it
finds a camera in its chat mode
... proposal 2 would make that distinction useless
Youenn: this would require a change in the UX of hangout
Sam: what is the deviceId? free-form string?
Youenn: a UUID
JIB: per-origin
Youenn: double-keyed
Dom: what if new capture device types come in?
Harald: e.g. depth cameras which are in the pipeline
Youenn: I think this would have to move to a picker-based
approach
Armando: lying about devices availability doesn't sound right
EricC: in Safari, we default to the list of capture devices
that are tied to that platform (e.g. 2 cams, 1 mic on iPhones)
... if there are additional devices, we pretend they come up
upon gUM grant
PeterSnyder: would moving to Proposal 3 in the long term be a
possibility?
EricC: what kind of questions would make sense for Option 3?
Sam: one anti-pattern is asking permissions as soon as users
get in
... I've been that in WebRTC land in particular when it comes
to asking for cameras
<weiler> axk wei
Bernard: part of the reason this happens is because fewer and
fewer features are available before you ask for permissions
... e.g. network topology detection is gated to camera
permission today
... and as this causes problems to real deployment
JIB: I doubt going to permission prompt is a direction any
browser would go to
... plus, a permission prompt for enumerating devices would be
just before another prompt
Harald: I'm hearing moving towoard Proposal 1 would be
acceptable to all implementors
<hta> we have 5 issues to get through. We have 45 minutes.
<hta> (now we have 22 minutes)
Harald: Proposal 2 is more controversial
PeterSnyder: I do have concerns with proposal 1
Dom: for clarity, all these proposals are improvements over the
current situation
PeterSnyder: Proposal 2 then lies about the reality? when does
the truth get revealed?
EricC: upon getting permission access for capture
... the list of devices would be updated (with an event) to
reflect the reality
PeterSnyder: OK, that sounds appealing
Youenn: Proposal 1 is clearly implementable (shipped in Safari)
... Proposal 2 will break some web sites e.g. if they adapt
their default UI to what's available
... hearing Proposal 1 is a good implementors target in the
short term; Proposal 2 is appealing to PING
... and appealing to some implementors
... Issue 607 - persistence of device ids
... can be used for cross-site tracking
... deviceIds have already some level of protection
... they're not exposed to cross-origin iframes
... they can also be hidden from iframes with device-info
... A proposal is to partition id if other persistent partition
id
... Difficult in making it mandatory today given existing
deployment
... Re partitioning, Safari double-keys all persistent data
based on the nesting of browsing context (à la iframe) origins
... (existing discussions in this space for http cache in fetch
spec, and in service workers)
<Orphis> Double keyed HTTP cache:
[20]https://github.com/whatwg/fetch/issues/904
[20] https://github.com/whatwg/fetch/issues/904
PeterSnyder: the concern is when there is no double-keying
Youenn: the goal is to go there; the question is what to do
when double-keying is not available
PeterSnyder: I'm suggesting double-keying the seeding of UUID
... to partition the deviceId space
JIB: this breaks the case of embedded e.g. Hangout
... and it doesn't actually buy privacy until indexeddb is
partitioned
PeterSnyder: PING would be happy with requiring partitioning of
deviceID
Youenn: Issue 374
... WebRTC Stats is exposing for network types from users
... e.g. if the user is on wifi, ethernet, vpn, etc
... mostly for debugging purposes
... the problem is that it exposes fingerprinting surface,
expose privacy-sensitive information
... and could be mis-used for user-hostile adaptation
... A first proposal would be to move this to an extension spec
where special mitigations could be discussed
... Second: we have already a note about this, nothing needs to
be done
... Third: we hide this behind the getUserMedia
Emad: what's the fingerprinting surface?
Youenn: you can monitor the different types of network a user
has been using, when, detect patterns
@@@: different behavior on different type of networks sounds
useful
Dom: not what WebRTC Stats are meant for - they're meant for
monitoring or debugging
<hta> Amit = amit
Dom: UX adaption would need to use e.G. network information
<weiler> debugging should be "special case", right? hence it's
okay to not provide the info in the ordinary case?
Peter: Network Error Logging is another API that reports
information on network traffic
Dom: does it?
Peter: would need to double check
Harald: Proposal A & B doesn't actually change what's shipping
... C about guidance feels more important
Dom: let's distinguish between the practical considerations of
where to define the mitigations
... I think I'm hearing interest in investigating mitigations
in more details
Amit: we could fuzz the network types (e.g. network1, network2,
...)
... could help distinguishing cases of debugs
Peter: I think that rather guidance is specific rules
Bernard: in practice, vpn isn't all that useful
Christine: vpn are actually forbidden in some countries, this
shouldn't be broadcasted
Harald: vpn should just be deleted from what I'm hearing
... we still need to look at how critical networkType is for
debugging purposes given the concerns we're hearing
Henrik: other exposed stats given maybe more actionable (e.g.
bitRate)
Dom: proposal D would then be removing it
<weiler> again, isn't debugging a special case, such that it
could be hidden behnd a permission?
Peter: PING would support removing it if that's not too big a
loss, gating it would be the fallback
<Amit> we might want qingsi to give an opinion as an expert on
ice debugging
Youenn: Issue 83 in audio output
... We're currently limited to which speakers can be used for
audio output
... as it linked to getting permission to getting audio input
... We would like to offer an in-chrome picket to give access
to new devices
Armando: we're supportive
Peter: without knowing the details, this sounds interesting
Youenn: thank you for all your help
Peter: thank you for having us
WebRTC NV Use Cases
<scribe> ScribeNick: dralex
<dontcallmeDOM> ScribeNick: dralex_
scribing
14 open issues
++> issues 53
advanced codec cap.
HW acc available?
min and max resolutions
support for sic ?
svc?
use case B : identify the implementation (good for debugging,
and good for adaptation to a specific implementation features)
in some cases, supported profiles and resolutions are different
for HW and software
right now the encoder is assigned during negotiation, and then
the bandwidth adaptation might change the setting outside of
what the current encoder/decoder can do.
youenn express concerns that from the developer point of view,
it can become real hard to handle.
Action item, henrik will ....
describe one or two uses cases, and then make a PR.
JY: it seems to be presented the wrong wa: API first, instead
of use case first. Can you please write the use corresponding
use case?
florent: we would like to be in a case where we get helpful
error messages to act on it.
dom: that really underline the need to write a user story
JY: we have to be careful not to augment the fingerprinting
surface.
--------------
issue 37: requirement for secure web conferencing.
second attempt since the meeting in Stockholm
PR 49 submitted by Cullen
google'se mad suggested that we look at the MLS security
architecture as an inspiration to write our requirements here
discussion about req. N25 to N29 from MLS
proposal to put that in the secure conferencing requirements
dom recommandatie is to only fuse one of this use case.
mozilla position is to merge in the untrusted case, and needs
to think about the trusted case.
google is considering very seriously considering the trusted
case and implementing it
apple is not in favour of anything, but shows interest in the
result of investigations from mozilla and google.
---------------
charte expire in march 2020
since a new or updated charter would need 3 months to be
approved, we would need a WG-approved draft by EoY
obvious charter changes:
2 secs out (webrtc 1.0, GUM)
update deliverable timelines
<dralex> scribbing
<dralex> open questions: what do we do with existing
deliverables
<dralex> is there any new deliverable?
<dralex> how long do we need.
<dralex> what should we do about the maintenance of webrtc 1.0
and GUM
<dralex> what about webrtc-stats and webrtc identity
<dralex> there is also a leak of editor
<dralex> some people and/or organization need to provide
ressources
<dralex> other specs are stable but much earlier in the
standardisation process.
<dralex> image capture, depth cameras
<dralex> content hints
work could only continue with an identified editor, AND a
commitment by a browser vendor to implement
emerging use cases
more granular objects
webrtc insertable
end-to-end encryption
<dralex__> really only three ways forward:
<dralex__> in re-chartered group: only with editor and
implementor commitment
<dralex__> in incubation (CG group)
<dralex__> or moved to another group (media group)
<dralex__> it seems that the consensus is to keep the 3
activities together (maintenance, dev, ....)
<dralex__> the question is open about whether some media
capture should follow web transport, webcodec.
<dralex__> the consensus seems that there is a strong link with
web transport and webcoedc (peter), but as it would dbe the
same implementor as the main webrtc spec, it would make sense
to keep things together
<dralex__> interest from mozilla and apple on image capture
<dralex__> no strong interest in depth
<dralex__> stop discussion here because of time questions
Joint Meeting with Accessible Platform Architecture Working Group
[21]Minutes taken in APA meeting minutes
[21] https://www.w3.org/2019/09/20-apa-minutes.html#item02
<jcraig> Web RTC group. Dom said to come to the #APA room (the
physical room) in Kashi 1F right behind registration
<dom__> [minutes for this meeting taken on #apa]
<
<vr000m> trying to join the meeting URL is this URL correct:
[22]https://meet.google.com/vxf-wgai-rjn
[22] https://meet.google.com/vxf-wgai-rjn
<hta> we're having a meeting in a different room at the moment,
so I guess nobody's watching the "allow to join" button.
<hta> will be back soon.
<vr000m> ok
<dontcallmeDOM> scribenick: steveanton
WebRTC stats
RESOLUTION: issue-365 & issue-470: just remove
RTCMediaStreamStats (move to obsolete)
... issue-437: agreement for proposal
Issue 398/PR 495
jib: like these members better than those proposed for
transceiver stats
hbos: already have per-encoding stats in the outbound-rtp
stats, only thing missing is the rid
... if that's the only thing we want we should just add it to
outbound-rtp
... but if we want more information then we should have a
separate dictionary
jib: prefer to just add rid to outbound-rtp
vr000m: if getParameters exists then rid should be sufficient
... no concrete objection to just adding rid but would prefer
consulting with the list to see if the other stats are useful
jib: might be a bug in getParameters -- every time you call it
transaction id changes
... which means you don't know if the transaction id changes
because of getParameters or an outside change
dom: let's discuss that in a separate issue
RESOLUTION: add rid and confirm that we don't want to add
encoding parameters
issue-401
bernard: along with svc we have a new weird thing of simulcast
without different rtp streams
... when talking about layer we should identify the layer and
the mode of the layer
hbos: might just have an index into the svc config array
bernard: need temporal id & spatial id to identify a layer.
byte for each would work for every known codec
vr000m: are sid's numbers?
bernard: possible to have sid represent a simulcast encoding
... could have multiple simulcast encodings in the same rtp
ssrc
... need to describe better what the layer is and what mode it
is
vr000m: we should discuss this in another meeting since it's
getting complicated
... can the svc mode change?
bernard: yes, and would affect the number of layers and stats
hbos: does the basic idea of having one svc stats object per
layer with these attributes make sense?
bernard: definitely want to know aggregate stats for the entire
stream
... not sure if per-layer loss is useful for congestion control
... might use the stats to realize after the fact that your
behavior was sub-optimal
hta: framesSent and bytesSent seem like enough
jib: inconsistency ... width vs. frameWidth
hbos: because in that dictionary there's a mix of audio and
video
... frame was added to make it clear it's for video
RESOLUTION: henrik should go write a PR and we'll add it
issue-443
vr000m: isn't the endpoint aware of the deviation of the stats
from expectation?
hbos: need to define expectations
vr000m: can do the math. expectation is inter-frame stats
hbos: over what time frame?
alex: expectation changes with sfu
hbos: expectation can change during call (60 fps to 30 fps)
... shouldn't be reported a glitch
alex: can only define a glitch by knowing what was sent by the
peer
hta: calculate the sum of intervals and sum of squares of
intervals? allows you to calculate mean and std dev
jib: before or after the jitter buffer?
... on the sender side there's feature creep
... where we have stats on the sources
... worried we are adding stats for playback
hbos: this has to do with received
... but will be visible in playback
... don't intend to measure how the video tag works
alex: need to decouple which part of the video playback
pipeline is being measured
jib: if we have a stat that reports glitches but don't have any
rendering glitches because jitter buffer smoothed it over is
confusing
alex: don't want to force the app to query stats too often
hbos: need to be specific with how glitch is defined
... getting the feeling we should move towards proposal B
jib: why do we care about glitches before jitter buffer?
hbos: only care about after jitter buffer
... some existing stats are confusing about this though
varun: want the stat for after the jitter buffer
alex: fps is supposed to be stable by segment
... there will be a step at some point
... can we report the stability of fps within segments?
hbos: that would show up as a glitch in proposal B
alex: can infer expectation by assuming fps is constant for a
period of time
hta: sum of square intervals allows you to calculate the
average/std dev of arrival rate between any two samples
hbos: that sounds like it would solve the problem
RESOLUTION: add a stat which is the sum of the square of inter
frame intervals
issue-440
hbos: implementation has separate booleans but they are not
independent
alex: but this isn't implementation specific
armax: proposal C: remove?
hbos: chrome reports cpu over bandwidth if both are true
discussion about what is the use case for this stat
varun: cpu limiting is interesting when it happens
... bandwidth limiting we have a lot of other stats
... cpu is influenced by unknown things on the system
hbos: issue is not about having this stat but what to do when
both value apply
jib: if the value is none you can infer that quality is fine
hbos: any value other than none indicates you are not sending
the resolution you want
jib: this is sender side only?
hbos: yes
varun: none can also be source limited
... e.g. if the camera can't capture enough pixels because it's
dark
jib: can add the string both
hbos: didn't want to add a vector since you might infer that a
false element indicates no problem
... e.g. if you are so cpu limited that you can't use all your
bandwidth
jib: if there's a situation where both are limiting, can you
improve quality by improving either or both?
hbos: likely limited by both
varun: other implementations may know what is the real limiting
factor
... so proposal b seems better
hbos: should we say that if the implementation can't
distinguish just say bandwidth?
issue-448
RESOLUTION: go with the proposed solution
issue-358
jib: what would happen after an ice restart finishes?
... when do the stats go away?
hbos: they go away automatically with no event
jib: changing the id would mean they are not referenced
anywhere
... so you can infer they are no longer in use
hbos: they would not exist in that case
jib: what if you are in the middle of an ice restart?
varun: depends on behavior of make before break
... e.g. if you are still using the transport
... you would see both objects
jib: how would you know what is the old or new one if both are
present?
hta: we should do proposal a
hbos: proposals are not mutually exclusive
RESOLUTION: go with proposal a and continue discussing proposal
b
issue-376
steveanton: problem is this is an instantaneous stat not a
cumulative stat
hbos: can't think of a good cumulative stat
steveanton: could do minimum rtt
hta: building on a standard stat that is part of the protocol
machine is ok
hbos: continue looking for a cumulative stat we could use
RESOLUTION: try to find a cumulative stat that could be used
for rtt, but otherwise rely on spinfo_srtt -- regardless we
want sctp rtt
issue-377
hta: cwindow is orthogonal to bufferedAmount
steveanton: cwindow is useful for application logic, but
getstats is not a good place to put it
RESOLUTION: don't add to stats but discuss adding a dedicated
API (not in 1.0)
<dontcallmeDOM> scribenick: dontcallmeDOM
Content-Hints API
Harald: Recalling previous discussions, words that could
characterize the contents of a track. Close discussion by
Harald rewriting draft based on ideas presented at the meeting,
including MUST/SHOULD.
Jan-Ivar: And clarify track.clone().
Harald: Need to specify that it copies all the attributes.
Jan-Ivar: And add guidance for future specs.
Wrap-up
[Armando was able to name the bird.]
Conclusions and next steps
Harald: We have a number of PRs to write now. We have a number
of documents that need wider review, including TAG. Shepherding
needed. We have gone through features at risk; the proposal is
to delete all features marked in the document, except for
maxFramerate and RTCError.
Youenn: RTCError needs more discussion? It should be marked
feature at risk but let’s not delete it for now.
Bernard: PR requirement is to have better error handling, so
removing it from the spec might create more work than it saves.
It needs more discussion.
Harald: Move the normative identity dependency steps to the
extension spec.
Youenn: E.g. call a NO-OP function or step that is overridden
by the extension spec.
Bernard: Isolation...?
Jan-Ivar: Both webrtc-pc and media recorder has language like
MUST NOT record if there are isolated properties. We can move
this out of identity to mediacapture-main.
Youenn: It should stay in the identity spec for now because it
is a feature at risk.
Harald: Action item on Jan-Ivar to sort out isolation property
(suggesting to move it?).
Youenn: Let’s do ICE forking later on as an extension spec or
iterative work.
Harald: Developer feedback; people still not happy with Unified
Plan switch and consistency. More SSRC nosies.
... SVC, keep it simple please. We only support predefined
modes.
... Privacy issues. Details in the minutes.
Youenn: Now is the time for PRs.
Harald: We did not get to issue 68.
Youenn: Don’t know what to do about that, need to pick up
discussions and figure out what to do there.
Harald: NV use cases. Split conferencing PR in two, Jan-Ivar
will go back to Firefox to clarify if we can merge the
untrusted JavaScript case. We should want this, but there is
disagreement if we should support trusted JavaScript use case.
... Rechartering. Not too much to say about that. Discussed
options, no clear answer. Should we incubate specs? WIll
discuss further.
... Stats again. And then we ran out of time.
Summary of Action Items
[NEW] ACTION: aboba to Add a paragraph to the table to describe
considerations for adding new values to the table of modes.
Summary of Resolutions
1. [23]issue-365 & issue-470: just remove RTCMediaStreamStats
(move to obsolete)
2. [24]add rid and confirm that we don't want to add encoding
parameters
3. [25]henrik should go write a PR and we'll add it
4. [26]add a stat which is the sum of the square of inter
frame intervals
5. [27]go with the proposed solution
6. [28]go with proposal a and continue discussing proposal b
7. [29]try to find a cumulative stat that could be used for
rtt, but otherwise rely on spinfo_srtt -- regardless we
want sctp rtt
8. [30]don't add to stats but discuss adding a dedicated API
(not in 1.0)
[End of minutes]
Received on Monday, 23 September 2019 12:49:57 UTC