15:01:15 <RRSAgent> RRSAgent has joined #webrtc
15:01:19 <RRSAgent> logging to https://www.w3.org/2026/05/19-webrtc-irc
15:01:19 <Zakim> Zakim has joined #webrtc
15:01:19 <dom> RRSAgent, make log public
15:02:13 <dom> Meeting: WebRTC May 2026 meeting
15:02:13 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/Ma__19_2026
15:02:13 <dom> Slideset: https://docs.google.com/presentation/d/15M9QqV_fcYXBmRhkiiIwbncf4RsALK04LPeqbTHetMk/
15:02:13 <dom> Chairs: Guido, Jan-Ivar, Youenn
15:02:14 <dom> Present: Guido, Dom, Jan-Ivar, Harald, PeterT, KacperWasniowski, Youenn
15:02:35 <dom> Present+ ErikSprang
15:02:50 <dom> Present+ SunShin
15:03:33 <dom> Present+ TimP
15:04:02 <dom> Recording is starting
15:05:08 <dom> Present+ DanielVogelheim
15:05:33 <dom> Present+ BartoszHabrajski
15:05:46 <dom> Topic: -> https://github.com/w3c/mediacapture-screen-share/issues/330 PIP window Excluded while getDisplayMedia
15:05:46 <dom> [slide 10]
15:06:16 <dom> [slide 11]
15:06:38 <dom> [slide 12]
15:07:06 <dom> [slide 13]
15:07:54 <dom> Youenn: is this a hint from the user agent or web site?
15:07:58 <dom> Tove: web app
15:08:31 <dom> Jan-Ivar: PiP window - limited to opened by the web page, both video and document PiP?
15:08:53 <dom> ... is this only for screen sharing? can't this be done by using tab or window capture?
15:09:17 <dom> Tove: this is for cases where you want to share your whole screen, e.g. because you'll want to show other apps
15:09:37 <dom> ... also, full screen sharing remain the options many users pick for convenience
15:10:06 <dom> TimP: won't it be confusing for end users which window will or will not be included in what gets shared?
15:10:46 <dom> Tove: that's a valid concern; I think it has become common that floating UIs get treated differently from other windows
15:11:19 <dom> Jan-Ivar: I like that it's a hint - I assume the UA would allow to override the decision
15:11:37 <cabanier> cabanier has joined #webrtc
15:11:37 <geheimnis`> geheimnis` has joined #webrtc
15:11:37 <slightlyoff> slightlyoff has joined #webrtc
15:11:37 <timeless> timeless has joined #webrtc
15:11:37 <Josh_Soref> Josh_Soref has joined #webrtc
15:11:40 <dom> ... no issue with the API, but would hope for a better definition of what constitutes a PiP window
15:11:56 <dom> Tove: there is a spec about opening a PiP window from a web page
15:12:22 <dom> Jan-Ivar: so this would be limited to PiP windows as enabled by Video PiP and document PiP, not popups or permission dialogs?
15:12:24 <dom> Tove: right
15:12:43 <dom> Youenn: what would be the default? "include"?
15:12:44 <dom> Tove: yes
15:12:52 <dom> Youenn: sounds reasonable
15:13:22 <dom> RESOLVED: Proceed with a PR to screen-share-extensions
15:13:38 <dom> Present+ ThomasNguyen
15:13:43 <dom> Topic: -> https://github.com/w3c/mediacapture-extensions/pull/168 Capabilites Element
15:13:43 <dom> [slide 16]
15:16:17 <dom> [slide 17]
15:17:21 <englishm> englishm has joined #webrtc
15:17:21 <jh> jh has joined #webrtc
15:17:27 <cabanier> cabanier has joined #webrtc
15:17:27 <geheimnis`> geheimnis` has joined #webrtc
15:17:27 <slightlyoff> slightlyoff has joined #webrtc
15:17:27 <timeless> timeless has joined #webrtc
15:17:27 <Josh_Soref> Josh_Soref has joined #webrtc
15:18:18 <dom> Jan-Ivar: the constraints dictionary is slightly different from gUM - e.g. setting video=false or audio=false
15:18:30 <dom> ... is the assumption is that using that element means asking for both?
15:18:42 <cabanier> cabanier has joined #webrtc
15:18:42 <geheimnis`> geheimnis` has joined #webrtc
15:18:42 <slightlyoff> slightlyoff has joined #webrtc
15:18:42 <timeless> timeless has joined #webrtc
15:18:42 <Josh_Soref> Josh_Soref has joined #webrtc
15:18:43 <dom> Thomas: part of the issues we want to resolve
15:18:46 <dom> [slide 18]
15:19:55 <dom> Youenn: do we need to set constraints for the <usermedia> element; if so, we should probably restrict it to prevent audio=false
15:20:20 <dom> ... but is it needed first? if the main use case is to have a prompt for permission for capture, it's not really needed it
15:20:38 <dom> ... if it's to get one prompt for camera and microphone, then maybe not
15:21:10 <dom> ... I understand this isn't part of the current prototype, if so we should wait for actual demand for this
15:21:28 <dom> Thomas: the goal is to enable configure audio and videos from the constraints
15:21:58 <dom> Jan-Ivar: I think long term <usermedia> should be used for cases where <camera> and <microphone> aren't a good fit
15:22:37 <dom> ... if that's acceptable, then we could offer a migration path away from contraints audio=false
15:22:56 <dom> Jan-Ivar: what happens if you don't specific setConstraints - my expectation is that it would ask for both with default constraints
15:23:03 <dom> Thomas: yes
15:23:11 <dom> Jan-Ivar: generally supportive of that API
15:23:45 <dom> Thomas: right now setting audio=false would be an error
15:24:43 <dom> Jan-Ivar: is it still the case that the permission tied to access to and opening of a physical device?
15:25:15 <dom> thomas: yes; there are investigations in that space around private mode, but no concrete proposal
15:25:26 <dom> Jan-Ivar: next steps? merge PR and iterate?
15:25:50 <dom> Thomas: I would like it if we can merge and iterate; but maybe we can make progress on a couple of the listed issues
15:27:15 <dom> Youenn: OK with merging, but maybe best to remove setConstraints from the PR and adding it back later; or whether <usermedia> should react to camera stopping; one of my comments was that applying state monitoring we do for <camera> for <usermedia> as well; if we're unclear, maybe best to merge a smaller version of the PR where consensus is clear
15:27:30 <dom> Jan-Ivar: SGTM, but I would want setConstraints included since it already doesn't allow false
15:27:37 <dom> [slide 19]
15:27:56 <dom> Thomas: we have already 5 issues for later iteration
15:28:55 <dom> Jan-Ivar: re secure context - an element can't be restricted to secure context, but it would probably not functional outside of secure context and generate an error
15:29:14 <dom> Daniel: I had a different proposal, but I'm not sure there is a precedent for ti
15:30:12 <dom> Jan-Ivar: queuing for fire event?
15:30:24 <dom> Youenn: nothing controversial, but needs some tightening
15:31:10 <dom> Guido: so we land a subset of PR with consensus?
15:31:18 <dom> Dom: does that or not include setConstraints?
15:31:51 <dom> Youenn: if it's implemented, that may change my position; overall, I would prefer keeping <usermedia> as simple as possible since down the line we prefer <camera> and <microphone> as target
15:32:21 <dom> Jan-Ivar: setConstraints so far only use to disable device types?
15:32:54 <dom> Thomas: right; the plan is to have generate an error with audio=false or video=false later on
15:33:08 <dom> Youenn: so setConstraints is part of MVP based on demand from web developers?
15:33:31 <englishm> englishm has joined #webrtc
15:33:31 <jh> jh has joined #webrtc
15:33:43 <dom> ... I don't see setContraints exposed in usermedia element in Chrome source
15:34:17 <dom> Thomas: it's defined separately from the main element
15:34:27 <dom> Youenn: oh  I see - it did ship with allowing audio=false
15:34:31 <dom> Thomas: we plan to change that
15:34:40 <dom> Youenn: then OK, let's keep it in PR
15:35:07 <englishm> englishm has joined #webrtc
15:35:07 <jh> jh has joined #webrtc
15:35:31 <dom> TimP: can we be confident that the impact of gUM on ice candidates will also apply to <usermedia>?
15:35:57 <dom> Jan-Ivar: that's how the spec describes it since it calls explicit gUM
15:36:12 <dom> ... we could make it more explicit with a Note
15:37:23 <dom> Youenn: I think that's only defined on the IETF side of things, not in mediacapture and streams
15:37:48 <dom> Jan-Ivar: that may well be correct; if so, we should file an issue with the IETF IP Mode draft
15:38:21 <dom> ... there is also work on local network permissions in the WICG which might provide a better hook for this
15:39:30 <dom> RESOLVED: Merge PR at editors call taking into account comments on PR (e.g. state monitoring for <usermedia>)
15:40:23 <dom> Youenn: re IP mode, we can add notes to our WebRTC docs, and consider filing issues at the IETF
15:41:16 <dom> Harald: I think we should separate the concept of having permissions to access IP addresses in WebRTC, which would then activated by different mechanisms (incl gUM)
15:41:35 <dom> ... some of this may need updates in IETF land, but first updates to WebRTC
15:42:07 <dom> Youenn: we re-use the IP modes, and anchor this in the WebRTC spec
15:42:19 <dom> TimP: I'll file an issue in https://github.com/w3c/webrtc-pc/issues/
15:43:02 <dom> Jan-Ivar: I've filed a related issue wrt mDNS and the relationship to IP mode where there are already compat issues (e.g. permissions vs active state)
15:43:20 <dom> Topic: -> https://github.com/w3c/webrtc-rtptransport/ RTCRtpTransport update
15:43:20 <dom> [slide 23]
15:44:09 <dom> Present+ PhilipEliasson
15:45:13 <englishm> englishm has joined #webrtc
15:45:13 <jh> jh has joined #webrtc
15:45:49 <dom> [slide 24]
15:46:53 <dom> [slide 26]
15:49:08 <dom> [slide 27]
15:51:43 <dom> [slide 28]
15:53:26 <dom> [slide 29]
15:54:19 <dom> [slide 30]
15:55:58 <dom> Youenn: have you tried implementing an app with WebTransport and RTCTransport and compare their efficiency?
15:56:27 <dom> ... since one of the goals is to improve perf
15:57:06 <dom> Philip: in the prototype, we basically a wasm version of PC to check whether things ran well, and they did
15:57:06 <dom> ... we haven't made comparisons with other transports
15:57:50 <dom> ... PC needs feel pretty different from other transports
15:58:21 <dom> ... RTCTransport is P2P (which webtransport doesn't support), and you can implement your own congestion control
15:58:52 <dom> Youenn: you're saying WebTransport doesn't provide enough e.g. timing information to provide the same level of control
15:59:17 <dom> Philip: yes, there would be quite a bit limitations in terms of bandwidth estimation
15:59:35 <dom> Youenn: thanks; I remain a bit unclear about the direction of the API
15:59:43 <dom> Jan-Ivar: +1 on more data on performance
16:00:05 <dom> ... WebTransport already does datagrams; comparison with data channels performance would be interesting
16:00:32 <dom> ... as I've mentioned before, I don't think having a total bespoke API just for P2P purposes feel not optimal
16:01:12 <dom> ... taking away control from the browser on congestion control feels tricky - e.g. how to deal with multiple tabs acting simultaneously
16:01:56 <dom> Philip: AFAIU, WebTransport doesn't provide custom congestion control; BBR doesn't perform well in some use cases
16:02:30 <dom> Jan-Ivar: congestion control isn't specified, although there is an API control to ask for lower latency (not implemented yet) - that could be improvide if that's the only for a different API
16:03:06 <dom> Philip: two main reasons: custom congestion control (vs a fixed low latency option in WebTransport) which allows quick iteration
16:03:34 <dom> ... there is no low latency congestion control that would work for every applications
16:03:57 <dom> ... a fixed approach doesn't allow to adapt to application-specific behaviors
16:04:46 <dom> Jan-Ivar: performance measurements would help, esp as this is being done on the main thread
16:06:53 <dom> TimP: data channels don't work under high loss situations
16:07:45 <dom> ... playing with RTCTransport allows to deal much better and much more flexibly in terms of congestion control
16:07:57 <dom> ... I'm very supportive of this and have played with it to try it out
16:08:11 <dom> ... but we haven't made formal comparisons and measurements
16:08:40 <dom> Phil: is the perf question about comparison to WebTransport? or how much throughput it allows?
16:09:04 <dom> Jan-Ivar: it's more about justify a bespoke API based on performance improvements
16:09:35 <dom> Philip: with some patching to buffers, we managed to get 1Gb/s through this API
16:09:49 <dom> Jan-Ivar: comparing with WebTransport and data channels would be helpful
16:10:39 <cabanier> cabanier has joined #webrtc
16:10:39 <geheimnis`> geheimnis` has joined #webrtc
16:10:39 <slightlyoff> slightlyoff has joined #webrtc
16:10:39 <timeless> timeless has joined #webrtc
16:10:39 <Josh_Soref> Josh_Soref has joined #webrtc
16:10:50 <dom> ... WebTransport is built on top of QUIC which comes with a lot of features, incl dynamic route changing
16:11:03 <dom> ... part of the concern here is trying to do networking at the W3C layer
16:11:40 <dom> Philip: roaming support in QUIC does not equate to route management since it doesn't give control on the timing and prioritization of routes
16:12:18 <dom> TimP: a useful test might be to look at what happen at saturation in data channels vs this API (where I expect you would get better outcomes)
16:12:26 <dom> ... although I don't think we're able to measure this yet
16:12:51 <dom> Youenn: I suggest we file issues to continue discussion on these performance validation
16:13:05 <dom> Topic: -> https://github.com/w3c/webrtc-encoded-transform/ SFrame
16:13:05 <dom> Subtopic: Issue #305 Sending simulcast and per ssrc-encryption
16:13:05 <dom> [slide 33]
16:13:33 <dom> RRSAgent, draft minutes
16:13:35 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/19-webrtc-minutes.html dom
16:15:05 <dom> Harald: do each stream with a separate id get a separate key?
16:15:17 <dom> Youenn: good question - worth filing an issue
16:16:58 <dom> Harald: if the IETF have already put in the spec to do key derivation based on SSRC, that seems like an excellent option to follow
16:17:10 <dom> Youenn: it's optional; but I guess you support option C then
16:17:24 <dom> Jan-Ivar: +1
16:17:44 <dom> TimP: not sure I understand why you need to add an option to the transform
16:18:19 <dom> Youenn: if you don't do simulcast, you would be able to say to the transform whether to use the key directly or derived from SSRC
16:19:22 <dom> Harald: options reduce interop; if there is only way to do it, that's usually better
16:19:28 <dom> Youenn: so enforcing key derivation?
16:19:44 <dom> Harald: I think we would need a strong argument to not do that
16:20:12 <dom> Kacper: I'm concerned about SFUs which are doing ssrc rewriting
16:20:33 <dom> Youenn: you would need to know the ssrc before which could trigger an issue, which might justify making it optional
16:20:48 <dom> ... what is webex doing? is it using per-ssrc derivation?
16:21:50 <dom> Peter: what is the motivation for having separate keys for the separate simulcast streams?
16:22:12 <dom> Youenn: I know some apps are doing key derivation for different senders
16:22:34 <dom> Harald: with key derivation, they're all derived from one key
16:22:46 <dom> Peter: but we don't that for SRTP
16:22:57 <dom> Youenn: but SRTP is hop-by-hope, not end-to-end
16:23:25 <dom> Harald: SRTP uses different keys from RTP and RCTP; but all of this is mostly internal
16:24:35 <dom> Peter: the reason I don't like C is that it ties SFrame to RTP
16:26:08 <dom> Youenn: I'll need to research this more; e.g. I don't know how apps using ScriptTransform handle this
16:26:38 <dom> Peter: if each streams already use different keys, doing the same for simulcast makes sense
16:26:44 <dom> Youenn: that would be B or C
16:26:55 <dom> Jan-Ivar: my preference is for any option that doesn't need to an option
16:27:07 <dom> Youenn: not sure that's feasible given the need to adapt to different apps
16:27:23 <dom> [slide 34]
16:28:46 <dom> Subtopic: SFrame and frame marking
16:29:29 <dom> Jan-Ivar: I think we should have a useful default for SFrame with a custom-setting API
16:29:48 <dom> Harald: doubtful about making the packet more complex by default
16:30:31 <dom> ... adding a dependency descriptor when not needing reveals a bit part of the stream, which may defeat the goal of using SFrame for privacy
16:30:57 <dom> Youenn: at the cost of worse SFU behavior
16:31:06 <dom> ... so only mentioning them, not enabling them by default
16:31:29 <dom> Jan-Ivar: not every browser implementation the setnegotiatedheader API
16:31:42 <dom> ... which supports the idea of good defaults
16:31:58 <dom> Harald: but is "good" more privacy-supportive or SFU-supportive?
16:32:17 <dom> Jan-Ivar: maybe we can a privacy-vs-perf option?
16:32:33 <dom> Youenn: is webex using framemarking with SFrame?
16:32:54 <dom> Kacper: we don't need it but we're not using the standards-based sframe
16:33:22 <dom> Subtopic: Issue #307 SFrame Receiver transform may trigger lots of events
16:33:22 <dom> [slide 35]
16:33:52 <dom> RRSAgent, draft minutes
16:33:53 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/19-webrtc-minutes.html dom
18:13:13 <Zakim> Zakim has left #webrtc