- 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