15:04:02 <RRSAgent> RRSAgent has joined #webrtc
15:04:07 <RRSAgent> logging to https://www.w3.org/2026/03/24-webrtc-irc
15:04:07 <Zakim> Zakim has joined #webrtc
15:04:13 <dom> Chairs: jan-ivar, guido; youenn
15:04:17 <dom> s/;/,/
15:04:29 <dom> Recording is starting
15:04:29 <dom> Recording: https://www.youtube.com/watch?v=TilVQOs8WPY
15:04:34 <dom> Meeting: WebRTC March 2026 meeting
15:04:44 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/March_24_2026
15:04:59 <dom> Slideset: https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/
15:05:59 <dom> Present+ BartoszHabrajski, Guido, Harald, Jan-Ivar, KacperWasniowski, PeterT, SunShin, TimP, Youenn, Dom
15:06:11 <dom> Present+ ThomasNGuyen
15:06:40 <caribou> present+
15:07:54 <dom> Topic: -> https://github.com/w3c/webrtc-pc/issues/ WebRTC-PC Interop Issues
15:07:54 <dom> [slide 10]
15:08:06 <dom> Subtopic: Issue #3088  [[IceRole]] initialized too late
15:08:09 <dom> [slide 11]
15:08:56 <dom> [slide 12]
15:09:58 <dom> [slide 13]
15:10:43 <dom> [no reaction]
15:11:04 <dom> s/[no reaction]/Youenn: any observable change from this?
15:11:35 <dom> Jan-Ivar: I don't think so, but still to be confirmed through updated WPTs
15:11:48 <dom> RESOLVED: Proceed with PR to fix this
15:12:05 <dom> Guido: the PR may provide opportunity for more detailed reaction
15:12:07 <dom> Subtopic: Issue #3090 · Should garbage collecting RTCPeerConnection be observable?
15:12:07 <dom> [slide 14]
15:17:42 <dom> Youenn: when eventhandlers are registered, the PC isn't GC-able
15:18:25 <dom> ... pc.onicecandidate is registered in the test under discussion
15:18:51 <dom> Harald: I'm remembering updating tests to add pc.close() to ensure GC
15:19:15 <dom> ... we've been pushing that any way of reaching an open PC should make it not GC-able
15:19:46 <dom> Jan-Ivar: GC is obversable from the remote end
15:22:32 <dom> ... current Firefox behavior is to GC more aggresively than other browsers, which avoids issues when devs don't call pc.close()
15:23:59 <dom> Youenn: in the test case we're discussing, this is because FF detects no ice candidate can reach pc2? otherwise, it feels like a bug in FF
15:25:53 <dom> Youenn: not sure about changing the spec; the test probably needs more review
15:26:04 <dom> Dom: how much real-word compat issue is this creating?
15:26:09 <dom> Jan-Ivar: not aware of any specifically
15:26:20 <dom> Dom: then maybe we don't need to fix it
15:26:36 <dom> Harald: fixing the test feels like always worth it
15:26:44 <dom> Subtopic: Issue #3092 · RTCError should be exposed on Workers
15:26:44 <dom> [slide 15]
15:27:48 <dom> RESOLVED: adopt proposal
15:27:57 <dom> Subtopic: Issue #3095 · https://w3c.github.io/webrtc-pc/#dfn-final-steps-to-create-an-offer is unclear
15:27:57 <dom> [slide 16]
15:31:46 <dom> [slide 17]
15:33:57 <dom> Jan-Ivar: another option is to clarify the intent of the spec
15:34:01 <dom> Youenn: that's option A
15:34:48 <dom> Jan-Ivar: this predates promises, when we had concerns about the negotiationneeded event
15:35:40 <dom> ... this may no longer be as much an issue if you await promises, but there are still hard-to-pin-down tricky timing issues that this was meant to prevent and are likely still relevant
15:36:56 <dom> ... FF optimizes this cleverly, which could serve as a basis for a more specific algorithm
15:37:40 <dom> ... the main goal is to ensure that as you're about to send the results of createOffer, you ensure it's still aligned with JS state
15:38:07 <dom> Youenn: given the example is about system resoures, that's not so clear to me
15:39:15 <dom> Harald: the relevant test creates an offer without any tracks, then add a track; this is not obvious that this is what the spec is asking
15:40:13 <dom> ... I'd be in favor of some version of Option A if we can find a clean way to spec it
15:41:02 <dom> Youenn: if we go with option A, if negotiation might be needed and createOffer is in process, you would need to check
15:43:29 <dom> ... the spec already asks to generate the answer on main thread
15:46:03 <dom> ... we should either clarify the spec with normative language, or non-normative language, to ensure alignment between what's the page is asking and the offer
15:46:19 <dom> RESOLVED: Proceed with option A, ideally with normative language, or non-normative if not possible
15:47:12 <dom> Guido: is this causing issues in the wild? if not, option C is good
15:47:22 <dom> Youenn: not aware of real web compat issues
15:47:42 <dom> Jan-Ivar: can't rule it out since they would be really hard to track down
15:49:29 <dom> s/RESOLVED/PROPOSED/
15:49:53 <dom> Harald: let's see a concrete proposal for option A before resolving this
15:53:38 <dom> TimP: if the change you've put in JS is not in the offer, won't there be a negotiationneeded event to fix things?
15:53:55 <dom> Jan-Ivar: but using negotiationneeded isn't required
15:55:46 <dom> TimP: if this was designed before we added better APIs (negotiationneeded and transceiver), is this complexity still needed?
15:56:12 <dom> Jan-Ivar: there are data races that the spec should protect from, even if they're corner cases
15:57:20 <dom> youenn: it's not an alternative between race and no-race - it's mostly about optimizing API shape
15:57:30 <dom> Jan-Ivar: I'll provide more background on the historical intent
15:57:43 <dom> Subtopic: Issue #3096 · Vague error for setting a description, inconsistent wpt
15:57:43 <dom> [slide 18]
15:59:16 <dom> [slide 19]
16:02:00 <dom> [slide 20]
16:02:37 <dom> Guido: does this mean Chrome and Safari would fail the test?
16:02:40 <dom> Jan-Ivar: yes
16:03:21 <dom> Harald: I agree with the principle
16:04:03 <dom> Guido: I'm OK with fixing the test, but wouldn't want to keep it in Interop 26
16:04:38 <dom> Youenn: I'm OK with the fix; no strong feeling about interop 26, doesn't look like it should be a big change to libwebrtc
16:05:40 <dom> RESOLVED: Proceed with fixing test case; integration in interop 26 still TBD
16:05:58 <dom> Subtopic: Issue #3097 · Should RTCDataChannel.send be allowed to throw synchronously for not enough buffer space
16:05:59 <dom> [slide 21]
16:08:23 <dom> [slide 22]
16:10:56 <dom> Jan-Ivar: FF lets you send an unlimited amout since we didn't see a reason to limit it; the proposed change works for us, although UA-dependent behavior isn't great
16:11:28 <dom> Youenn: this may be something worth bringing in a separate issue, but not part of interop 26
16:11:36 <dom> RESOLVED: Proceed with proposal of spec clarification
16:11:55 <dom> Topic: Capabilities Element
16:11:55 <dom> [slide 25]
16:12:42 <dom> s/Topic: Capabilities Element//
16:12:47 <dom> s/[slide 25]//
16:12:56 <dom> Topic: Capabilities Element
16:12:56 <dom> [slide 25]
16:13:27 <dom> Daniel: we've been discussing the <usermedia> element, now I have a draft spec
16:13:58 <dom> ... interested in guidance in how to proceed with it moving forward
16:14:14 <dom> ... we have a chrome legacy attribute on which I'm also seeking guidance
16:15:11 <dom> Jan-Ivar: going piecemeal would be OK
16:15:46 <dom> Youenn: +1 with going piecemeal after initial explainer - you may need to update mediacapture-main with hooks
16:16:07 <dom> Daniel: should I model this after the other explainer in mediacapture-extensions?
16:16:50 <dom> Guido: start from the TAG model
16:16:51 <dom> -> https://w3ctag.github.io/explainer-explainer/ Explainer Explainer
16:17:20 <dom> Youenn: so start with an explainer, then a series of PR on media capture extensions (possibly completed with additions to -main as needed)
16:17:34 <dom> ... do you have a sense of a timeline?
16:17:55 <dom> Daniel: hope to get back to this next week; we already have a Blink-process explainer which I hope can serve as a good basis
16:18:28 <dom> Topic: MSTP audio / AudioTrackGenerator
16:18:28 <dom> [slide 28]
16:20:16 <dom> [slide 29]
16:21:03 <dom> [slide 30]
16:22:45 <dom> Jan-Ivar: the data has been longer to produce than initially planned given Paul's availability
16:23:15 <dom> TimP: I have some sympathy on the overlap argument, but the use cases are quite different
16:24:07 <dom> ... MSTP is mostly useful when you're processing both audio and video together - having different APIs for things that are tightly coupled in the way developers approach it is not very satisfactory
16:25:18 <dom> ... e.g. do lips-rerendering in video based on the audio
16:25:47 <dom> Jan-Ivar: our finding is that audio and video are different enough that you're likely to end up wanting to treat them differently
16:26:00 <dom> TimP: I still feel like there is a useful niche in approaching them together
16:27:53 <dom> Guido: beyond measurements (on which I'm looking forward to refutal) - there is a non-niche use case requested by multiple use cases we presented at a previous meeting where audio glitches feel unavoidable when processing doesn't hit audio deadlines
16:29:40 <dom> ... this particular use case can't be implemented without glitches in FF and Safari given lack of MSTP audio
16:32:00 <dom> Jan-Ivar: might be worth highlighting it on the github issue
16:33:07 <dom> Youenn: TimP made a good point about the scenario where having main thread + audio worklet + worker - this would be what a test should demonstrate
16:33:48 <dom> ... it would be good to ensure the requirements from Chrome's team are well understood
16:37:13 <dom> Guido: we have sample code that illustrated our use case
16:38:02 <dom> Youenn: so two actions are needed: a better MSTP shim, and an illustration of how to avoid glitches when audio processing can't meet the audio clock based on the sample Guido shared previously
16:39:13 <dom> Harald: I would encourage a dedicated meeting between Guido and Paul to advance on this outside of a WG meeting
16:40:06 <dom> -> https://www.w3.org/2025/12/09-webrtc-minutes.html#97b7 Previous discussion on the topic
16:41:15 <dom> Jan-Ivar: to clarify, the goal of the shim is not to demonstrate no perf impact - the proper comparison should be with a audio worklet architecture
16:41:48 <dom> TimP: if there is a such meeting, hope the group is invited (even if not required)
16:43:41 <dom> @@@: if there are differences of jitter between input and rendering, there will be glitches if there is no buffering, given WebAudio and MSTP have different models (push vs pull)
16:45:25 <dom> Youenn: what timeline for these actions? given potential dependency on implementation work
16:45:37 <dom> Jan-Ivar: I need to check with Paul
16:45:54 <dom> RRSAgent, draft minutes
16:45:55 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/24-webrtc-minutes.html dom
16:51:46 <dom> RRSAgent, make log public
18:06:31 <cabanier> cabanier has joined #webrtc
18:21:51 <Zakim> Zakim has left #webrtc