Meeting minutes
Slideset: https://
(as an experiment, transcription will be done automatically)
Thank you Harald
Jan-Ivar: first order of business is to thank Harald Alvestrand. He's retiring. So we wish to celebrate a founding figure of WebRTC on his retirement. He's the former chair. You all know him as our former and founding chair of this working group. He's also been a core contributor from the start and the author and of the RTC overview draft RTC web overview draft that later became RFC 8825. He helped launch the standardization effort itself shaping the original working group charter and much of the spec. And in 2011 he announced Google's release of the WTC source code a turning point for real-time communication on the open web. And he also has decades of standards leadership including as IETF chair.
Harald: So, it's been a while. June 30 is the last day that I'm I'll be working for Google. I mean WebRTC has been my main mission since 2010 when I first presented the idea at the IETF meeting in Maastricht. Working in this in many aspects actually writing about it, leading groups about it and especially discussing about it was a chair for 13 years from in inception of this group until Guido was good enough to take over for it. For me, that was a relief in so many ways. Not quite my life's work, but significant chunk, but uh I'm laying down my keyboard as a full-time contributor. Don't promise to be around. Don't promise to stay away. But we'll see. Other things in life are more important. nothing easy. There are lots of disagreements and lots of fights, but we got to agreements a lot of the time. And I think that what we did was actually making the world a better place. And I leave you all to take care of it, to take it to the next level, wherever that is. I think you have the power and the skill and the will. Go on making the world a better place. So, thanks for all the fish.
Jan-Ivar: Thank you Harald. Thank you for your vision, your rigor, your generosity over all these years. And I think webRTC exists in no small part because of you. So enjoy your retirement. You've definitely earned it.
Rechartering
Jan-Ivar: The WG is chartered until 30 September. So we need to recharter to finish the remaining work and we don't plan to change scope necessarily but we need to you know we don't want to expand our scope when we have a lot of work left to do. So that said we will still welcome agenda items if people have energy in certain areas that they want to cover. But we thought it was good to go over our list of publications and some of the chair's preliminary plans for the remaining work. So we have the link here that lists our publications. We have one recommendation which is WebRTC-PC. We have five candidate recommendations, 12 working drafts, one draft note and one discontinued draft. We also have two editors draft that are the extensions drafts for webRTC-PC and mediacapture-main.
Jan-Ivar:
So we're going to cover the remaining items here. We have five candidate recommendations currently and we're going to go over the following slides using this legend of spec name with current status our proposed short-term action with some describing comments and qualifiers, and the final target. And so this is open for discussion. So we can just take questions along the way and I'll just narrate the list here.
We have the WebRTC priority control API and CR snapshot. We're thinking of moving that to WebRTC-PC and WebRTC extensions based on some parts, the ultimate goal is WebRTC-PC but they might the individual APIs we might depend on the number of implementations whether they go into the PC version or the extensions version.
Identity for WebRTC is in CR Snapshot. The plan here is to retire once we have SFrame in WebRTC extensions at which point this would be discontinued.
We have the audio output devices API for speakers
Tim Panton: on the identity piece, is there anything we else that we lose in that? Because there was like originally quite a lot of stuff attached to it. is there anything that we're we're going to lose by doing that?
Tim Panton: I'm thinking particularly about the certificate handling and maybe some other, the thing where you couldn't copy frame you couldn't copy video streams, were those it defined in that or defined elsewhere I've lost track.
Jan-Ivar: I don't think there's any plan to move. So the identity spec had some unique features that relied on the browsers cross origin protections for video and maybe audio. Identity was leaning on that by allowing users in of a browser to register an identity provider and basically treat content as opaque so that the JavaScript could not access similar to how JavaScript cannot access cross origin video and audio. There's no plan to move that forward that I am aware of. There was only one implementation which is in Firefox and I think the goal would be to drop those efforts. Criticism of those APIs have been that they don't cover data, so I think the idea is that with Sframe we have a better approach for securing not just video and audio but also data.
Tim Panton: I'll reread the um thing we're proposing to discontinue and see if we're losing anything that I care about
Jan-Ivar: Please file issues and any questions and concerns you have. This is basically just the chair's overall plan, we're happy to take input on individual items.
Jan-Ivar: audio output devices CR draft. The plan there is to do a short triage and publish a CR snapshot with the final target being CR, meaning that we don't believe we have the energy to push this one to REC necessarily.
Jan-Ivar: not every spec needs to go to recommendation necessarily because that's a lot of work.
Jan-Ivar:media capture and streams, CR draft, the goal there is to triage and publish a CR snapshot pretty soon. Right now it's in the CR draft, which is a less stable state for CR with a long-term plan of reaching REC in 2027.
Jan-Ivar:WebRTC test spec, also is in CR draft. The plan there is to just publish another snapshot and with a final goal of CR.
Jan-Ivar: we also have 12 working drafts. we have WebRTC Encoded Transform which we plan to do a short triage and publish a CR snapshot of with a plan long-term plan of getting to recommendation in 2028. We have mediaStreamTrack insertable media processing using streams, where we plan to publish the CR snapshot for a final goal of CR, media stream recording publish CR snapshot with goal of CR, MediaStreamTrack content hints, the plan is to move the content hints and their effect on things like constraints to the media capture main spec and media capture recorder and to move the degradation preference parts to a WebRTC-PC as those have a pretty good implementation and in that case I should have added an arrow here that means content hit would be discontinued once that has happened.
Jan-Ivar: For screen capture, the plan is to triage and publish the CR snapshot with the final goal of CR. For media stream image capture, currently a working draft and the plan is to leave it as a working draft.
Jan-Ivar:And the final six here is Capture Handle - bootstrapping and collaboration when screen sharing, leave as a working draft. Media capture from DOM elements is fairly mature in implementation but has some rough edges. The idea here is to publish the CR snapshot with the final goal of CR.
Jan-Ivar:for Viewport Capture, leave as is a working draft. Scalable video coding (SVC) extensions for WebRTC. The plan there is to move to WebRTC-PC leaving this spec discontinued. Alternatively it could go to WebRTC extensions but I think Firefox is working to implement this, so that would satisfy the two implementations requirement.
Jan-Ivar: for Region capture the plan is to leave as is a working draft and media cap media stream capture scenarios the plan is to retire. Final goal is discontinued state.
Jan-Ivar:Then we have a draft note and two editor's drafts. So we have WebRTC extended use cases. The plan is to discontinue that. For WebRTC extensions, which is an editors draft, we split to webRTC-PC into to in order to get it to REC. The plan is to move things that can be moved to webRTC-PC and to leave and publish the rest as a working draft. And same thing for media capture extensions. Move what can be moved to media capture main and publish the rest as is. And the last one is media capture depth streams extensions which is already discontinued.
Jan-Ivar: So if all this works out, in two years we would hopefully have three recommendations(WebRTC, WebRTC Encoded Transform, media capture main), six candidate recommendations, six working drafts and six for discontinued drafts. So this is the chair's proposed plan. So now questions, comments, concerns?
Youenn: overall it seems okay to me. I would like to mention that it's still an important effort for editors and we have fewer and fewer editors. So there's also this issue which is how we increase the editors' energy and time. Also we didn't talk really about PepC so maybe it's already covered elsewhere and we don't have to mention it but or maybe we should mention it in somehow in the charter.
Jan-Ivar: do you think we need to change our scope for that one? it's a unique solution to permissions, but it should be covered
Youenn: it's probably covered. I don't know whether we want to make it explicit or not.
Jan-Ivar: Okay. Now I think that work is happening in media capture extensions. So I think the goal would be to try to move it to media capture main. Would we do that before REC? we could try but the devil is in the details for some of these things. Our goal was to outline a vision, an initial plan and hopefully basically as sort of a guide for where we would direct our energy unless informed otherwise by members.
Youenn: I tend to agree, but I would say PepC is one thing that we might put energy in. So maybe it's worth being more explicit.
Sun Shin: I have a question about discontinued, especially about WebRTC extension. Could you explain what does discontinued means for these specs or discussions?
Jan-Ivar: We already have Media capture depth stream extensions that's already been discontinued. That's basically when the document is still available but as far as standards track it has been discontinued, it's still available but no longer being worked
Jan-Ivar: every document is on the standard track with the exception of WebRTC extensions and media capture extensions which are editors drafts, the goal for APIs in those two particular specs is to eventually be moved into media capture main or over WebRTC-PC and the criteria we've used there is one implementation plus one implementation interest in order to move things. So those two specs are kind of a holding pen that we want to get rid of eventually by moving them into the target spec. And for things we cannot move, we would probably publish as a working draft, not discontinue, if that makes sense. So the ones being discontinued are WebRTC extended use cases and Media Stream capture scenarios and identity
Jan-Ivar: WebRTC extensions and media capture extensions will be published as working drafts if there's anything left in them that wasn't moved.
Harald: So the obvious leftover from that doesn't have a CR or REC path but is widely used is Stats, that says leave as CR.
Jan-Ivar: That's a good question. Stats is sort of a an interesting case because a subset of the stat spec is required as mandatory to implement in webRTC-PC and the long tail of that I guess is not mandatory to implement.
Harald: I think it's been in CR for a while.
Jan-Ivar: right so I think to go in order to get the recommendation we'd need two implementations of every stat and that might be a tall order.
Harald: Could it still be a viable approach to designate this as living standard?
Youenn: it's one way of doing things.
Jan-Ivar: a cheap way of having a living standard is to stay in CR basically forever. We have WebRTC where we actually have recommendation and we're still sort of editing it and updating it but there's a lot of effort with that model perhaps. So I think I'm not sure the W3C has figured out the best way to maintain live standards and there are at least two options we seem to have here. I would say for stats we have the additional option of extending the list of mandatory to implement stats in WebRTC-PC which would effectively give us a way to nail down additional stats as we choose.
Harald: Well, that's a downref.
Jan-Ivar: So I think the best solution there is to keep it in CR forever because that gives us flexibility but if we can get it to REC we would not oppose going to REC but it would require an implementer effort.
Harald: And it would probably require some kind of holding pen that for the stuff that can't make it to REC because there's enough stuff there that is operationally important.
Carine: The difference between living standard CR and REC is that the living standard CR has not necessarily been tested against two implementations while the recommendation has passed the criteria for interop.
Jan-Ivar: That makes sense.
TPAC 2026
Youenn: deadline to request meeting slot is tomorrow. What do people think?
Carine: We should be rechartered by then. So I think we can reserve room.
Youenn: plan might be to allocate time for European afternoon sessions so that it's sort of skill friendly for US people.,/p>
ACTION: Youenn to request meeting slots at TPAC 2026
mDNS & Local Network Access
Youenn: Jan-Ivar filed an issue about Firefox being prompted on Mac OS mDNS and basically the prompt was related to local network access.
Youenn: So first there's the Mac OS prompt. I will talk about it. But there's also the WICG local network access stack which is highly related to that. So, it's a not a really new spec because it's already implemented in Chrome and Firefox I think but it's still evolving. It's a new permission-based API that is gating public web pages from accessing local sites. The typical use case is you have a public page and it's trying to reach the user's home router. So it may be for good reasons. Maybe the web page is owned by the manufacturer of the home router and it's doing config, or maybe it's a hacker. This spec is defining is what is the local network, and then a permission prompt. Here you can see two examples of prompts, one from Chrome on the left and Firefox on the right, I believe and it's something like "allow this website to access apps and services on devices connecting to your local network" or it's "this website wants to look for and connect to any device on your local network".
Youenn: It's focusing on HTTP websocket web transport for now at least implementation-wise but the scope of the spec I believe, so webRTC is also in scope, even if not implementation-wise.
Youenn: the spec has no notion of webRTC. So there's some effort that should be done there and I'm guessing that it's some effort that could be a joint effort between the WICG and some webRTC folks as well.
Harald: there is an implementation in Chrome for webRTC actually. I think it's behind a flag
Youenn: So maybe there's an action for the implementers there to update the spec somehow or provide a PR. That would be nice. And then maybe uh the webRTC working group could review and and provide feedback or it could be discussed here maybe.
Youenn: the spec is defining two new permissions. One is called "local-network" access and it's really the router use case. The other one is "loopback-network" access, gating requests to loopback addresses and it's sort of related to the localmess, I guess.
Tim Panton: So I'm a bit worried about the definition of local networks for IPv6. Maybe it's not in scope in this discussion now, but my public IP address and my local IP address for IPv6 may or may not be the same. So that needs to be discussed maybe in more depth at some other point.
Youenn: I haven't precisely looked at that point. I know there are some IPv6 non-persistent addresses that can be used and probably the spec is saying something about it.
Youenn: Since there are two new permissions, there's integration with the permission API. So the web page can query whether local network or loopback network access is granted, denied or whether it's unknown and user should be prompted and there's also a permissions policy which allows delegation from iframe and it's also allowing the website itself to for instance disable local network access. So no prompt means it's always denied for instance.
Youenn: Getting back to Jan-Ivar's issue, in Mac OS there's now an OS-level gate for accessing local network and it's gating webRTC. Some applications were actually trying to get as much information about the user, including on the user's local network, for instance getting all mDNS services. That can be used to fingerprint the user or to better know the user, basically steal information from the user. These applications were not using that mDNS information to connect or do whatever.
Youenn: Giving the user the ability to decide whether an application should get access to this information is quite useful. The scope is local network, not loopback, and here's an example of a prompt, like "allow this application to find devices on local networks". Since it's OS based it's application-wide. it's not per origin. Within WebRTC this particular prompt can happen at two times. The first is happening when setRemoteDescription or addIceCandidate is called, if you have an mDNS ICE candidate in either the SDP or you're adding it then the user agent will try to do mDNS resolution. This really create a simulCast message and this message will trigger the prompt. Even if you do not have mDNS candidates, if you still have like local network IP addresses in your candidates, for instance there are like two user agents, one has the access of its own private IP addresses and it's sending it to the other peer then the other peer will try to connect to local network access and this will also trigger the prompt.
Youenn: So in one case it's happening when there's actually a connection try, which is probably good, and in the other case it's happening very quickly whenever there's an mDNS candidate.
Youenn:
Is there a path forward for mDNS ICE candidates? because mDNS ICE candidates were designed to protect the user and now we're seeing that there's a prompt very quickly. First they're UUID v4-based so they're basically non-persistent, they're randomly generated so they do not carry a lot of information. Based on that there might be a possibility to only prompt if there's a chance to connect and not prompt as soon as you try to resolve the mDNS UUID name. In case of successful resolution normally you try to connect and then if you're trying to connect the prompt would happen but if the resolution fails which would be the case a lot of time there would be no prompt.
So that would reduce prompt fatigue and could be a a solution forward.
We need to investigate it. So having feedback from you on this would be interesting.
Youenn: As you can see local network access is prompting in case of loopback and one reason is that it's blocking abuses like we've seen with localmess.io, which basically was doing cross-app tracking via localhost using STUN messages, so webRTC at least. It's interesting to see whether mDNS resolution would be okay for loopbacks. There's a known issue I haven't seen a lot of activity recently but it's worth restarting the effort. It seems that it might be depending on whether the OS is allowing every app to know about its mDNS names. If only the OS knows about the mDNS names then maybe it's fine and one possibility would be to only expose these names to people trying to query them and not trying to enumerate them by default to every app that wants them.
Youenn: Loopback is also heavily used for testing so having a prompt for local loop within the user agent is something that might not be desirable. I believe user agents can decide for their own registered mDNS names, they could decide whether to prompt for these names and sockets that they know of. And of course for legitimate webRTC cases like loopback in the same page they should not prompt basically and if there are some abuse cases then maybe we should describe them and then there should be a prompt.
[slide 23]Youenn: There was an issue filed a long time ago about adding a prompt that would allow to get access to mode 2 from webRTC IP address handling meaning getting access to the default private IP.
Today you a web page can get access to this IP address but gUM or getDisplayMedia must be called beforehand. So the issue was about adding a prompt and I think it was closed because there was no real activity and this would require another spec. So now we have sort of a spec. This prompt from local network access could allow to migrate to mode 2. Mode 1 is allowing to enumerate all interfaces, could be discussed but it seems more difficult to me.
Youenn: Feedback would be interesting. I was wondering whether we also want an explicit API to trigger the prompt. Currently to trigger the prompt you need to either connect. Maybe the website would want to connect OR would want to show the prompt beforehand. Usually network access is done asynchronously, it's done in the background. There's no user gesture. So it's a bit more difficult than a prompt for camera access where usually you expect to user gesture.
Youenn: Is there a need for an API to suppress the prompt for webRTC if a web page really does not want to have a prompt there? there's the permissions policy API with a HTTP header for instance. Do we need an API to disable web mDNS support, or uh like local network access to WebRTC? That's something we could also discuss.
Jan-Ivar: Two comments. The first is looking at RFC 8828, I believe user media gates mode one.
Youenn: Yes, in Chrome, not in Safari, don't know for FF
Jan-Ivar: I believe it's mode 1.
but it sounds to me that getUserMedia was always like a bit of a hack. I feel is that ideally device capture should have nothing to do with networking. So I would definitely support any move toward an actual local network permission prompt here. The second part about suppressing the API, I think we have to be a little careful. I'm hesitant to give a number but I would guess like 90% of WebRTC calls today are not local network calls. At the same time I think
Jan-Ivar: we need to support the use case where this does not trigger a local network access prompt because that's the dominant webRTC use case. It's important to not worsen the experience when webRTC is peer-to-peer. So if it's possible to form a connection locally, we should still support that. It would be also a negative if that became a second-class citizen.
Youenn: If we can reduce the number of prompts that could happen with mDNS candidates for instance, to the case where there's a connection that is feasible and we are trying to do it, then maybe the number of prompts will be reduced a lot. For Google meet for instance there will never be a successful case so hopefully prompt never happen and we will not need an API to suppress network access for webRTC. I would hope that otherwise there should be like a network API and not webRTC-specific.
Jan-Ivar: I don't think setLocalDescription, setRemoteDescription or addIceCandidate is the correct trigger to trigger a prompt. So if we can avoid those somehow because that they don't really signify user intent to access the local network in my view
Youenn: it's the same for fetch for instance. Fetch is usually called without a user gesture. it's done on in the background
Jan-Ivar: the options there are to prompt or try to do without local candidates. There will be cases where the browser doesn't have local network access and in that case it could just do a worse job. But if the user agent has permission but the website does not, it could try to do better than that, right?
Youenn: How?
Jan-Ivar: Well, the browser could use mDNS in that case, but it could not necessarily require that for the website.
Youenn: there's definitely an issue which is MacOS-specific which is when do you trigger the OS-level prompt compared to the browser LNA prompt and there's something to be discussed there definitely. For camera usually there's the browser prompt first and then the OS prompt which is just one time. We could have a similar approach there where it's the browser that prompts first and then the OS. Still something to think of.
Philipp Hancke: if we want to disable WebRTC's mDNS support, we can probably use a no host ICE gathering policy that would allow applications to opt into that like Google Meet could set that and it would never gather local candidates.
Youenn: so what is the no host policy?
Philipp Hancke: it is something that is implemented in libwebrtc. It has been specified in ORTC but it never made it to WebRTC-PC
Youenn: Ah, that's interesting. Yeah,
Philipp Hancke: So it just needs to be web-exposed. The problem is the definition of local network address is difficult and we need to synchronize with the LNA specification.
Youenn: I haven't precisely looked at how the spec is defining local loop and local network, but the idea to keep piggy-back on their definition should be the a good one.
Philipp Hancke: It's I think a table with 10 rows at least.
Tim Panton:I think it's great that we're finally getting round to doing this properly in a way that doesn't trigger it off getUserMedia. There are specific use cases for oneway video which would really benefit from having a proper prompt here which I think would be good. The only piece that slightly worries me is that we're still talking about using a generic and quite scary wording. It would be nice if you knew that the prompt was triggered by webRTC, you could give some hint that it was a video call that was happening or was supposed to be happening to or you know what the purpose of this supposedly what looked like a network attack. It would be nice to outline what the purpose of it is purported to be and then the user could see if that tied in with what they were expecting. So if it says like "your browser is trying to set up a video call and they're trying to access their baby monitor", then that makes sense, if they're trying to access their toaster, it probably doesn't. And so I think it means that the language has to be less generic but that may be very difficult to achieve because getting language right is hard.
I'm happy to kind of work with people on this. So we've got very specific interests and use cases in this area.
Youenn: wrt the prompt wording, it's user agent territory. I would say that if you're using webRTC you don't know whether it will be video call or data channel. Ditto for web transport, are you using it for text or video it's difficult. Also usually networking happens as synchronously so what we would like to be in a situation where the web page can provide information "I'm trying to connect to a baby monitor, click on it" then there's a prompt saying, "Do you want to connect to local devices?" Yes, the web page told me that, I have a baby monitor, I'll probably grant access. But given that all these things are asynchronous, it remains to be seen. I guess that websites that really want to handle correctly the baby monitor thing will be able to have this experience. But the default user experience might not be great. It might be hard to show a prompt, frequently a web page can be in the background and you're trying to show a prompt and the user will never see it for instance. So that's why it's much more difficult I think than getUserMedia for instance. But still it's already deployed. So piggybacking on it seems good to me.
Peter Thatcher: I apologize if this is a redundant question but when you say mode 2 with default private IP, are you proposing that would happen if LNA happened?
Youenn: if you're permitted to access to LNA either through a prompt or because the user granted persistent permission, the idea would be that by default you would leak the default private IP address. mode 1 is can be more than local network.
Peter Thatcher: I think it'd be great if we could get the default private IP in this case where LNA happens to come up. I guess my follow-up question would then be, can the developer know when LNA is going to pop up?
Youenn: there's a permissions query which allows you to know whether the permission state is granted or denied or prompt.
Peter Thatcher: And the developer can prompt it whenever it wants?
Youenn: that's the issue. I don't think there's an explicit API to trigger a prompt but maybe JavaScript could try to trigger the prompt by fetching some resources, which is is a kind of a hack, but I guess it's generic to LNA. So maybe it's a question to LNA. Maybe they have already a solution to that and webRTC could just piggy back on that.
Peter Thatcher: that would be really nice for use cases that would benefit from the default private IP. So something like web torrent they could show something to the user like hey we're going to pop something up to you because we need this to work properly. So click this button and then you'll get a prompt.
Youenn: So you would be in favor of an explicit API to trigger the prompt basically.
Peter Thatcher: exactly.
Youenn: Okay. That's something we could try to mention to the LNA force in WICG.
Jan-Ivar: Just the one caution there I think is that normally at least for Mozilla we tend to prefer permission at point of use, which would I think argue against, but also in this case this seems something JavaScript could already accomplish using some clever WebRTC calls perhaps.
Youenn: I tend to agree with your point. Normally you want to prompt at connection time.
Peter Thatcher: as long as it's reliably known when it will happen and it's not too hacky. I don't want something that works on one browser but doesn't work on another and or changes between versions of browsers and then suddenly breaks.
Youenn: it seems that we should try to contact the LNA folks basically. Harald or Guido, since there's already a webRTC implementation for LNA maybe it's worth uh describing how it's working somewhere in GitHub
Guido I can have an action item to try to find out how that integration is working.
ACTION: Guido to describe how LNA integration works
WebRTC-pc issues
issue #3110
issue #3111
no objection to the proposal, resolved as proposed
[slide 29[
issue #3112
slide [30]
RESOLUTION: adopt proposal A
issue #3114
needs implementations checking
issue #3115
browsers implement A.
RESOLUTION: proposal A
issue #3119
how do we fill about this implementation of getLocalCandidates?
issues #3117 and #3118
PRs to come
issue #3120
WebRTC extensions grab bag
Erik presenting
feedback welcome w3c/
cryptex
HDR
Q is should we standardize the color space RTP header extension