IRC log of webrtc on 2026-03-24

Timestamps are in UTC.

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: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