Meeting minutes
Slideset: https://
Jan-Ivar: PSA: the expected discussion on MSTP Audio/Audio Track Generator is pushed back to next meeting
WebRTC in Interop 2026
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
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
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
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)
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
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
SFrame Update
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
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
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
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
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
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
Youenn: no strong feelings; shorter is better, that's the extent of my view on this
getCapabilities() for getDisplayMedia
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
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