IRC log of webrtc on 2026-02-17

Timestamps are in UTC.

16:00:20 [RRSAgent]
RRSAgent has joined #webrtc
16:00:25 [RRSAgent]
logging to https://www.w3.org/2026/02/17-webrtc-irc
16:00:25 [Zakim]
Zakim has joined #webrtc
16:00:25 [dom]
RRSAgent, make log public
16:00:26 [dom]
Meeting: WebRTC February 2026 meeting
16:00:26 [dom]
Agenda: https://www.w3.org/2011/04/webrtc/wiki/February_17_2026
16:00:26 [dom]
Slideset: https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/
16:00:26 [dom]
Chairs: Guido, Jan-Ivar, Youenn
16:00:48 [dom]
Present+ Dom, Guido, KacperW, Bartosz, Youenn
16:00:57 [dom]
Present+ FrederikSolenberg
16:01:22 [dom]
Present+ SunShin
16:02:14 [dom]
Present+ Jan-Ivar
16:02:53 [dom]
Present+ MelissaNeubert
16:02:57 [dom]
Present+ MinhLe
16:02:59 [dom]
Present+ Harald
16:03:43 [dom]
Present+ TimP
16:04:24 [dom]
Recording is starting
16:06:22 [dom]
Jan-Ivar: PSA: the expected discussion on MSTP Audio/Audio Track Generator is pushed back to next meeting
16:06:25 [dom]
Topic: WebRTC in Interop 2026
16:06:25 [dom]
[slide 10]
16:06:29 [dom]
Present+ Carine
16:07:58 [dom]
Harald: 344/407 - what does that refer to?
16:08:25 [dom]
Jan-Ivar: the tests filtered for interop-2026-webrtc, matching single-browser failures
16:08:34 [dom]
Youenn: 344 is the number of pass out of the total
16:08:39 [dom]
[slide 11]
16:11:38 [dom]
Youenn: the current list will evolve over time; the plan is to have a pretty stable list by end of Q1; some tests will be excluded e.g. because they're wrong
16:12:06 [dom]
... all those interested should review the tests to suggest addition or removal; in particular, input on specific additions should come as early as possible
16:12:36 [dom]
... should we track this in a WPT issue? in a document?
16:13:17 [dom]
Harald: previous interop were focused on a well-defined scope; this feels stastistics based, when we know from experience lots of WPT tests are wrong
16:13:25 [dom]
... what's the motivation for this scope?
16:13:59 [dom]
Youenn: my personal motivation is that I've encountered fairly major compat issues triggered by very minor-looking failures
16:14:31 [dom]
... so going through the tests and fixing as many failures as we can would help; fixing on tests that pass two browsers reduce the scope to be more manageable and focused
16:14:48 [dom]
jan-ivar: +1; this is focused on webrtc-pc which is more mature
16:15:32 [dom]
... considering only tests that pass in 2 browsers reduce the number of tests in scope and also bring light to where there is existing interop
16:15:41 [dom]
Guido: +1
16:16:10 [dom]
... there may still be tests to be excluded e.g. because they're not worth the effort
16:16:20 [dom]
... but it's a good way to increase overall interop for webrtc
16:17:23 [dom]
Youenn: I suggest alerting the WebRTC WG mailing list; each vendor will also validate whether the tests are relevant from their perspective
16:17:34 [dom]
Jan-Ivar: I suggest opening an issue on webrtc-pc
16:17:50 [dom]
Youenn: maybe a document listing tests, those validated and those still under review
16:17:56 [dom]
... we have a bit less of a month to finalize this
16:19:06 [dom]
... as a markdown doc on webrtc-pc
16:20:09 [dom]
Jan-Ivar: heads up that the merge for the variant meta may create false negatives in vendor imports of WPT
16:21:29 [dom]
Youenn: I'll take a look for our importer
16:21:34 [dom]
Topic: PEPC Update
16:21:34 [dom]
[slide 13]
16:21:47 [dom]
MinhLe: (PM of the capabilities element)
16:22:09 [dom]
... the last few weeks we've been meeting in a task force meeting to accelerate progress on this
16:23:47 [dom]
... we've been discussing additional capabilities attached to these buttons, and identify what MVP and what comes post-MVP
16:24:20 [dom]
... MVP on the left hand side, post-MVP on the right hand side
16:25:26 [dom]
Jan-Ivar: the Chrome MVP would include also <microphone> and <camera> or just <usermedia>?
16:26:23 [dom]
Minh: the 3 elements: but the icons-only version won't be available for <usermedia>
16:26:46 [dom]
Jan-Ivar: I'm a bit concerned about <camera> and <microphone> would they be toggles?
16:27:10 [dom]
Minh: they would be the same as <usermedia> except they can't do the combined button
16:27:35 [dom]
... the icons-only is part of our goal for the Chrome MVP
16:28:07 [dom]
Youenn: I thought there would be only <usermedia> to get out of Origin Trial, with the device-specific buttons coming shortly after
16:28:30 [dom]
... to avoid creating situations where rolling back on device-specific decisions would be difficult
16:28:32 [dom]
[slide 14]
16:29:07 [dom]
MinhLe: [CE stands for Capability Element]
16:29:55 [dom]
... this set of behaviors could be applied to icons-only
16:30:38 [dom]
Youenn: I think the goal was to left second-click undefined in MVP to leave more freedom for post-MVP
16:30:53 [dom]
TimP: +1 - given the many edge cases to deal with
16:31:26 [dom]
... e.G. a click might enable audio play an element; enabling local IP address discovery is also tied to this
16:32:37 [dom]
MinhLe: in icons-only mode, the expectations is that the button would be replaced and so the second-click was a niche case
16:32:54 [dom]
Jan-Ivar: I might have been pushing for this, but if it's not needed for MVP, maybe best to leave it undefined indeed
16:33:18 [dom]
... I thought icons-only would be post-MVP - what's the use case if they're not toggles?
16:34:09 [dom]
MinhLe: the icons-only button would only be used for permission granting and then replaced, with the goal of removing a pre-prompt
16:34:23 [dom]
... we're open to do less for the MVP, but this would be a nice-to-have
16:34:40 [dom]
Jan-Ivar: +1 on getting there, but I think it will need a bit more time
16:35:30 [dom]
Harald: after the 1st click, you have the stream; if you have an event for the 2nd click, you can implement any action you want in the JS; you don't need to have an effect
16:35:41 [dom]
... so just being a click event might be the right thing even in the long run
16:36:01 [dom]
Guido: I also had understood only <usermedia> as part of the MVP
16:36:43 [dom]
... +1 that a simple click event might be a good way to let apps design their own behavior
16:37:07 [dom]
Jan-Ivar: for accelerating the MVP out of the door, I'd be OK with not having an event
16:37:33 [dom]
Youenn: +1 - let's keep MVP actually minimal by leaving aside things that are niche and undecided yet
16:39:05 [dom]
... so let's not have the click event for now
16:39:22 [dom]
Dom: not sure if it's possible for a visible HTML element not to fire a click event
16:39:27 [dom]
Youenn: you may be right
16:39:51 [dom]
... if there is a click event for the 1st click, then I'm fine for the 2nd click to also fire that event - but not have a specialized behavior
16:40:24 [dom]
Guido: what does the origin trial do at the moment?
16:40:53 [dom]
... if the OT is doing something with the 2nd click, whatever it is doing might need to be the MVP if someone is relying on that behavior
16:41:06 [dom]
Minh: right now, the second click generates a permission revocation prompt
16:41:28 [dom]
... but none of the partners using that element are actually keeping the button after the initial prompt, so shouldn't create any breakage
16:41:44 [dom]
Guido: in that case, I'm fine either way
16:42:19 [dom]
Youenn: we should test whether the click event is fired on the first click in the existing OT
16:42:39 [dom]
TimP: the second click is within a session, right?
16:42:42 [dom]
Guido: right
16:43:54 [dom]
MinhLe: in summary: remove icons-only, <camera> and <microphone> from MVP; and don't do anything specific about the second click in terms of events (just align with what happens for other elements)
16:44:21 [dom]
[slide 15]
16:45:22 [dom]
[slide 16]
16:46:54 [dom]
Jan-Ivar: exposing camera/mic selection in the prompt is up to the UA - the key is having an API that adapts to the various approaches to permission management
16:48:12 [dom]
Guido: the only device selection capability would be the deviceId constraint - no capability to switch device from the prompt
16:49:21 [dom]
[slide 17]
16:50:59 [dom]
Youenn: I haven't followed the dicsussion on allow on button push - if/when you plan to move forward with this and is spec-targeted, it would be good to present it to the WG
16:51:15 [dom]
Jan-Ivar: I expect there won't be much in the spec about that particular approach, more UA-driven
16:51:34 [dom]
Guido: persistence of permission is indeed normally implementation dependent
16:52:10 [dom]
Jan-Ivar: I'm assuming clicking the button has the same permission effect as calling getUserMedia, e.g. the user can call getUserMedia again
16:52:14 [dom]
MinhLe: correct
16:52:36 [dom]
Topic: -> https://github.com/w3c/webrtc-encoded-transform/ SFrame Update
16:52:36 [dom]
[slide 20]
16:54:37 [dom]
[slide 21]
16:56:03 [dom]
Jan-Ivar: is this a bit that expresses basically per-frame or per-packet?
16:56:13 [dom]
Youenn: not exactly
16:56:52 [dom]
... sometimes you might be packetizing an encrypted payload that needs to be sent as two packets, even in packetized mode
16:57:31 [dom]
... the spec allows you to send on big payload in packetized mode that can be sent in two packets
16:57:37 [dom]
s/on/one/
16:58:07 [dom]
... in practice, the media-specific packetizer that it will produce before encryption will be small enough to avoid sending two packets
16:59:01 [dom]
... but the SFU might have a different MTU between incoming and outgoing that would require splitting and recombing packets
16:59:10 [dom]
s/the SFU/a SFU
16:59:41 [dom]
TimP: why aren't the S(tart) and E(nd) bits sufficient for this?
17:00:15 [dom]
Youenn: a single packet might contain a frame (with both S and E set to 1)
17:00:34 [dom]
Youenn: the T bit will impact the API as we'll see
17:00:36 [dom]
[slide 22]
17:01:40 [dom]
Youenn: _ok* code examples are fine, _ko* will throw
17:03:38 [dom]
Harald: if we want to drop packets, we should close the transceiver - we shouldn't have another way to do this
17:03:46 [dom]
Youenn: we want to allow changing ot a different transform
17:03:56 [dom]
Harald: how do you synchronize with the incoming stream?
17:04:34 [dom]
Youenn: you cannot; the only thing you can commit is no packet will not go through a transform, without promise on which transform it will
17:04:52 [dom]
Harald: I'd rather we prevent changing the transform completely
17:05:04 [dom]
Youenn: we allow changing for ScriptTransform
17:05:08 [dom]
Harald: which I objected to too
17:05:22 [dom]
Jan-Ivar: I think there is agreement not to allow for null
17:06:16 [dom]
Harald: do we have evidence and tests for changing transform?
17:06:25 [dom]
Youenn: I'll check what we have with webkit
17:06:54 [dom]
Guido: there are WPT with a changed scripttransform - not sure they're very comprehensive
17:07:27 [dom]
Jan-Ivar: this feels like a separate issue of changing the general rule and changing the situation for sframe transform
17:07:55 [dom]
Youenn: we could look into it, even though it would be a bit strangely dissymetric
17:08:11 [dom]
... the key principle is to ensure no packets can go through without encryption
17:08:16 [dom]
[slide 23]
17:11:46 [dom]
Jan-Ivar: maybe instead of type, calling it sframe?
17:12:13 [dom]
... re default, I'd suggest we set one and go with "per-frame"
17:12:14 [dom]
Dom: +1
17:12:25 [dom]
Youenn: let's go with that then
17:12:27 [dom]
[slide 24]
17:14:55 [dom]
Jan-Ivar: I like this; if you want ot send both the type and an object, how would that work?
17:15:04 [dom]
Youenn: the object would come as a second parameter
17:15:17 [dom]
... we could put it all in a single dictionary via a different constructor?
17:15:27 [dom]
... no strong opinion on either approach
17:15:29 [dom]
[slide 25]
17:17:13 [dom]
Youenn: currently thinking of "exposing packets concatenated as frames"
17:18:07 [dom]
Jan-Ivar: support that; not sure how this would get exposed to the receiver script transform which expects a frame
17:18:26 [dom]
Youenn: the scripttransform receives an encrypted payload
17:18:50 [dom]
Jan-Ivar: I still think the scripttransform should only receive decrypted frames
17:19:15 [dom]
Youenn: then you shouldn't use this with the sframe depacketizer
17:22:27 [dom]
... if we want to add native encryption/decryption to ScriptTransform, we need to add key management to the ScriptTransform, which doesn't exist today (although there are ideas in that direction discussed in github issues)
17:23:31 [dom]
TimP: so SFrame packetization means an SFU no longer need to care about the underlying codec
17:24:08 [dom]
Youenn: it can also process non-standards "sframe" flavors - it looks at any content as an encrypted blob of data
17:24:38 [dom]
TimP: likewise for the SFU; I'm in favor of granting that flexibility
17:26:09 [dom]
Topic: SFrame packetization in RTCRtpScriptTransform
17:26:09 [dom]
[slide 28]
17:28:20 [dom]
Youenn: not against it, but you need a way to control encryption/decryption keys
17:28:42 [dom]
... not sure if it gets done at the scripttransform level, in the worker, or in a more dynamic manner
17:28:51 [dom]
... haven't received request for this so far though
17:29:53 [dom]
Jan-Ivar: make sense; we can bikeshed the API on github
17:29:59 [dom]
[slide 29]
17:30:52 [dom]
Youenn: no strong feelings; shorter is better, that's the extent of my view on this
17:31:02 [dom]
Topic: -> https://github.com/w3c/mediacapture-screen-share/issues/329 getCapabilities() for getDisplayMedia
17:31:02 [dom]
[slide 32]
17:34:31 [dom]
Youenn: should we allow for a web site to ask audio only if restrictOwnAudio is possible instead?
17:35:05 [dom]
Guido: this is an example of a potential combination, but there are other situations, e.g. where the UI of the app is changed based on that capability
17:36:08 [dom]
Youenn: check on the properties isn't sufficient?
17:37:22 [dom]
Guido: all versions of Chrome say the constraints are supported, but depending on the a number of parameters (permissions, OS versions, etc) they get different values
17:37:35 [dom]
Youenn: I'm concerned this is creating new fingerprinting surface
17:38:37 [dom]
Jan-Ivar: I like the idea of solving the use case for restrictOwnAudio and suppressLocalPlayback, not enthused to open it to more constraints
17:38:55 [dom]
Guido: fine to limit for that - note that some of these capabilites are surface-specific
17:39:22 [dom]
[slide 33]
17:39:57 [dom]
[slide 34]
17:41:44 [dom]
Jan-Ivar: I don't think the ConstrainablePattern should guide us on this one
17:42:17 [dom]
... we have a global getSupportedConstraints() on track - maybe a similar to that but narrowed to specific use-case driven constraints
17:42:49 [dom]
Youenn: this feels like a fingerprint minefields; I would prefer to expose capabilities before permission
17:42:56 [dom]
... or at least limit it as much as possible
17:43:04 [dom]
... e.g. I would remove cursor
17:43:24 [dom]
... there are use cases where changing getDisplayMedia might provide an alternative
17:43:37 [dom]
... in any case, we'll need to get input from the privacy WG
17:43:55 [dom]
Guido: happy to do so; primarily interested if there is interest in supporting the use case
17:44:47 [dom]
Youenn: the optional UI use case seems hard to solve with getDisplayMedia, so I'm OK investigating this, but I want input from PING WG if we don't have alternatives to getCapabilities
17:45:22 [dom]
Harald: the API feels useful, but I'm questionning the linkage to surfaces "monitor", "window", "browser"
17:45:53 [dom]
... it would be feel you could limit getCapabilities to a specific parametrized surface
17:46:22 [dom]
... some of these constraints make sense only for some surfaces
17:47:20 [dom]
Jan-Ivar: have you considered using a constraint that fails?
17:47:51 [dom]
Youenn: that's what I meant by adapting getDisplayMedia, but that doesn't work for optional UI
17:49:38 [dom]
TimP: can this be determined before the user picks a particular surface? do all apps/monitors behave the same way?
17:51:10 [dom]
Guido: yes
17:52:52 [dom]
TimP: I think the logic would better fit after permission has been obtained
17:53:04 [dom]
Guido: not sure what API would enable that
17:53:27 [dom]
... putting after permission is too late since it may require prompting the user again
17:54:06 [dom]
Jan-Ivar: I would recommend a more targeted API to the specific use case
17:54:41 [dom]
... not sure how the developer would make use of values that vary across surfaces
17:55:20 [dom]
Guido: if the app can detect suppressLAP work on some surfaces, it can decide to only offer these surfaces or give up depending on its needs
17:57:11 [dom]
Youenn: I think a highly focused solution would work - I would start with one of the two properties (rOA or sLAP), detail the use cases (some might work with changes to gDM, some not), and then iterate on a solution that targets specifically the needs that can't be solved via gDM
17:57:45 [dom]
Guido: I'll consult with developers and come back with a more targeted description of the use case towards a minimal solution
17:58:03 [dom]
RRSAgent, draft minutes
17:58:04 [RRSAgent]
I have made the request to generate https://www.w3.org/2026/02/17-webrtc-minutes.html dom
18:26:05 [Zakim]
Zakim has left #webrtc