Meeting minutes
Slideset: https://
PIP window Excluded while getDisplayMedia
Youenn: is this a hint from the user agent or web site?
Tove: web app
Jan-Ivar: PiP window - limited to opened by the web page, both video and document PiP?
… is this only for screen sharing? can't this be done by using tab or window capture?
Tove: this is for cases where you want to share your whole screen, e.g. because you'll want to show other apps
… also, full screen sharing remain the options many users pick for convenience
TimP: won't it be confusing for end users which window will or will not be included in what gets shared?
Tove: that's a valid concern; I think it has become common that floating UIs get treated differently from other windows
Jan-Ivar: I like that it's a hint - I assume the UA would allow to override the decision
… no issue with the API, but would hope for a better definition of what constitutes a PiP window
Tove: there is a spec about opening a PiP window from a web page
Jan-Ivar: so this would be limited to PiP windows as enabled by Video PiP and document PiP, not popups or permission dialogs?
Tove: right
Youenn: what would be the default? "include"?
Tove: yes
Youenn: sounds reasonable
RESOLUTION: Proceed with a PR to screen-share-extensions
Capabilites Element
Jan-Ivar: the constraints dictionary is slightly different from gUM - e.g. setting video=false or audio=false
… is the assumption is that using that element means asking for both?
Thomas: part of the issues we want to resolve
Youenn: do we need to set constraints for the <usermedia> element; if so, we should probably restrict it to prevent audio=false
… 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
… if it's to get one prompt for camera and microphone, then maybe not
… I understand this isn't part of the current prototype, if so we should wait for actual demand for this
Thomas: the goal is to enable configure audio and videos from the constraints
Jan-Ivar: I think long term <usermedia> should be used for cases where <camera> and <microphone> aren't a good fit
… if that's acceptable, then we could offer a migration path away from contraints audio=false
Jan-Ivar: what happens if you don't specific setConstraints - my expectation is that it would ask for both with default constraints
Thomas: yes
Jan-Ivar: generally supportive of that API
Thomas: right now setting audio=false would be an error
Jan-Ivar: is it still the case that the permission tied to access to and opening of a physical device?
thomas: yes; there are investigations in that space around private mode, but no concrete proposal
Jan-Ivar: next steps? merge PR and iterate?
Thomas: I would like it if we can merge and iterate; but maybe we can make progress on a couple of the listed issues
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
Jan-Ivar: SGTM, but I would want setConstraints included since it already doesn't allow false
Thomas: we have already 5 issues for later iteration
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
Daniel: I had a different proposal, but I'm not sure there is a precedent for ti
Jan-Ivar: queuing for fire event?
Youenn: nothing controversial, but needs some tightening
Guido: so we land a subset of PR with consensus?
Dom: does that or not include setConstraints?
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
Jan-Ivar: setConstraints so far only use to disable device types?
Thomas: right; the plan is to have generate an error with audio=false or video=false later on
Youenn: so setConstraints is part of MVP based on demand from web developers?
… I don't see setContraints exposed in usermedia element in Chrome source
Thomas: it's defined separately from the main element
Youenn: oh I see - it did ship with allowing audio=false
Thomas: we plan to change that
Youenn: then OK, let's keep it in PR
TimP: can we be confident that the impact of gUM on ice candidates will also apply to <usermedia>?
Jan-Ivar: that's how the spec describes it since it calls explicit gUM
… we could make it more explicit with a Note
Youenn: I think that's only defined on the IETF side of things, not in mediacapture and streams
Jan-Ivar: that may well be correct; if so, we should file an issue with the IETF IP Mode draft
… there is also work on local network permissions in the WICG which might provide a better hook for this
RESOLUTION: Merge PR at editors call taking into account comments on PR (e.g. state monitoring for <usermedia>)
Youenn: re IP mode, we can add notes to our WebRTC docs, and consider filing issues at the IETF
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)
… some of this may need updates in IETF land, but first updates to WebRTC
Youenn: we re-use the IP modes, and anchor this in the WebRTC spec
TimP: I'll file an issue in https://
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)
RTCRtpTransport update
Youenn: have you tried implementing an app with WebTransport and RTCTransport and compare their efficiency?
… since one of the goals is to improve perf
Philip: in the prototype, we basically a wasm version of PC to check whether things ran well, and they did
… we haven't made comparisons with other transports
… PC needs feel pretty different from other transports
… RTCTransport is P2P (which webtransport doesn't support), and you can implement your own congestion control
Youenn: you're saying WebTransport doesn't provide enough e.g. timing information to provide the same level of control
Philip: yes, there would be quite a bit limitations in terms of bandwidth estimation
Youenn: thanks; I remain a bit unclear about the direction of the API
Jan-Ivar: +1 on more data on performance
… WebTransport already does datagrams; comparison with data channels performance would be interesting
… as I've mentioned before, I don't think having a total bespoke API just for P2P purposes feel not optimal
… taking away control from the browser on congestion control feels tricky - e.g. how to deal with multiple tabs acting simultaneously
Philip: AFAIU, WebTransport doesn't provide custom congestion control; BBR doesn't perform well in some use cases
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
Philip: two main reasons: custom congestion control (vs a fixed low latency option in WebTransport) which allows quick iteration
… there is no low latency congestion control that would work for every applications
… a fixed approach doesn't allow to adapt to application-specific behaviors
Jan-Ivar: performance measurements would help, esp as this is being done on the main thread
TimP: data channels don't work under high loss situations
… playing with RTCTransport allows to deal much better and much more flexibly in terms of congestion control
… I'm very supportive of this and have played with it to try it out
… but we haven't made formal comparisons and measurements
Phil: is the perf question about comparison to WebTransport? or how much throughput it allows?
Jan-Ivar: it's more about justify a bespoke API based on performance improvements
Philip: with some patching to buffers, we managed to get 1Gb/s through this API
Jan-Ivar: comparing with WebTransport and data channels would be helpful
… WebTransport is built on top of QUIC which comes with a lot of features, incl dynamic route changing
… part of the concern here is trying to do networking at the W3C layer
Philip: roaming support in QUIC does not equate to route management since it doesn't give control on the timing and prioritization of routes
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)
… although I don't think we're able to measure this yet
Youenn: I suggest we file issues to continue discussion on these performance validation
SFrame
Issue #305 Sending simulcast and per ssrc-encryption
Harald: do each stream with a separate id get a separate key?
Youenn: good question - worth filing an issue
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
Youenn: it's optional; but I guess you support option C then
Jan-Ivar: +1
TimP: not sure I understand why you need to add an option to the transform
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
Harald: options reduce interop; if there is only way to do it, that's usually better
Youenn: so enforcing key derivation?
Harald: I think we would need a strong argument to not do that
Kacper: I'm concerned about SFUs which are doing ssrc rewriting
Youenn: you would need to know the ssrc before which could trigger an issue, which might justify making it optional
… what is webex doing? is it using per-ssrc derivation?
Peter: what is the motivation for having separate keys for the separate simulcast streams?
Youenn: I know some apps are doing key derivation for different senders
Harald: with key derivation, they're all derived from one key
Peter: but we don't that for SRTP
Youenn: but SRTP is hop-by-hope, not end-to-end
Harald: SRTP uses different keys from RTP and RCTP; but all of this is mostly internal
Peter: the reason I don't like C is that it ties SFrame to RTP
Youenn: I'll need to research this more; e.g. I don't know how apps using ScriptTransform handle this
Peter: if each streams already use different keys, doing the same for simulcast makes sense
Youenn: that would be B or C
Jan-Ivar: my preference is for any option that doesn't need to an option
Youenn: not sure that's feasible given the need to adapt to different apps
SFrame and frame marking
Jan-Ivar: I think we should have a useful default for SFrame with a custom-setting API
Harald: doubtful about making the packet more complex by default
… adding a dependency descriptor when not needing reveals a bit part of the stream, which may defeat the goal of using SFrame for privacy
Youenn: at the cost of worse SFU behavior
… so only mentioning them, not enabling them by default
Jan-Ivar: not every browser implementation the setnegotiatedheader API
… which supports the idea of good defaults
Harald: but is "good" more privacy-supportive or SFU-supportive?
Jan-Ivar: maybe we can a privacy-vs-perf option?
Youenn: is webex using framemarking with SFrame?
Kacper: we don't need it but we're not using the standards-based sframe