23:34:30 RRSAgent has joined #webrtc 23:34:30 logging to https://www.w3.org/2019/09/18-webrtc-irc 23:34:35 RRSAgent, make log public 23:34:41 Meeting: WebRTC TPAC F2F Day 1 23:34:46 RRSAgent, this meeting spans midnight 23:34:53 Chair: Bernard, Jan-Ivar, Harald 23:34:54 Present+ 23:36:17 Present+ jeff 23:36:42 ericc has joined #webrtc 23:38:25 Present+ Youenn, EricC, Harald, Orphis, Bernard, Jan-Ivar, Henrik, Armando, Emad 23:40:00 -> https://docs.google.com/presentation/d/1Xprz0ElNTUWRDdX6kyp11cZ4ItTvUFUmzoXsKZdXxuU/edit#slide=id.p Meeting slides 23:40:09 jib has joined #webrtc 23:40:48 youenn has joined #webrtc 23:40:51 ScribeNick: youenn 23:40:56 WebRTC F2F Thursday morning 23:40:59 Topic: Agenda review 23:42:41 hhan__ has joined #webrtc 23:42:48 Topic: State of the WebRTC WG 23:44:20 Slight difference between charter ending March 2020 and list of deliverables. 23:44:30 Probably not able to deliver everything 23:44:53 Web developers want interop, it should just work 23:46:53 media capture main spec: 26 issues, 21 of them sticking around, probably harder to fix. 23:48:20 community sense is that it works. 23:48:35 Jared has joined #webrtc 23:49:50 Going to PR requires closing bugs and validating testing. 23:50:10 screen capture spec 23:50:44 developer use it and sense is that it works. 23:51:05 We should get it to CR. 23:51:23 13 open bugs. 23:51:36 dom: need full horizontal review 23:51:54 Goal is to fix all CR blocking issues by ending of F2F 23:52:20 Need also to fill out TAG review. 23:53:29 Need an explainer for the TAG review 23:53:44 webrtc-pc! 23:54:34 32 open issues, still new ones coming in at a good pace 23:55:12 Bugs are smaller and smaller 23:57:14 New PR target at the end of F2F 23:57:25 WebRTC-identity 23:57:55 Not much progress there 23:59:26 Present+ Jared 00:02:02 jeff_ has joined #webrtc 00:04:11 Other documents 00:04:22 Capture from DOM 00:04:54 Needs editor. 00:05:00 https://github.com/w3c/mediacapture-fromelement/ 00:05:22 19 open issues, fairly old but heavy use. 00:06:17 Need TAG/privacy/security review and check open bugs whether blocker or not 00:06:32 media recorder API 00:06:49 Need an editor and TAG review. 00:07:42 stat-identifier 00:07:54 ... spec: fairly active 00:09:22 depth spec: no more progress, shipped in chromium under a pref. 00:10:12 audio output devices: shipped in Chrome, Mozilla under a pref. 00:10:31 ... in CR 00:10:33 anssik has joined #webrtc 00:11:00 content hints: released in Chrome, works, WD 00:12:33 DSCP: origin trial showed mixed results, especially in private networks 00:13:25 WebRTC-SVC: active interest, early in development cycle 00:14:13 WebRTC-ICE: Implemented in Chrome as part of QUIC experiment. Basic stuff working. 00:14:20 No first WD yet. 00:15:59 Other W3C activity: media wg activity is relevant to WebRTC WG 00:17:51 TOPIC: WebRTC 1.0 Testing 00:20:33 inamori_ has joined #webrtc 00:23:28 hta1 has joined #webrtc 00:24:48 Specs have links to tests, should allow to compute spec coverage. 00:27:10 A lot of progress in tests passing in all 4 browsers. 00:32:33 DrAlex presenting the WPT and KITE dashboards 00:35:24 inamori_ has joined #webrtc 00:35:45 Simulcast testing big progress with IETF 104 and 105 hackathons. 00:47:16 Topic: Next steps to PR for WebRTC-pc 00:51:10 Chrome has mid and rid header extensions, Firefox supports rid header extension. 00:52:30 Florent implemented the simulcast playground for unified plan. 00:52:38 Could be used as a basis for WPT. 00:53:32 ACTION: Florent to investigate upstreaming his page as WPT test 00:53:32 Created ACTION-124 - Investigate upstreaming his page as wpt test [on Florent Castelli - due 2019-09-26]. 00:55:05 -> https://dontcallmedom.github.io/webrtc-impl-tracker/?webrtc Confluence-based WebRTC Implementation tracker 00:59:51 Max_ has joined #webrtc 01:02:38 Plan: do a final CR containing all new changes, then no substantive changes. Then validate testing is sufficient to go in PR. 01:03:17 Goal is to go to PR by end of the year. 01:05:59 jianjunz has joined #webrtc 01:29:32 horiuchi has joined #webrtc 01:32:22 horiuchi has joined #webrtc 01:39:01 hhan has joined #webrtc 01:40:58 jib has joined #webrtc 01:41:10 Topic: Issue 1764 01:41:21 Bernard summarizing the issue 01:42:10 Gooroomee has joined #webrtc 01:42:32 Discussing Nils proposal. 01:42:49 Harald: are all codecs ok with sending, then not sending and resending audio packets? 01:43:24 Opus: you need to process a few packets before outputting sounds? 01:43:30 s/sounds?/sound/ 01:43:47 jeff has joined #webrtc 01:44:34 Varun: what about doing like in mute case? 01:45:07 Bernard: send silence is not very clear, might change according the negotiated parameters. 01:48:17 RESOLUTION: Accept Nils proposal for Issue 1764 01:48:37 Topic: Issue 2121 01:57:08 horiuchi has joined #webrtc 01:59:15 RESOLUTION: Proposal C: define retrieval of constraint properties for getSettings but make them not modifiable 01:59:48 for width, height and frameRate, and aspectRatio 02:00:13 Issue 2230 02:00:21 trackbot, bye 02:00:21 trackbot has left #webrtc 02:00:39 Youenn: the host field in the ice error event exposes private ip addresses 02:01:05 ... in theory it could expose private information; in practice, it's exposing addresses that in general would have already been exposed to the page 02:01:17 jeff has joined #webrtc 02:01:19 ... the spec opens up the possibility to use 0.0.0.0:0 if filtering is needed 02:01:28 ... there is an odd case when you ask only for relay candidates 02:01:39 ... we could maybe filter the host address in that case 02:01:52 ... returning 0.0.0.0:0 instead of null is a bit strange 02:02:01 ... and why is port and address in a single field? 02:02:42 horiuchi_ has joined #webrtc 02:02:43 nakakura has joined #webrtc 02:03:40 jan-ivar: maybe either than null, an empty string? 02:03:56 harald: the advantage of 0.0.0.0:0 is that it is parseable by an IP address parser 02:04:15 ... e.g. if you log the errors 02:06:28 ericc has joined #webrtc 02:07:37 dom: since it has been very recently deployed, this is purely a cosmetic design decision at this point 02:07:47 jan-ivar: empty string sounds good to me 02:08:37 henrik: we should be consistent with what we have in RTCIceCandidate 02:09:12 RESOLUTION: empty string for null value, split port separately 02:10:59 (make port nullable, find name for host) 02:11:08 ISSUE 2257 02:14:01 Same certificate for workers so postMessage is potentially useful. 02:14:37 Bernard: for forking, same certificate for different endpoints, potentially in a worker thread. 02:19:41 RESOLUTION: Keep the existing ability and put a note about the security issue. 02:21:08 Zakim has left #webrtc 02:21:24 postMessaging a certificate might be useful in a data channel context so it might be a useful feature. 02:24:40 Topic: Screen capture 02:25:34 Jan-Ivar is listing the list of improvements done in the past year. 02:26:15 Issue 60: Define Tab Capture 02:27:36 Riju has joined #Webrtc 02:27:53 RESOLUTION: Use 'browsing context' as tab capture 02:29:48 Need horizontal review, fill out privacy and security questionnaire. Need explainer. 02:31:15 Discussion about tab capture. Mozilla might want to capture the active tab (without the other tabs like a window would leak). 02:32:48 Potential clarification: make it clear that tab capture might change the the tab dynamically. 02:35:20 horiuchi has joined #webrtc 02:36:08 Topic: Media capture and streams 02:36:12 Issue 554 02:41:42 Harald: lack of spec actually makes it harder to implement. Definitely interested and would like to push implementation when there is a spec. 02:41:55 Jan-Ivar: Would be good to have for our own testing. 02:42:11 Issue 565 02:45:13 RESOLUTION: allow browsers not to fire devicechange event if the list of device is actually the same 02:46:21 make this mandatory behavior unless this can be privacy-neutral 02:46:25 Issue 584 02:46:50 Max_ has joined #webrtc 02:50:58 horiuchi has joined #webrtc 02:53:05 Safari has potential issues with downscale restriction in multiple apps accessing to camera. 02:53:58 RESOLUTION: Remove upscale from the proposed sentence and merge 02:56:18 Issue 608 02:58:29 jianjunz has joined #webrtc 03:01:57 jeff_ has joined #webrtc 03:02:08 Riju has joined #Webrtc 03:02:42 ericc has joined #webrtc 03:02:57 Topic: Media Recording 03:03:01 ISSUE 139 03:06:39 Proposal is to always re-encode when mimeType is set and not reencode otherwise. 03:09:36 yuj has joined #webrtc 03:10:19 RESOLUTION: Consensus from Proposal B 03:10:25 s/from/for/ 03:10:48 nakakura has joined #webrtc 03:11:28 Issue 167 03:13:52 horiuchi has joined #webrtc 03:15:22 horiuchi_ has joined #webrtc 03:19:50 RRSAgent, draft minutes 03:19:50 I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dom 03:19:55 RESOLUTION: Start with proposal B, Jan-Ivar to create a PR, promise based. 03:20:14 Need to discuss multiple track change cases. 03:20:19 RRSAgent, draft minutes 03:20:19 I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dom 03:31:25 horiuchi has joined #webrtc 03:39:51 horiuchi has joined #webrtc 03:44:06 horiuchi_ has joined #webrtc 04:09:07 yj has joined #webrtc 04:09:14 inamori_ has joined #webrtc 04:14:00 ericc has joined #webrtc 04:19:36 yj has joined #webrtc 04:21:28 jeff_ has joined #webrtc 04:23:55 hta has joined #webrtc 04:29:21 nakakura has joined #webrtc 04:29:43 Topic: WebRTC Stats 04:30:20 henrik: [implementation status] - the gaps in implementation reflects more structural changes in where the stats are exposed rather than the lack of available metrics 04:30:46 jib has joined #webrtc 04:31:11 steveanton has joined #webrtc 04:31:14 ScribeNick: steveanton 04:32:50 horiuchi has joined #webrtc 04:33:12 youenn: wpt should be enough for simple counters 04:33:37 youenn: WebKit has some basic wpt validation that can be upstreamed 04:33:56 hbos: chrome does not have detailed tests at the integration level 04:34:28 ACTION: Youenn to upload simple validation tests from webkit to WPT 04:34:33 vr000m: explore simple tests in wpt then go forward from there 04:34:59 ericc has joined #webrtc 04:36:04 hhan has joined #webrtc 04:37:17 horiuchi has joined #webrtc 04:38:39 bernard: new model better supports SVC 04:38:53 jeff has joined #webrtc 04:39:23 topic: issues 361/452 04:40:12 general agreement to proceed 04:40:20 topic: issues 478/396 04:41:06 youenn: can already get this information from the api 04:41:16 jib: opposed for stats reporting things that the app already knows 04:41:42 hbos: need mid to correlate stats objects with the m= section (proposal 2) 04:42:44 jib: adding transceiver stats requires adding transceiver id 04:43:37 bernard: snapshotting state would help correlate stats with changes in signaling 04:44:39 jib: worried about bloat in stats objects 04:46:03 vr000m: two issues (1) do we need a transceiver dictionary (2) once we have that do we need additional data e.g. direction 04:46:44 jib: could also just put a mid on sender/receiver 04:48:38 vr000m: stats are used largely for debugging 04:52:59 agreement that mid should be mti 04:54:41 jib: opposed to direction/currentDirection more than opposed to transceiver stats 04:55:17 general agreement to add transceiver stats to with mid/sender id/receiver id only 04:55:42 also codecIds? 04:55:56 TOPIC: issue-480/issue-472 04:59:00 bernard and jib sold on proposal 1 05:01:02 Riju_ has joined #webrtc 05:01:21 vr000m: like events since we then we don't have to shim peerconnection 05:02:24 youenn: prefer that stats expose replace track info directly rather than through events 05:02:41 Amit has joined #webrtc 05:06:01 jib: see that shimming replacetrack is not ideal, but does work 05:09:12 vr000m: not providing something like onstatsended leaves a gap with replacetrack that has been known for 2 years 05:09:49 youenn: onreplacetrack should be a follow up and not in 1.0 05:11:37 jeff has joined #webrtc 05:12:44 jianjunz has joined #webrtc 05:13:40 RESOLUTION: remove onstatsended and continue discussion about an event to notify when significant stats change 05:13:47 TOPIC: issue-479 05:18:15 RESOLUTION: consensus to remove track stats (moving it to obsolete section) 05:18:36 TOPIC: Content-Hints 05:23:02 TOPIC: issue-2248 05:28:41 TOPIC: issue-28 05:33:08 TOPIC: issue-28 & issue-30 05:33:11 horiuchi has joined #webrtc 05:35:57 horiuchi_ has joined #webrtc 05:36:23 hta: more sympathetic to normative action than before 05:36:55 hbos: agree that we should only ship APIs that are well defined 05:38:08 Gooroomee has joined #Webrtc 05:38:09 jib: trying to be agnostic about what to do next, just want to provide feedback 05:38:55 bernard: where to specify normative hints for content hints? 05:39:59 jib/hta/bernard: content hints should be a follow up spec that covers the integrations with other specs 05:40:34 youenn: is a high level api that influences control knobs the right design? 05:43:26 Riju has joined #webrtc 05:43:33 youenn: if hints are crucial for an application then we should specify the behavior 05:44:17 jib: hints can be useful since they are simpler than turning all the knobs 05:45:46 TOPIC: disposing of content-hint 05:46:53 bernard: some advanced codecs have content capture tools (hevc, av1) 05:47:02 bernard: useful to expose this for e.g. screensharing 05:47:29 RESOLUTION: advance but not at high priority 05:47:43 horiuchi has joined #webrtc 05:48:03 TOPIC: DSCP API 05:53:03 RESOLUTION: proposal 1 05:53:22 (Move Priority to DSCP document, harmonize, keep experimenting) 05:53:33 TOPIC: WebRTC-ICE 05:53:58 horiuchi_ has joined #webrtc 05:54:50 horiuchi has joined #webrtc 05:56:37 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) 05:57:06 dom: shouldn't be a high cost to the working group 05:58:22 generally no opposition to adopting the spec 06:07:18 horiuchi has joined #webrtc 06:10:25 bernard: do the p2p mesh folks want datachannels in workers? 06:12:12 dom: does this expose new security & privacy risks? 06:12:23 peter: need to think through the risks more 06:12:43 bernard: forking has been thought through, but not in the context of p2p mesh 06:17:57 bernard: who is asking for ICE forking? just dht people? 06:18:02 hbos: why is ice forking hard? 06:20:00 bernard: each transport has different candidate pair statuses, API changes (dtls transport) to facilitate forking, more ICE optimizations that are more important for forking 06:20:44 bernard: might not be that complex if you started from scratch and knew what you wanted to do 06:21:35 peter: two code bases which would need to implement forking 06:21:39 no current plans for either to do it 06:22:35 hta: not hearing much enthusiasm in the room 06:22:36 jianjunz has joined #webrtc 06:22:51 jib: more use cases could motivate implementors 06:23:42 bernard: p2p mesh is an issue in the use cases repo 06:25:44 inamori_ has joined #webrtc 06:28:00 horiuchi_ has joined #webrtc 06:32:32 horiuchi_ has joined #webrtc 06:37:20 ericc has joined #webrtc 06:43:38 Topic: Features at risk 06:43:41 ScribeNick: dom 06:50:58 JIB: Overview of feature at risks: there are about 12 features marked at risk 06:51:07 sugi has joined #webrtc 06:51:15 ... I'll present some of our options to manage features at risks 06:51:28 .. if no implementation and no dev interest, we remove the feature 06:51:47 ... if no implementation but dev interest, we can leave the spec if we expect imminent implementation 06:51:53 ... if not, we can move to an extension 06:52:03 inamori_ has joined #webrtc 06:52:31 ... We conducted an analysis of what was implemented where to identify which features should be at risk 06:52:42 ... focusing on things with fewer than 2 implementations and no clear implementation commitment 06:53:11 ... for instance, rollback has only 1 implementation, but there is one ongoing 06:53:25 ... [reviewing the list to check for possible mistakes] 06:55:16 ... VoiceActivityDetection is at risk - only one (buggy) implementation 06:55:22 Bernard: does it negotiate CN? 06:55:26 steveanton has joined #webrtc 06:55:28 Henrik: checking it now 06:55:41 Amit has joined #webrtc 06:56:13 JIB: OauthCredential is not implemented anywhere 06:56:42 Henrik: re VoiceActivityDetection, what Chrome ships can be done via setParameters 06:56:55 JIB: pranswer - 2 impl 06:57:12 Youenn: not sure our implementation should really count; this may need to be marked at risk 06:57:20 JIB: we're interested in implementing, but it hasn't been a priority 06:57:34 ... QoS priority is at risk 06:57:49 ... icecandidateerror? 06:58:12 Henrik: it's shipped in Chrome and old-Edge 06:58:28 Youenn: will need to be tested 06:59:03 JIB: RTCError isn't shipped yet anywhere 06:59:40 Henrik: we have the basic plumbing, but finalizing it is more work than you would expect 07:02:12 Dom: how confident are we about this landing any time? any risk of later interop? 07:02:26 Youenn: pages could break if they've started relying on existing error names 07:02:53 ... Should we instead specify what currently ships (if interoperable) 07:03:22 Bernard: we designed RTCError to provide more details 07:04:17 ... Errors in operational services occur at a very high rate 07:06:10 Dom: let's plan on discussing this tomorrow 07:06:37 JIB: simulcast-aware stats? 07:06:41 Henrik: spec is ready 07:06:50 JIB: commitment from Edge and Firefox to implement 07:08:59 ... Are they MTI? 07:09:22 Henrik: adopting them means changing the behavior in a backwards incompatible way 07:10:02 JIB: statsended we decided to remove 07:10:12 ... setStreams? 07:10:20 Orphis: in Chrome 07:10:29 Youenn: planned for us 07:10:37 JIB: us too, by the end of the year 07:11:19 ... RTCPeerConnectionIceEvent.url is only in Safari - any other implementation commitment? 07:11:36 Bernard: I think we would want to do this for Edge/Chrome 07:11:51 JIB: planned for us, but probably not by EOY 07:12:26 JIB: Identity - in Stockholm, we reached a compromise to split identity into a separate spec 07:12:37 ... there are still a few normative ref from -pc to -identity 07:12:42 ... but still only one implementation 07:13:03 ... are we ok with that situation? 07:13:18 Youenn: I think it should be marked at risk 07:13:35 JIB: getDefaultIceServices - not implemented should be marked at risk 07:13:57 ... 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 07:14:16 Youenn: Firefox and Chrome are the two main implementor for stats 07:14:25 Armanda: does the tests need an update? 07:14:31 s/a:/o:/ 07:14:48 JIB: no, but implementations need to catch up with stats 07:15:12 ... I don't think they should be in jeopardy because they moved 07:15:23 ... Firefox doesn't have track-stats yet 07:16:43 Dom: is the list of MTI stats in -pc correct? 07:17:59 Henrik: it will have to be updated to match the results of our stats discussion tomorrow 07:18:13 JIB: OAuthCredentials? 07:18:37 RESOLUTION: move OAuthCredential to extension 07:20:06 JIB: negotiate for rtcpTransport? (issue 3 in spec) 07:20:32 Harald: impl got nuked, too confusing 07:20:48 RESOLUTION: negotiate for rtcpTransport to be removed 07:21:00 JIB: VoiceActivityDetection? 07:21:08 Henrik: over taken by events, let's remove 07:21:16 RESOLUTION: remove VoiceActivityDetection 07:21:48 JIB: getDefaultIceServers()? 07:22:05 Youenn: move to an extension and wait for a proponent to push for an improved proposal 07:22:18 JIB: getSUpportedAlgorithms? 07:22:26 RESOLUTION: remove getSupportedAlgorithms 07:22:43 JIB: SendParameters.priority? 07:22:49 Orphis: remove 07:23:13 RESOLUTION: remove SendParameters.priority and prioritytype enum 07:23:25 RESOLUTION: remove ReceiveParameters.encodings 07:23:30 Orphis: (they're pointless) 07:23:40 JIB: EncodingParameters.dtx? 07:23:51 Bernard: nobody implements 07:24:00 Orphis: available via SDP munging for OPUS in Chrome 07:24:15 Harald: let's drop it 07:24:49 Orphis: this applies to ptime and codecpayloadtype should also be at risk 07:25:27 Henrik: a large discussion: there would be a need to control the codecs you sent beyond what to do with negotiation today 07:25:34 Orphis: right now, it's read-only 07:26:04 Henrik: codecpayloadtype could be removed and brought back later if there is demand in an extension 07:26:15 Orphis: ptime isn't implemented, not clear demand 07:26:40 RESOLUTION: Remove .dtx, .ptime, .codecpayloadtype from EncodingParameters 07:26:49 RESOLUTION: datachannel priority to be removed 07:28:36 Dom: Identity - mozilla sole implementor? 07:28:44 JIB: we want to see it adopted 07:29:32 ... the peerIdentity steps could perhaps be moved to -identity 07:29:58 Henrik: moving out is an editorial question 07:30:08 ... but the real question is whether identity is part of 1.0 07:30:22 Youenn: no plan to implement in 1.0; interested in the field, but not sure this is the right solution 07:30:37 ... there may be other issues that need to be addressed with higher priority 07:31:10 ... we don't want to be tied to that particular solution at this time 07:32:14 RESOLUTION: migrate the remaining identity steps to -identity 07:33:20 Dom: we also need to figure out how to re-integrate isolated media streams into our normative sphere 07:34:18 RRSAgent, draft minutes 07:34:18 I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dom 07:35:14 Topic: Developer feedback 07:35:22 jib has joined #webrtc 07:36:32 horiuchi has joined #webrtc 07:37:46 Riju has joined #webrtc 07:39:56 jianjunz has joined #webrtc 07:46:21 horiuchi has joined #webrtc 08:22:37 lgrahl has joined #webrtc 08:32:45 horiuchi has joined #webrtc 08:34:37 horiuchi has joined #webrtc 08:34:47 dontcallmeDOM has joined #webrtc 08:37:36 horiuchi_ has joined #webrtc 08:41:17 horiuchi has joined #webrtc 08:42:19 hta has joined #webrtc 08:43:43 Topic: Mészáros Mihály’s Developer Feedback 08:43:43 Mészáros: TURN for NRENs, Higher education & research. 08:43:43 ... Global turn server, the goal is to keep media traffic in their network. 08:43:43 ... Multi-tenant TURN is not possible without Long Term Credential. 08:43:43 ... Working on co-located TURN, working on implementation in Firefox and possibly Chrome. 08:43:44 ... Why not just add these three attributes, it would require little changes to mechanisms. Should be little effort. 08:43:47 ... We should consider keeping OAuth until we have alternatives for TURN. 08:43:49 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. 08:43:53 Youenn: You say the existing API is not great, but is the current API working as a hack? 08:43:55 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. 08:43:58 Harald: Do any of the browsers implement the behave TURN REST? How do you do this with current implementations of browsers? 08:44:01 Mészáros: It would be nice to have one authentication server anywhere. 08:44:05 Topic: Sean’s Developer Feedback 08:44:07 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. 08:44:10 ... Small businesses want to use WebRTC but they have to use other things because they have restricted port ranges. 08:44:13 ... 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. 08:44:16 Jan-Ivar: The reason you can’t do addIceCandidate in a different order they could end up in the first offer. 08:44:19 Sean: That’s only an issue for the first offer. 08:44:21 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. 08:44:24 Sean: In the real world this is a problem. People cache candidates for example. Jan-Ivar: You shouldn’t cache. 08:44:27 Sean: Closing (message+code) can be done by sending a final message 08:44:29 ... Ability to deny a data channel based on data channel name. Not sure if enough value. 08:44:31 ... Media via DataChannels is being more and more popular. Lack of HW acceleration. 08:44:35 ... 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. 08:44:38 ... People want setCodecPreferences; SDP munging is painful. I’m tired of seeing people munge SDP and it blows up in their face. 08:44:41 ... Lack of CipherSuite choices: people want HW acceleration. 08:44:43 ... addStream vs addTrack vs addTransceiver. Causes headaches, people don’t understand what’s going on. 08:44:45 ... Provisional offers/answer: Do we need them? I have to answer questions about it all the time. 08:44:47 ... Can we make API simpler for porting to other languages like not having to use strings? 08:44:49 ... Tor Snowflake uses DataChannels and spend a lot of time removing the ability to fingerprint. Can we set ciphers? 08:44:52 Topic: Silvia’s Developer Feedback 08:44:54 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. 08:44:57 ... 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. 08:45:00 ... We use the new API, using multiple streams works well in Chrome but not in Firefox. Interop problems. 08:45:02 ... We sometimes hit decoding problems. 08:45:06 ... 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. 08:45:09 ... 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. 08:45:13 ... 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. 08:45:16 Topic: Emil’s Developer Feedback 08:45:18 Emil: Will put in slides after the meeting. I have three items: 08:45:20 ... 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. 08:45:24 ... We keep hearing not all windows are sharable on windows. 08:45:26 ... 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 08:45:31 erent points in the pipeline to add our own logic. 08:45:35 Topic: “Others on the Line”: Max 08:45:37 Max: Lack of granular port ranges. 08:45:39 ... How do we add hooks on different parts of the stack. We are excited about these things becoming part of the standard and 08:45:42 ... 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. 08:45:45 Harald: Do you think we should revive SSRC signaling? Should we revive the draft that I wrote? 08:45:47 Max: Yes. Loudly adding a plus one! 08:45:49 i/Topic: Mészáros/ScribeNick: dontcallmeDOM 08:45:51 RRSAgent, draft minutes 08:45:51 I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dontcallmeDOM 08:47:13 Agenda: https://www.w3.org/2011/04/webrtc/wiki/September_19-20_2019#F2F_during_W3C_TPAC_2019 08:47:19 RRSAgent, draft minutes 08:47:19 I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dontcallmeDOM 08:53:53 achronop has joined #webrtc 08:58:39 horiuchi has joined #webrtc 09:00:52 achronop has joined #webrtc 09:02:04 horiuchi has joined #webrtc 09:02:31 horiuchi has joined #webrtc 09:03:13 achronop has joined #webrtc 09:04:54 mp__ has joined #webrtc 09:05:40 mp__ has joined #webrtc 09:23:19 horiuchi has joined #webrtc 10:00:26 inamori_ has joined #webrtc