07:25:31 <RRSAgent> RRSAgent has joined #webrtc
07:25:35 <RRSAgent> logging to https://www.w3.org/2025/11/11-webrtc-irc
07:25:58 <dom> Meeting: WebRTC WG TPAC 2025 November 11
07:26:18 <Zakim> Zakim has joined #webrtc
07:26:33 <dom> RRSAgent, make log public
07:26:57 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/November_11_2025
07:27:07 <dom> Chair: Youenn, Jan-Ivar, Guido
07:27:25 <dom> Slideset: https://docs.google.com/presentation/d/1sd5zEnvlXO5Sk3ENQorUUIQiRz65sv0KZKxDMMYHM3I/
07:29:21 <dom> Present+ Youenn, Guido, Jan-Ivar, Harald, TonyHerre, SunShin, Dom, Carine, PDM, morx3x , wadakatu
07:30:06 <MarianH> MarianH has joined #webrtc
07:31:09 <herre> herre has joined #webrtc
07:31:16 <jib> jib has joined #webrtc
07:31:22 <kota> kota has joined #webrtc
07:32:01 <dom> Topic: State of the WG
07:32:01 <dom> [slide 8]
07:33:37 <dom> Present+ Kenskau, Meumi, Marian
07:33:46 <dom> Present+ MikeWest
07:34:50 <dom> Present+ MarkusH
07:35:12 <dom> [slide 9]
07:35:31 <caribou> present+ HiroshiKawada, ChrisB
07:36:46 <ryokik> ryokik has joined #webrtc
07:37:14 <dom> [slide 10]
07:37:47 <caribou> present+ RyoKikuchi
07:38:45 <dom> [slide 11]
07:39:42 <dom> [slide 12]
07:40:37 <dom> [slide 13]
07:41:03 <m-alkalbani> m-alkalbani has joined #webrtc
07:42:21 <dom> [slide 14]
07:44:29 <dom> [slide 15]
07:46:19 <dom> Present+ WillMorgan
07:46:27 <dom> Present+ TimP
07:47:13 <dom> q?
07:47:53 <dom> youenn: re webrtc-nv-use-cases not getting attention, but we're seeing new proposals (L4S, network slicing, etc)
07:48:01 <dom> ... should we obsolete the use cases doc?
07:48:40 <dom> harald: good question; I haven't opened it in a year; it's a concern if we develop proposals without anchoring them in a use case
07:48:58 <dom> Youenn: other groups tend to use an explainer rather than a separate centralized use case doc
07:49:28 <komasshu> komasshu has joined #webrtc
07:49:35 <dom> Dom: +1 on obsoleting the doc, as long as do insist on getting explainers to support new proposals
07:49:57 <dom> Harald: probably useful to take a fresh look at the doc and see which might have been spec'd already
07:50:23 <dom> Youenn: re tests, 25% of the tests aren't passing in all browsers, which is as many interop bugs that might impact developers
07:50:45 <dom> ... still a big improvement over what was a few years ago, but we still need improving
07:50:57 <dom> Harald: there are cases where this comes from disagreement
07:51:29 <dom> Youenn: but I've also found failures linked to compat issues that I discovered the hard way
07:51:52 <dom> ... I think it would be useful to take a more systematic review of test results, and fix tests/spec/implementations as needed
07:52:40 <dom> Harald: some of these failures have common causes because e.G. They have a common dependency which is the failure rather than the focus of the actual test
07:52:58 <dom> Youenn: it's usually easier to identify failure in test cases rather than debugging compat issues in real web site
07:54:02 <dom> Youenn: we filed an issue for Interop 2026 on WebRTC, which implementors seems to be on board; hopefully it will be selected and if it is, I hope we can get the WG to identify the list of tests that need fixing in H1, and getting them fixed in H2
07:54:20 <dom> Topic: Transport exploration
07:54:20 <dom> Subtopic: RTCTransport API
07:54:20 <dom> [slide 18]
07:55:32 <dom> Tony: there is a breakout session planned on this tomorrow
07:56:34 <dom> [slide 19]
07:58:11 <dom> [slide 20]
08:01:21 <dom> [slide 21]
08:01:23 <dom> [slide 22]
08:02:08 <dom> i|Youenn: re tests,|-> https://github.com/w3c/webrtc-nv-use-cases/issues/132 Should we retire nv-use-cases
08:03:05 <dom> [slide 23]
08:04:28 <dom> Subtopic: WebTransport over WebRTC ICE?
08:04:29 <dom> [slide 25]
08:05:15 <dom> Jan-Ivar: the current WebRTC is shaped around ICE for P2P connection management, and RTP - that made sense a long time ago
08:10:06 <dom> [slide 26]
08:12:08 <dom> q?
08:12:33 <dom> harald: one of the points of trying to do a new API was to look at the performance of all these layers
08:12:49 <dom> ... WebTransport or data channels over sctp over dtls over udp with ICE is a stack
08:13:12 <dom> ... we can't escape from DTLS set up for proper security, nor from ICE set up for P2P
08:13:25 <dom> ... but not sure if we should concentrate on reducing the baggage we carry about
08:13:36 <dom> Youenn: you would like measurements of gain?
08:13:40 <herre> herre has joined #webrtc
08:13:55 <dom> Harald: yes - Tony put up a demo page hitting a GB/s without optimization for RTC Transport
08:13:58 <herre> q+
08:14:08 <dom> ... (on a local loop)
08:14:15 <dom> ack herre
08:14:20 <dom> q+ TimP
08:14:32 <dom> Tony: keeping existing APIs when we can have values
08:14:42 <dom> ... but this proposal is addressing a different set of use cases
08:15:04 <dom> ... part of what we want to address is using custom congestion control
08:15:12 <dom> ... or custom jitter buffer
08:15:29 <dom> ... would we be able to address these use cases with WebTransport?
08:15:46 <dom> Jan-Ivar: we would like to have low latency in WebTransport as well; if there are APIs that would allow that
08:16:06 <dom> ... re circuit breaker architecture, this has been controversial in the past - both the app and the browser want the control
08:16:33 <dom> ... understanding how that get solved
08:16:57 <herre> q+
08:16:59 <dom> TimP: +1 on distinguishing what RTCTransport letting developers experiment with congestion control algorithms for very specific weird use cases
08:17:34 <dom> ... e.G. I have a use case with a very different set of constraints (for LiDAR) than video calls
08:17:57 <dom> ... also need a different approach to the jitter buffer - the sequence number doesn't matter
08:18:00 <dom> ack TimP
08:18:46 <dom> Youenn: re congestion control/circuit breaker - is it standardizing a congestion control, or standardizing how the connection is broken in case of need
08:19:00 <dom> ... WebTransport is looking at more congestion control support
08:19:08 <dom> ... there may be common need across both approaches
08:20:08 <dom> TimP: the idea is that in terms of circuit breaker, one could be designed that could be used across the 3 systems (classic webrtc, webtransport, rtctransport) - "too many packets for this, we'll break the connection and let the app know"
08:20:30 <dom> ... but the purpose of congestion control is blurred in webrtc between protecting the network and giving a good user experience
08:21:12 <dom> ... in RTCTransport, we're separating the two: living the responsibility to the browser to break the circuilt, but let developers experiment with different congestion control algorithms that don't necessarily align with what's needed for video transmission
08:21:23 <dom> q+ jan-ivar
08:21:31 <dom> ack herre
08:21:39 <dom> ack jan-ivar
08:21:40 <dom> q+ herre
08:21:54 <dom> jan-ivar: the proposals are different because we're solving different use cases
08:22:13 <dom> ... tony is addressing super low latency for things like lidar
08:22:30 <dom> ... where I'm trying to look at plugging WebCodecs into the system
08:22:51 <dom> ... this points to the need to discuss use cases
08:23:12 <dom> Youenn: so there is a discussion point on circuit breaker and the matching use cases - whether it's UA specific, defined in the spec
08:23:26 <herre> q-
08:23:29 <dom> Guido: discussion to be continued in the breakout session tomorrow
08:23:41 <dom> Topic: Encoder Complexity API
08:23:41 <dom> [slide 28]
08:24:18 <dom> s| Encoder Complexity API| -> https://github.com/w3c/webrtc-extensions/issues/191 Encoder Complexity API
08:24:28 <dom> [slide 29]
08:25:18 <dom> [slide 30]
08:26:34 <dom> [slide 31]
08:29:18 <dom> Youenn: only the UA has information about low battery, so the app wouldn't be well positioned to set the hint
08:29:43 <dom> ... if you're encoding multiple streams and give a sense of which stream to "sacrifice" first
08:29:56 <dom> ... the downside of a hint is interoperability
08:30:27 <dom> ... if this is heuristics and the spec doesn't give guidance per codec, plus variability across encoders, how reliable would this be for developers to use?
08:34:09 <dom> q+ Jan-Ivar
08:34:42 <dom> ... ideally, the spec should give enough indication for two browsers running on the same device to behave the same
08:34:49 <dom> ... e.g. per codec mapping
08:35:21 <dom> erik: but depending on the content (still or moving images), the behavior would have to be adaptive
08:36:14 <dom> Jan-Ivar: I don't see fingerprinting surface here, but I wonder if it's incentivizing to ask for more information about capabilities that would create that risk
08:36:30 <dom> ... how would an app use it? given usage might vary over time on a given system?
08:36:35 <dom> ... is this mostly about relative priorities?
08:37:46 <dom> erik: it's meant to provide support the bring-your-own-adaption approach, where clearly need more feedback loop
08:37:57 <dom> jan-ivar: same concern re interop as Youenn
08:38:09 <dom> ... how interop is encoder complexity
08:38:26 <dom> erik: it's pretty common but coming under different names (speed, ...)
08:39:08 <dom> RESOLVED: relative priorities among streams seem consensual, with concerns on interop
08:39:20 <dom> Topic: PEPC: the <usermedia> element
08:39:20 <dom> [slide 33]
08:41:13 <dom> [slide 34]
08:42:32 <dom> Marian: transient user activation is a ppor signal to rely on for validating the user is OK with a prompt
08:42:48 <dom> ... trusted user signal would be a more specific user activation more directly relevant to the context
08:42:50 <dom> [slide 35]
08:43:57 <dom> [slide 36]
08:45:28 <dom> [slide 37]
08:45:47 <dom> Marian: this is on origin trial with Zoom
08:46:49 <dom> ... one of the value they see is fixing the situation where users may have forbidden prompt and may not know how to get out of this - substantial improvements in recovery
08:47:02 <dom> ... it also helps quicker user decision
08:47:26 <dom> [slide 38]
08:47:31 <dom> [slide 39]
08:48:01 <dom> q+
08:49:09 <dom> ack jan-ivar
08:49:15 <dom> ack dom
08:50:01 <dom> dom: how do you envision device selection and handling constraints?
08:50:38 <dom> marian: we've talked about exposing constraints in the element
08:50:47 <dom> ... re device selection, not sure
08:51:16 <dom> mikeW: device selection could be handled with a picker of some sort
08:51:32 <dom> Youenn: today, under some constraints getUserMedia might simply fail without prompt
08:51:56 <dom> WIll: this sounds very good in terms of recoverability
08:52:10 <dom> ... if someone chooses a specific video device, will that restrict fro mchanging that device later
08:52:30 <dom> Marian: that might be UA dependent; at least in Chrome, giving access to one device gives access to all
08:52:44 <dom> Will: any interest to expanding to other permission-gating features?
08:52:53 <dom> Marian: we've already done this for permissions
08:53:03 <dom> ... Mike has been looking at expanding for web apps install
08:53:09 <dom> MikeW: we're very interested in the pattern
08:53:22 <dom> ... for each capability, we'll need to consider specifically for that capability
08:54:00 <dom> ... web app install has very different constraints than usermedia
08:54:18 <dom> q+ youenn
08:54:26 <dom> ... Is it the case you'd be interested in more than just permission?
08:54:58 <dom> ... there is a nice idea of a use case to control mute the stream via this button - that's part of what we're interested in
08:56:14 <dom> jan-ivar: I had concerns about the original one-element proposal from PEPC (the one on slide 37), but the new approach shown in slide 35 feels more compelling
08:56:37 <caribou> +1 to handling permission and controlling the stream at the same time
08:56:45 <dom> ... we're going to suggest using separate camera and microphone elements to avoid the problem of the input element with polymorphism
08:57:03 <dom> ... moving away from permission to allowing access to the feature feels good
08:57:29 <dom> ... it also feels that it makes less intrusive the scenario where you don't grant permanent access to devices
08:57:59 <dom> ... while still leaving room for the UA to experiment
08:58:18 <dom> youenn: 3 main feedback: getUserMedia is difficult, getDisplayMedia might be an easier and very natural fit
08:58:56 <dom> ... we had interop issues to get the list of devices where the permission access leads to very different situations across browsers
08:59:17 <dom> ... clikcing the usermedia access button could be a sufficient signal for allowing device enumeration
09:00:02 <dom> ... for mute/unmute, we have an API in Media Session for this - muting doesn't need user activation, unmuting does based on heuristics - such a button could improve that situation as well
09:00:54 <dom> MikeW: we are not experts in the API you're expert in; to make this usable beyond permission control, we'll need activate engagement from this group to make it work well
09:01:15 <dom> ... we know permissions well, but shifting away from just that needs a lot more help and engagement
09:01:50 <dom> ... we have a repo on the WICG PEPC - filing issues is a great way to get started
09:02:09 <dom> ... issue 62 is a good place to leave initial feedback
09:02:21 <dom> ... once we have enough traction, this might split into its own repo
09:02:39 <dom> Harald: this <usermedia> elemnt, if the page already has permission, what will happen?
09:02:55 <dom> MikeW: a developer wouldn't use it if they already have permission
09:03:07 <dom> Harald: but it could be statically added to the HTML document
09:03:17 <dom> MikeW: it would still appear if you have permission
09:03:38 <dom> ... in our model, the stream would remain attached to the element, which could still be interact with the stream
09:04:05 <dom> ... although that conceptually makes sense, not sure it will work in practice
09:04:19 <dom> ... for multiple microphones, it should work but that need to be verified
09:04:22 <dom> RRSAgent, draft minutes
09:04:23 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/11-webrtc-minutes.html dom