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