14:56:13 <RRSAgent> RRSAgent has joined #webrtc
14:56:18 <RRSAgent> logging to https://www.w3.org/2025/09/16-webrtc-irc
14:56:18 <Zakim> Zakim has joined #webrtc
14:56:18 <dom> RRSAgent, make log public
14:56:19 <dom> Meeting: WebRTC September 2025 meeting
14:56:19 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/September_16_2025
14:56:19 <dom> Slideset: https://docs.google.com/presentation/d/11rr8X4aOao1AmvyoDLX8o9CPCmnDHkWGRM3nB4Q_104/
14:56:19 <dom> Chairs: Guido, Jan-Ivar, Youenn
15:01:11 <dom> Present: Fippo, Jan-Ivar, Guido, SergeySilkin, NishitaDey, harald, SteveBecker, JasperHugo, PeterT
15:01:13 <dom> Present+
15:02:00 <dom> Present +SunShin
15:03:32 <dom> Present+ TonyHerre
15:04:05 <dom> Present+ Youenn
15:04:24 <dom> Recording is starting
15:05:36 <dom> Present+ DiegoPerezBotero
15:05:38 <dom> Present+ Carine
15:06:56 <dom> Present+ TimP
15:07:09 <dom> Present+ KonradHofbauer
15:07:24 <dom> Topic: -> https://github.com/w3c/mediacapture-output/ Audio Output Devices API
15:07:24 <dom> Subtopic: Ask for user gesture to call setSinkId #84
15:07:24 <dom> [slide 10]
15:10:15 <dom> Jan-Ivar: a bit concerned that this adds variance among implementations and might lead to compat issues
15:10:30 <dom> ... what's the motivation for this change?
15:10:56 <dom> Youenn: similar to gUM or gDM: when a web site starts playing audio, we put a user activation check - which I think the media spec requires
15:11:14 <dom> ... setSinkId is starting to play audio on a given speaker - it seems logical to have a user gesture check there as well
15:11:36 <dom> Harald: the most common use case where a device is no longer available is when people unplug their earbuds
15:12:00 <dom> ... when they do and the app notices, will there be a user activation event available or not?
15:12:21 <dom> Youenn: in that situation in Safari, setSinkId would be available given the devicechange event
15:12:50 <dom> harald: so a devicechange event counts as user activation in this case?
15:12:57 <dom> Youenn: that's how we implemented in Safari
15:13:17 <dom> ... and we propagate to the async enumerateDevices call as well since it's likely to be called afterwards
15:13:35 <dom> harald: so harmess if it includes the devicechange event
15:13:59 <dom> Youenn: that's why the spec should allow it; we think we've solved web compat concerns, we'll see if more emerge
15:14:28 <dom> Fippo: a common use case is to play the ring tone on the speaker and the call on the headset - would that still be supported?
15:15:02 <dom> Youenn: in a call, you call gUM, you get the devices and then call setSinkId - microphone starting also counts as activation in our heuristics
15:16:09 <dom> ... When we call gUM, the enumerateDevices list is changing with a devicechange event, which is used as the trigger to do the device setup
15:16:23 <dom> Jan-Ivar: so user activation or devicechange event?
15:16:29 <dom> Youenn: that's what we've implemented
15:17:19 <dom> Jan-Ivar: how does this deal with multiple gUM?
15:17:28 <dom> Youenn: this hasn't been a concern so far
15:17:43 <dom> Jan-Ivar: I'm not sure Firefox would be able to implement this; I'm also not a big fan of SHOULD
15:18:03 <dom> TimP: I'm supportive of this change, with a bit more work on details
15:18:35 <dom> ... as it can protect against misuses
15:19:20 <dom> Dom: what would it take to turn this into a MUST?
15:19:53 <dom> Youenn: I thought of first making this a first step and get implementation experience before requiring it
15:20:20 <dom> Guido: I'm ok with adding it as a may, but making a must will require a more extensive list of circumstances
15:20:39 <dom> Youenn: I can start with a MAY and open a  separate issue to make it stronger
15:20:51 <dom> RESOLVED: Proceed with a MAY require user activation
15:20:56 <dom> Subtopic: Should media capture output define an explicit default speaker device? #151
15:20:56 <dom> [slide 11]
15:21:15 <dom> [slide 12]
15:22:47 <dom> Jan-Ivar: I agree the situation is unfortunate for Web compat; is this only for speakers, or also for microphone?
15:23:20 <dom> Youenn: the problem seems less prominent for microphones
15:23:34 <dom> Jan-Ivar: the problem with that approach is that it clashes with the rest of the spec in terms of the devicechange event
15:23:47 <dom> Youenn: if you want the default, you call setSinkId("")
15:24:14 <dom> Jan-Ivar: but this doesn't let detect when the default OS device changes
15:24:27 <dom> Youenn: we've done that change for webcompat and seems to be working well
15:25:15 <dom> Guido: the default for the output device is a good idea; I think Firefox does it in some circumstances with selectAudioOutput
15:25:41 <dom> Jan-Ivar: yes, we have it in specific conditions for selectAudioOutput
15:25:57 <dom> Youenn: default speaker is also a widely used concept across OS
15:26:36 <dom> Jan-Ivar: Firefox needs to improve its compat on devicechange event in any case; so I'm in favor if we can clarify the situation with devicechange event
15:26:50 <dom> Youenn: ready for PR then?
15:27:05 <dom> Jan-Ivar: we can continue on the issue but not opposed to a PR
15:27:16 <dom> RESOLVED: proceed with proposed change with additional discussion expected
15:27:24 <dom> Subtopic: Expose the type of device in MediaDeviceInfo #1
15:27:24 <dom> [slide 13]
15:28:48 <dom> Jan-Ivar: LGTM, doesn't seem to bring privacy issues since they're only exposed when the device is exposed
15:29:06 <dom> ... should there be a headset category?
15:29:15 <dom> Youenn: we can try this
15:29:31 <dom> Harald: I'm a bit worried about the specifics of the enumeration
15:30:04 <dom> ... e.g. many mics are usb even they're built-in
15:30:16 <dom> Youenn: I can bring more info on what Windows / MacOS expose
15:30:51 <dom> RESOLVED: Proceed with a pull request with additional discussion on enumerated values
15:31:06 <dom> Subtopic: Speaker devices may not always work with all microphones #149
15:31:06 <dom> [slide 14]
15:33:12 <dom> Guido: what would be the alternative to failing gUM/setSinkId?
15:33:46 <dom> Youenn: I don't have a specific proposal; I was first trying to get a sense if that's a problem worth fixing (e.g. if it affects other OS)
15:34:06 <dom> Guido: maybe let's focus first on identifying how widespread an issue it is
15:34:36 <dom> Jan-Ivar: this reminds me of the issue where you can't open multiple mics on phones; don't have a good solution off the top of my head either
15:34:56 <dom> Topic: -> https://github.com/w3c/webrtc-extensions/issues/146 Decoder exposure and software fallback
15:34:56 <dom> [slide 17]
15:36:16 <dom> RRSAgent, draft minutes
15:36:17 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/16-webrtc-minutes.html dom
15:37:02 <dom> [slide 18]
15:38:24 <dom> [slide 19]
15:39:14 <dom> [slide 20]
15:39:34 <dom> [slide 21]
15:40:43 <dom> Youenn: the Privacy Working Group had raised concerns - we should ask them if we're looking at this again
15:41:07 <dom> ... if media capabilities already provide that info through polling - is that good enough?
15:41:51 <dom> ... polling instead of an event might be a feature here
15:42:28 <dom> Nishitha: media capabilities doesn't expose what is actually reflect what's happening during streaming
15:42:53 <dom> Diego: mc signals the potential to have the hardware decode enabled, but it doesn't say if it is happening
15:43:32 <dom> ... e.g. we can't get info on situations where MC says there is hardware decode but we're not seeing it used
15:44:34 <dom> ... there are software-fallback situations where errors occur that are can't be monitored via telemetry
15:45:04 <dom> Youenn: MC solves hardware support, but not lack of temporary availability. maybe it's a shortage of MC?
15:46:18 <dom> Diego: given that streams get negotiated during SDP O/A with the codec profile and format and characteristics that can lead to a decoder giving up in the middle of the stream; MC require predicting all possible cases to detect these situations when this event could give much more specific direction
15:47:14 <dom> Youenn: if the PRivacy Working Group is fine with this, I'm fine too; but these issues might arise in WebCodecs as well, so having a single solution would be nice
15:47:53 <dom> Jan-Ivar: I understand the event proposal comes from feedback from the Privacy WG (vs stats)
15:49:06 <dom> ... It's not really clear what fallback means
15:49:48 <dom> ... e.g. would that event be fired in a system without hardware decode support?
15:50:36 <dom> ... there are also situations (e.g. small frames) where software decode wouldn't be a sign of a problem
15:51:07 <dom> ... in terms of API shape, I prefer B rather than A that makes it harder to distinguish fatal errors
15:51:54 <dom> ... supportive of direction but with more clarification on situation of failures
15:52:32 <dom> TimP: supportive of this, but less supportive of the "fallback" concept and the hardware/software dichotomy
15:52:52 <dom> ... I think the event we want is "decoder implementation changed"
15:53:19 <dom> ... I think what we really care about is latency, not whether it's hardware or software
15:53:32 <dom> ... it would be nice to have stats on average frame decode time if we don't have one
15:53:39 <dom> Fippo: we do
15:53:55 <dom> TimP: then trigger on implementation change + stats would work
15:55:10 <dom> Diego: detecting device type is really hard for (good) privacy protection reasons, so we can't really figure the characteristics of the devices on which the stream is running, in particular to detect regressions
15:55:32 <dom> TimP: but knowing the decoder has changed under your feet, would that help?
15:55:47 <dom> Diego: CPU decode is not only about latency: it has impact on battery and thermal impact
15:58:02 <dom> ... the event would be useful, but less useful
15:59:56 <dom> dom: if we want to do this, we should do this and get feedback from Privacy WG
16:00:43 <dom> ... events can add privacy attacks by surfacing on two different origins
16:00:52 <dom> Harald: why on Transceiver vs Receiver?
16:00:59 <dom> Fippo: +1 to Receiver
16:01:20 <dom> RESOLVED: discuss proposal in more depth and prepare for Privacy review
16:01:28 <dom> Topic: -> https://github.com/w3c/webrtc-encoded-transform/ generateKeyFrame() API consolidation (Jan-Ivar)
16:01:28 <dom> Subtopic: Issue #273 / PR #274: Remove sender.generateKeyFrame()
16:01:28 <dom> [slide 25]
16:03:35 <dom> TimP: I don't like the first API - encoding parameters should be less dynamic than that, this is not an encoding parameter; the second API makes much more sense
16:04:04 <dom> Jan-Ivar: the argument why we went for this API is that it allows to combine changing all parameters and sending a keyframe at the same time
16:04:32 <dom> RESOLVED: Proceed with removing unimplemented API
16:04:59 <dom> Subtopic: Issue #147: expose rid as metadata on outgoing frames
16:04:59 <dom> [slide 26]
16:06:20 <dom> Fippo: we would like the encoding index in addition of the rid; we would like the mid since it isn't available in workers
16:06:38 <dom> Jan-Ivar: the mid can be passed as an option
16:06:58 <dom> Youenn: or in the Transformer itself
16:07:16 <dom> ... there will be one per mid
16:07:26 <dom> ... not exposing it in frames makes it more lightweight
16:07:43 <dom> ... we should file an issue on this
16:08:03 <dom> Jan-Ivar: adding an encodingIndex can also be filed an issue
16:08:29 <dom> Fippo: having it in addition to rid is an ergonomy value
16:08:36 <dom> RESOLVED: Proceed with pull request
16:08:45 <dom> Subtopic: PR #276: Default the generate key frame algorithm to all layers
16:08:45 <dom> [slide 27]
16:10:09 <dom> Youenn: the main use case is changing the encryption key in which case you want to generate keyframes for all layers
16:10:14 <dom> RESOLVED: proceed with merging PR
16:10:20 <dom> Subtopic: Issue 143: should transform.generateKeyFrame() take an array of rids?
16:10:20 <dom> [slide 28]
16:11:28 <dom> [slide 29]
16:11:30 <dom> [slide 30]
16:13:16 <dom> Youenn: no strong preference, but a slight preference to keep it as is since it matches the design requirements (encryption, per-rid keyframe); not sure what the use cases would be for different subsets; it adds complexity (e.g. what happens if one is invalid)
16:14:04 <dom> Fippo: there are use cases which only require 2 layers, e.g. on this call
16:14:24 <dom> Youenn: but this a use case for Transformer - we have setParameters otherwise
16:14:53 <dom> Fippo: what would be return value? Originally, it returned a timestamp which wouldn't work for an array
16:15:07 <dom> Jan-Ivar: already changed to undefined
16:15:58 <dom> Dom: let's leave it as is; we can change it to DOMString or Array if there is an important use case
16:16:16 <dom> RESOLVED: Leave current API with single DOMString argument
16:16:24 <dom> Topic: RTCDataChannel (SDP and stats)
16:16:24 <dom> Subtopic: -> https://github.com/w3c/webrtc-extensions/issues/241 Always negotiate datachannels
16:16:24 <dom> [slide 33]
16:19:00 <dom> Jan-Ivar: the problem is that BUNDLE attaches to the first m-line by default?
16:19:21 <dom> Fippo: right; since datachannels can't be rejected, they're the right target for BUNDLE
16:19:28 <dom> Jan-Ivar: thanks, makes sense to me
16:19:33 <dom> Youenn: +1
16:19:54 <dom> ... would be good to look into a JSEP revision given this is a second item on the revision list
16:20:11 <dom> Fippo: I have a bunch of issues against JSEP, I can talk with Justin on a third revision
16:20:17 <dom> Jan-Ivar: that'd be great
16:20:29 <dom> ... are there any concerns on compat issues?
16:20:34 <dom> Fippo: sounds unlikely
16:20:52 <dom> Dom: let's file a JSEP issue at the same time
16:21:00 <dom> RESOLVED: Proceed with PR and JSEP issue
16:21:09 <dom> Subtopic: -> https://github.com/w3c/webrtc-stats/issues/805# What is the lifetime of stats?
16:21:09 <dom> [slide 34]
16:22:23 <dom> [slide 35]
16:24:23 <dom> Youenn: will changes there create web compat issues? hopefully there is still room for making the right decisions
16:24:35 <dom> Fippo: I have web compat concerns for inboundrtp, we'll see
16:25:02 <dom> Jan-Ivar: thanks a lot for the analysis, showing diversity across stats, implementations (not clear what the spec asks for)
16:25:21 <dom> ... when implementations have a shared behavior, that's hopefully a good direction to go
16:25:37 <dom> ... +1 to documenting and cleaning as much as web compat enables
16:26:43 <dom> Fippo: the problem is creating stat objects before the relevant object is indeed created
16:27:23 <dom> ... Documenting rules and their motivation would be good, before seeing what we can change
16:27:35 <dom> Jan-Ivar: another parameter to take into account is rollback
16:28:01 <dom> Harald: there was a specific situation with candidate pair that some pairs contain ip addresses that are considered sensitive
16:28:13 <dom> ... I don't know if that impacts on when they're exposed
16:28:23 <dom> Fippo: they're hidden, so it shouldn't matter
16:29:01 <dom> Harald: the number of outgoing datachannels you create shoudl be equal to the number reflected in stats; I would be in favor to have them show up early
16:29:13 <dom> Fippo: let's document the behavior and then disagree on the right one :)
16:29:44 <dom> TimP: I'm happy with it being early; it's unpleasant but necessary
16:30:04 <dom> Jan-Ivar: having it late mean having it more useful; more generally, for early stats, we should be clear on what data they expose
16:30:13 <dom> Fippo: will report on this at the next meeting
16:30:19 <dom> Subtopic: -> https://github.com/w3c/webrtc-pc/issues/3071 data channel ids set before SCTP init #3071
16:30:19 <dom> [slide 36]
16:32:44 <dom> TimP: in theory, you could request more datachannels than the other party would accept
16:32:51 <dom> Fippo: good point, we need to look into that
16:33:03 <dom> Jan-Ivar: another aspect is workers
16:33:17 <dom> ... if all browsers do the same thing, documenting it sounds good to me
16:33:30 <dom> RESOLVED: Proceed with a PR
16:33:43 <dom> Topic: -> https://github.com/w3c/mst-content-hint/issues/62 Bring Your Own Degradation Adaptation
16:33:43 <dom> [slide 39]
16:34:38 <dom> [slide 40]
16:35:27 <dom> [slide 41]
16:36:37 <dom> Jan-Ivar: SGTM
16:36:44 <dom> Fippo: +1
16:37:16 <dom> ... would it make sense to expose the QP on the insertable stream as well? (rather than using getStats)
16:37:28 <dom> Sergey: exposing QP per frame sounds good
16:37:32 <dom> Guido: please file an issue
16:37:55 <dom> TimP: also in favor; as Fippo said, there may be more data needed outside of stats
16:41:11 <dom> Fippo: maintain-framerate / maintain-resolution - this adds the 3rd point of the triangle (with balance in the center)
16:41:28 <dom> Guido: there is an existing PR where the conversation can continue
16:41:37 <dom> RESOLVED: proceed with PR
16:41:42 <dom> Topic: -> https://github.com/w3c/webrtc-encoded-transform/issues/262 SFrameEncrypterStream rename
16:41:42 <dom> [slide 44]
16:44:10 <dom> Youenn: the behavior is not undefined
16:44:47 <dom> ... that isn't to say having different objects would be useful - e.g. for decrypting/encrypting
16:45:00 <dom> ... initially, one object for everything was sufficient
16:46:01 <dom> Harald: initially, we thought SFrameTransform would be added as a first or last step in a chain of transforms
16:46:31 <dom> ... if we're abandoning that model (which I think we should since nobody has implemented), we should look at how to apply it to a sender/receiver
16:46:50 <dom> [slide 45]
16:48:46 <dom> Youenn: +1
16:48:57 <dom> ... we will be able to add management key APIs dedicated to decryption and encryption
16:49:14 <dom> ... we might be able to duplicate these APIs in SFrameTransform as well
16:49:31 <dom> ... letting the UA do the encryption sounds like a good thing in general
16:50:07 <dom> Harald: I would like to see an example of ScriptTransform and SFrameTransform together
16:50:18 <dom> Jan-Ivar: see slide
16:50:23 <dom> Harald: that makes sense
16:50:31 <dom> Jan-Ivar: that wouldn't work for SPacket though
16:51:16 <dom> Harald: SGTM
16:51:23 <dom> RESOLVED: Proceed with PR
16:51:26 <dom> RRSAgent, draft minutes
16:51:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/16-webrtc-minutes.html dom
18:33:29 <Zakim> Zakim has left #webrtc