- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 19 Feb 2026 15:20:27 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes of the WebRTC WG meeting held on Feb 17 are available at:
https://www.w3.org/2026/02/17-webrtc-minutes.html
and copied as text below.
Dom
WebRTC February 2026 meeting
17 February 2026
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/2011/04/webrtc/wiki/February_17_2026
[3] https://www.w3.org/2026/02/17-webrtc-irc
Attendees
Present
Bartosz, Carine, Dom, FrederikSolenberg, Guido, Harald,
Jan-Ivar, KacperW, MelissaNeubert, MinhLe, SunShin,
TimP, Youenn
Regrets
-
Chair
Guido, Jan-Ivar, Youenn
Scribe
dom
Contents
1. [4]WebRTC in Interop 2026
2. [5]PEPC Update
3. [6]SFrame Update
4. [7]SFrame packetization in RTCRtpScriptTransform
5. [8]getCapabilities() for getDisplayMedia
Meeting minutes
Slideset: [9]https://docs.google.com/presentation/d/
1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/ and [10]archived
PDF copy
[9]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/
Jan-Ivar: PSA: the expected discussion on MSTP Audio/Audio
Track Generator is pushed back to next meeting
WebRTC in Interop 2026
[11][Slide 10]
[11]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#10
Harald: 344/407 - what does that refer to?
Jan-Ivar: the tests filtered for interop-2026-webrtc, matching
single-browser failures
Youenn: 344 is the number of pass out of the total
[12][Slide 11]
[12]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#11
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
… all those interested should review the tests to suggest
addition or removal; in particular, input on specific additions
should come as early as possible
… should we track this in a WPT issue? in a document?
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
… what's the motivation for this scope?
Youenn: my personal motivation is that I've encountered fairly
major compat issues triggered by very minor-looking failures
… 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
jan-ivar: +1; this is focused on webrtc-pc which is more mature
… 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
Guido: +1
… there may still be tests to be excluded e.g. because they're
not worth the effort
… but it's a good way to increase overall interop for webrtc
Youenn: I suggest alerting the WebRTC WG mailing list; each
vendor will also validate whether the tests are relevant from
their perspective
Jan-Ivar: I suggest opening an issue on webrtc-pc
Youenn: maybe a document listing tests, those validated and
those still under review
… we have a bit less of a month to finalize this
… as a markdown doc on webrtc-pc
Jan-Ivar: heads up that the merge for the variant meta may
create false negatives in vendor imports of WPT
Youenn: I'll take a look for our importer
PEPC Update
[13][Slide 13]
[13]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#13
MinhLe: (PM of the capabilities element)
… the last few weeks we've been meeting in a task force meeting
to accelerate progress on this
… we've been discussing additional capabilities attached to
these buttons, and identify what MVP and what comes post-MVP
… MVP on the left hand side, post-MVP on the right hand side
Jan-Ivar: the Chrome MVP would include also <microphone> and
<camera> or just <usermedia>?
Minh: the 3 elements: but the icons-only version won't be
available for <usermedia>
Jan-Ivar: I'm a bit concerned about <camera> and <microphone>
would they be toggles?
Minh: they would be the same as <usermedia> except they can't
do the combined button
… the icons-only is part of our goal for the Chrome MVP
Youenn: I thought there would be only <usermedia> to get out of
Origin Trial, with the device-specific buttons coming shortly
after
… to avoid creating situations where rolling back on
device-specific decisions would be difficult
[14][Slide 14]
[14]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#14
MinhLe: [CE stands for Capability Element]
… this set of behaviors could be applied to icons-only
Youenn: I think the goal was to left second-click undefined in
MVP to leave more freedom for post-MVP
TimP: +1 - given the many edge cases to deal with
… e.G. a click might enable audio play an element; enabling
local IP address discovery is also tied to this
MinhLe: in icons-only mode, the expectations is that the button
would be replaced and so the second-click was a niche case
Jan-Ivar: I might have been pushing for this, but if it's not
needed for MVP, maybe best to leave it undefined indeed
… I thought icons-only would be post-MVP - what's the use case
if they're not toggles?
MinhLe: the icons-only button would only be used for permission
granting and then replaced, with the goal of removing a
pre-prompt
… we're open to do less for the MVP, but this would be a
nice-to-have
Jan-Ivar: +1 on getting there, but I think it will need a bit
more time
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
… so just being a click event might be the right thing even in
the long run
Guido: I also had understood only <usermedia> as part of the
MVP
… +1 that a simple click event might be a good way to let apps
design their own behavior
Jan-Ivar: for accelerating the MVP out of the door, I'd be OK
with not having an event
Youenn: +1 - let's keep MVP actually minimal by leaving aside
things that are niche and undecided yet
… so let's not have the click event for now
Dom: not sure if it's possible for a visible HTML element not
to fire a click event
Youenn: you may be right
… 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
Guido: what does the origin trial do at the moment?
… 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
Minh: right now, the second click generates a permission
revocation prompt
… but none of the partners using that element are actually
keeping the button after the initial prompt, so shouldn't
create any breakage
Guido: in that case, I'm fine either way
Youenn: we should test whether the click event is fired on the
first click in the existing OT
TimP: the second click is within a session, right?
Guido: right
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)
[15][Slide 15]
[15]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#15
[16][Slide 16]
[16]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#16
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
Guido: the only device selection capability would be the
deviceId constraint - no capability to switch device from the
prompt
[17][Slide 17]
[17]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#17
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
Jan-Ivar: I expect there won't be much in the spec about that
particular approach, more UA-driven
Guido: persistence of permission is indeed normally
implementation dependent
Jan-Ivar: I'm assuming clicking the button has the same
permission effect as calling getUserMedia, e.g. the user can
call getUserMedia again
MinhLe: correct
[18]SFrame Update
[18] https://github.com/w3c/webrtc-encoded-transform/pull/252
[19][Slide 20]
[19]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#20
[20][Slide 21]
[20]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#21
Jan-Ivar: is this a bit that expresses basically per-frame or
per-packet?
Youenn: not exactly
… sometimes you might be packetizing an encrypted payload that
needs to be sent as two packets, even in packetized mode
… the spec allows you to send one big payload in packetized
mode that can be sent in two packets
… in practice, the media-specific packetizer that it will
produce before encryption will be small enough to avoid sending
two packets
… but a SFU might have a different MTU between incoming and
outgoing that would require splitting and recombing packets
TimP: why aren't the S(tart) and E(nd) bits sufficient for
this?
Youenn: a single packet might contain a frame (with both S and
E set to 1)
Youenn: the T bit will impact the API as we'll see
[21][Slide 22]
[21]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#22
Youenn: _ok* code examples are fine, _ko* will throw
Harald: if we want to drop packets, we should close the
transceiver - we shouldn't have another way to do this
Youenn: we want to allow changing ot a different transform
Harald: how do you synchronize with the incoming stream?
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
Harald: I'd rather we prevent changing the transform completely
Youenn: we allow changing for ScriptTransform
Harald: which I objected to too
Jan-Ivar: I think there is agreement not to allow for null
Harald: do we have evidence and tests for changing transform?
Youenn: I'll check what we have with webkit
Guido: there are WPT with a changed scripttransform - not sure
they're very comprehensive
Jan-Ivar: this feels like a separate issue of changing the
general rule and changing the situation for sframe transform
Youenn: we could look into it, even though it would be a bit
strangely dissymetric
… the key principle is to ensure no packets can go through
without encryption
[22][Slide 23]
[22]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#23
Jan-Ivar: maybe instead of type, calling it sframe?
… re default, I'd suggest we set one and go with "per-frame"
Dom: +1
Youenn: let's go with that then
[23][Slide 24]
[23]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#24
Jan-Ivar: I like this; if you want ot send both the type and an
object, how would that work?
Youenn: the object would come as a second parameter
… we could put it all in a single dictionary via a different
constructor?
… no strong opinion on either approach
[24][Slide 25]
[24]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#25
Youenn: currently thinking of "exposing packets concatenated as
frames"
Jan-Ivar: support that; not sure how this would get exposed to
the receiver script transform which expects a frame
Youenn: the scripttransform receives an encrypted payload
Jan-Ivar: I still think the scripttransform should only receive
decrypted frames
Youenn: then you shouldn't use this with the sframe
depacketizer
… 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)
TimP: so SFrame packetization means an SFU no longer need to
care about the underlying codec
Youenn: it can also process non-standards "sframe" flavors - it
looks at any content as an encrypted blob of data
TimP: likewise for the SFU; I'm in favor of granting that
flexibility
SFrame packetization in RTCRtpScriptTransform
[25][Slide 28]
[25]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#28
Youenn: not against it, but you need a way to control
encryption/decryption keys
… not sure if it gets done at the scripttransform level, in the
worker, or in a more dynamic manner
… haven't received request for this so far though
Jan-Ivar: make sense; we can bikeshed the API on github
[26][Slide 29]
[26]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#29
Youenn: no strong feelings; shorter is better, that's the
extent of my view on this
[27]getCapabilities() for getDisplayMedia
[27] https://github.com/w3c/mediacapture-screen-share/issues/329
[28][Slide 32]
[28]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#32
Youenn: should we allow for a web site to ask audio only if
restrictOwnAudio is possible instead?
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
Youenn: check on the properties isn't sufficient?
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
Youenn: I'm concerned this is creating new fingerprinting
surface
Jan-Ivar: I like the idea of solving the use case for
restrictOwnAudio and suppressLocalPlayback, not enthused to
open it to more constraints
Guido: fine to limit for that - note that some of these
capabilites are surface-specific
[29][Slide 33]
[29]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#33
[30][Slide 34]
[30]
https://docs.google.com/presentation/d/1pY0o0S17OKoCjs8SbGBdIotJZ22hQRAYch4QGEXQIC8/#34
Jan-Ivar: I don't think the ConstrainablePattern should guide
us on this one
… we have a global getSupportedConstraints() on track - maybe a
similar to that but narrowed to specific use-case driven
constraints
Youenn: this feels like a fingerprint minefields; I would
prefer to expose capabilities before permission
… or at least limit it as much as possible
… e.g. I would remove cursor
… there are use cases where changing getDisplayMedia might
provide an alternative
… in any case, we'll need to get input from the privacy WG
Guido: happy to do so; primarily interested if there is
interest in supporting the use case
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
Harald: the API feels useful, but I'm questionning the linkage
to surfaces "monitor", "window", "browser"
… it would be feel you could limit getCapabilities to a
specific parametrized surface
… some of these constraints make sense only for some surfaces
Jan-Ivar: have you considered using a constraint that fails?
Youenn: that's what I meant by adapting getDisplayMedia, but
that doesn't work for optional UI
TimP: can this be determined before the user picks a particular
surface? do all apps/monitors behave the same way?
Guido: yes
TimP: I think the logic would better fit after permission has
been obtained
Guido: not sure what API would enable that
… putting after permission is too late since it may require
prompting the user again
Jan-Ivar: I would recommend a more targeted API to the specific
use case
… not sure how the developer would make use of values that vary
across surfaces
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
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
Guido: I'll consult with developers and come back with a more
targeted description of the use case towards a minimal solution
Minutes manually created (not a transcript), formatted by
[31]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).
Received on Thursday, 19 February 2026 14:20:29 UTC