Meeting minutes
Slideset: https://
State of the WG
youenn: re webrtc-nv-use-cases not getting attention, but we're seeing new proposals (L4S, network slicing, etc)
… should we obsolete the use cases doc?
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
Youenn: other groups tend to use an explainer rather than a separate centralized use case doc
Dom: +1 on obsoleting the doc, as long as do insist on getting explainers to support new proposals
Harald: probably useful to take a fresh look at the doc and see which might have been spec'd already
Youenn: re tests, 25% of the tests aren't passing in all browsers, which is as many interop bugs that might impact developers
… still a big improvement over what was a few years ago, but we still need improving
Harald: there are cases where this comes from disagreement
Youenn: but I've also found failures linked to compat issues that I discovered the hard way
… I think it would be useful to take a more systematic review of test results, and fix tests/spec/implementations as needed
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
Youenn: it's usually easier to identify failure in test cases rather than debugging compat issues in real web site
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
Transport exploration
RTCTransport API
Tony: there is a breakout session planned on this tomorrow
WebTransport over WebRTC ICE?
Jan-Ivar: the current WebRTC is shaped around ICE for P2P connection management, and RTP - that made sense a long time ago
harald: one of the points of trying to do a new API was to look at the performance of all these layers
… WebTransport or data channels over sctp over dtls over udp with ICE is a stack
… we can't escape from DTLS set up for proper security, nor from ICE set up for P2P
… but not sure if we should concentrate on reducing the baggage we carry about
Youenn: you would like measurements of gain?
Harald: yes - Tony put up a demo page hitting a GB/s without optimization for RTC Transport
… (on a local loop)
Tony: keeping existing APIs when we can have values
… but this proposal is addressing a different set of use cases
… part of what we want to address is using custom congestion control
… or custom jitter buffer
… would we be able to address these use cases with WebTransport?
Jan-Ivar: we would like to have low latency in WebTransport as well; if there are APIs that would allow that
… re circuit breaker architecture, this has been controversial in the past - both the app and the browser want the control
… understanding how that get solved
TimP: +1 on distinguishing what RTCTransport letting developers experiment with congestion control algorithms for very specific weird use cases
… e.G. I have a use case with a very different set of constraints (for LiDAR) than video calls
… also need a different approach to the jitter buffer - the sequence number doesn't matter
Youenn: re congestion control/circuit breaker - is it standardizing a congestion control, or standardizing how the connection is broken in case of need
… WebTransport is looking at more congestion control support
… there may be common need across both approaches
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"
… but the purpose of congestion control is blurred in webrtc between protecting the network and giving a good user experience
… 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
jan-ivar: the proposals are different because we're solving different use cases
… tony is addressing super low latency for things like lidar
… where I'm trying to look at plugging WebCodecs into the system
… this points to the need to discuss use cases
Youenn: so there is a discussion point on circuit breaker and the matching use cases - whether it's UA specific, defined in the spec
Guido: discussion to be continued in the breakout session tomorrow
Encoder Complexity API
Youenn: only the UA has information about low battery, so the app wouldn't be well positioned to set the hint
… if you're encoding multiple streams and give a sense of which stream to "sacrifice" first
… the downside of a hint is interoperability
… 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?
… ideally, the spec should give enough indication for two browsers running on the same device to behave the same
… e.g. per codec mapping
erik: but depending on the content (still or moving images), the behavior would have to be adaptive
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
… how would an app use it? given usage might vary over time on a given system?
… is this mostly about relative priorities?
erik: it's meant to provide support the bring-your-own-adaption approach, where clearly need more feedback loop
jan-ivar: same concern re interop as Youenn
… how interop is encoder complexity
erik: it's pretty common but coming under different names (speed, ...)
RESOLUTION: relative priorities among streams seem consensual, with concerns on interop
PEPC: the <usermedia> element
Marian: transient user activation is a ppor signal to rely on for validating the user is OK with a prompt
… trusted user signal would be a more specific user activation more directly relevant to the context
Marian: this is on origin trial with Zoom
… 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
… it also helps quicker user decision
dom: how do you envision device selection and handling constraints?
marian: we've talked about exposing constraints in the element
… re device selection, not sure
mikeW: device selection could be handled with a picker of some sort
Youenn: today, under some constraints getUserMedia might simply fail without prompt
WIll: this sounds very good in terms of recoverability
… if someone chooses a specific video device, will that restrict fro mchanging that device later
Marian: that might be UA dependent; at least in Chrome, giving access to one device gives access to all
Will: any interest to expanding to other permission-gating features?
Marian: we've already done this for permissions
… Mike has been looking at expanding for web apps install
MikeW: we're very interested in the pattern
… for each capability, we'll need to consider specifically for that capability
… web app install has very different constraints than usermedia
… Is it the case you'd be interested in more than just permission?
… 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
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
<caribou> +1 to handling permission and controlling the stream at the same time
jan-ivar: we're going to suggest using separate camera and microphone elements to avoid the problem of the input element with polymorphism
… moving away from permission to allowing access to the feature feels good
… it also feels that it makes less intrusive the scenario where you don't grant permanent access to devices
… while still leaving room for the UA to experiment
youenn: 3 main feedback: getUserMedia is difficult, getDisplayMedia might be an easier and very natural fit
… we had interop issues to get the list of devices where the permission access leads to very different situations across browsers
… clikcing the usermedia access button could be a sufficient signal for allowing device enumeration
… 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
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
… we know permissions well, but shifting away from just that needs a lot more help and engagement
… we have a repo on the WICG PEPC - filing issues is a great way to get started
… issue 62 is a good place to leave initial feedback
… once we have enough traction, this might split into its own repo
Harald: this <usermedia> elemnt, if the page already has permission, what will happen?
MikeW: a developer wouldn't use it if they already have permission
Harald: but it could be statically added to the HTML document
MikeW: it would still appear if you have permission
… in our model, the stream would remain attached to the element, which could still be interact with the stream
… although that conceptually makes sense, not sure it will work in practice
… for multiple microphones, it should work but that need to be verified