15:01:20 <RRSAgent> RRSAgent has joined #webrtc
15:01:24 <RRSAgent> logging to https://www.w3.org/2025/07/15-webrtc-irc
15:01:24 <Zakim> Zakim has joined #webrtc
15:01:24 <dom> RRSAgent, make log public
15:01:25 <dom> Meeting: WebRTC July 2025 meeting
15:01:25 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/Jul_15_2025
15:01:25 <dom> Slideset: https://docs.google.com/presentation/d/1uEVvg1JB-6cUO9dZh7fb5CG1NDHkDP6U1wO61d0oujA/
15:01:25 <dom> Chairs: Guido, Jan-Ivar
15:01:25 <dom> Present: Guido, Dom, Jan-Ivar
15:01:25 <dom> Regrets: Youenn
15:01:30 <dom> Present+ Harald
15:01:40 <dom> Present+ PeterT
15:01:49 <dom> Regrets+ Elad, Cullen
15:02:10 <dom> Present+ JasperHugo
15:04:35 <dom> Present+ SunShin, PatrickRockhill
15:04:48 <dom> Recording is starting
15:07:01 <dom> Topic: -> https://github.com/w3c/webrtc-pc/issues/3060 Header Extension Control to WebRTC MainSpec
15:07:01 <dom> [slide 10]
15:07:37 <dom> [slide 11]
15:08:34 <caribou> present+
15:08:37 <dom> Present+ TimP
15:08:44 <dom> Present+ Carine
15:09:27 <dom> Jan-Ivar: I don't see any big problem with that; still some concern about dictionary vs interfaces, but these improvements can be made in the main spec
15:10:03 <dom> ... so no objection from me
15:10:13 <dom> RESOLVED: move forward with pull request for #3060
15:10:44 <dom> Jan-Ivar: will this help wrt codecs/negotiation?
15:10:55 <dom> Harald: some of the same things apply, but this won't help in the short term
15:11:05 <dom> Topic: -> https://github.com/w3c/webrtc-rtptransport RtpTransport
15:11:05 <dom> [slide 14]
15:12:00 <dom> [slide 15]
15:12:46 <dom> [slide 16]
15:13:21 <dom> Peter: SimpleRtpTransport is a working name for this proposal, can be bikeshed later
15:14:22 <dom> [slide 17]
15:14:51 <dom> [slide 18]
15:16:10 <dom> [slide 19]
15:16:55 <dom> [slide 20]
15:17:07 <dom> [slide 21]
15:18:30 <dom> PeterT: it's a peer-to-peer bandwidh-controlled congestion controlled packet API
15:18:34 <dom> [slide 22]
15:18:41 <dom> [slide 23]
15:20:21 <dom> Jan-Ivar: re slide 19, doesn't WebTransport solve this with its echo server? what's missing?
15:20:42 <dom> Peter: P2P, real-time, customized congestion control
15:21:24 <dom> Jan-Ivar: a lower level API than WebTransport is not something I would be excited about
15:21:49 <dom> Peter: it doesn't have to be lower level, but allow for custom bandwidth estimate, P2P and real-time
15:22:18 <dom> Jan-Ivar: how about negotating WebTransport over SDP?
15:22:33 <dom> ... WebTransport has some congestion control, and I/O is solved with Streams
15:22:41 <dom> ... having yet another API for P2P feels suboptimal
15:22:56 <dom> ... and instead catalyze on what we've already solved
15:23:26 <dom> ... re which WG - there have been efforts on QUIC over WebRTC which may be worth discussing how to revive them
15:23:51 <dom> TimP: stepping back a bit: there are real use cases that can't be done with WebRTC or WebTransport
15:24:14 <dom> ... e.g. data out of a LIDAR on a near network that you don't want to go through a server, not possible in real time
15:24:23 <dom> ... Peter's requirements are right in that regard
15:24:53 <dom> ... there is no appetite on implementing the closely related WebRTC API that would satisfy this
15:25:20 <dom> ... layering WebTransport and WebRTC together with a bit of QUIC, I don't see who would implement this
15:25:32 <dom> ... maybe that's the fundamental question that needs answering
15:25:58 <dom> Present+ PhilipEliasson
15:27:03 <dom> Peter: I understand interest from Google to implement something like SimpleRtpTransport
15:27:07 <dom> Philip: that's correct
15:27:33 <dom> Jan-Ivar: I don't think we would be implementing something like that: it feels too low level, and it's not clear how you would solve the hard problems
15:27:43 <dom> ... Quic gives some congestion control and flow control
15:28:19 <dom> Peter: my main question is not on specific API shape and network protocols, but rather move away from piecemeal, and if so where
15:28:58 <dom> Jan-Ivar: we would have to dive into which technical problems need solving - e.g. WebTransport not being P2P
15:29:21 <dom> ... send/receive packets methods in JS doesn't feel realistic - WebTransport solved some of that with streams
15:29:38 <dom> ... it would be easier with more implementation experience on WebTransport, but it still feels like the most promising option
15:29:59 <dom> ... we would be more likely to implement WebTransport over SDP - QUIC seems quite compatible with ICE
15:30:36 <dom> ... Web developers who don't need P2P can already make do with WebTransport and get reasonable real-time preference; they shouldn't have to use a different API to get P2P
15:31:06 <dom> TimP: +1 to pursuing an API in that space; not an expert on the right place for the work
15:31:18 <dom> ... although if it starts from ICE, this WG feels reasonable
15:31:35 <dom> ... otherwise, if it doesn't tie to existing objects, not obvious it would need to be here
15:32:07 <dom> Philip: the proposed work could fit in other groups, but the motivating factor behind this API feels like a good fit for this group
15:32:27 <dom> ... it's RTC focused, with its low latency congestion control
15:33:03 <dom> Jan-Ivar: QUIC over ICE would need IETF involvement, on which we could add an API
15:33:12 <dom> ... WebTransport is getting close to wide review on level 1.0
15:33:36 <dom> ... I could discuss with my co-chair over feasability of P2P connection
15:33:50 <dom> Peter: QUIC over ICE isn't complicated - I've written a draft to describe it
15:34:10 <dom> ... P2P QUIC could be done without ICE (but ICE-like)
15:34:37 <dom> ... (distinguishing the ICE packet format vs the ICE approach - the latter can be done with QUIC packets)
15:34:54 <dom> ... QuicTransport was just that
15:35:05 <dom> ... it would still need solving real-time
15:35:27 <dom> Jan-Ivar: why would we solve real-time congestion only for P2P?
15:35:34 <dom> Peter: this would also solve it for client-server
15:36:08 <dom> ... I haven't seen an implementation of QUIC with real-time congestion control on par with what we get with PeerConnection today
15:36:42 <dom> Philip: true real-time communication is different from just data flows
15:37:02 <dom> ... doing real-time congestion control is quite different, it could complicate things quite a bit
15:37:23 <dom> Jan-Ivar: part of the question is how much browsers should be involved in congestion control vs apps
15:37:44 <dom> ... we would prefer reusing existing approaches as much as possible
15:37:59 <dom> Peter: so if we're making WebTransport real-time and P2P, which group should it happen in?
15:38:06 <dom> Jan-Ivar: either would be fine from my perspective
15:38:12 <dom> ... it would be good to have an IETF spec to lean on
15:39:25 <dom> ... a simpler API could also be done by polyfilling on top of SDP
15:39:44 <dom> ... e.g. what is missing from datachannels?
15:40:12 <dom> Peter: there are some downsides to re-using the datachannel API
15:40:28 <dom> Jan-Ivar: I was thinking instead of getting WebTransport streams out of the negotiation
15:40:52 <dom> Peter: that's roughly what QuicTransport was
15:41:03 <dom> ... you don't need SDP for this, but you could build it on top of SDP
15:41:16 <dom> Jan-Ivar: getting rid of SDP would be a large task by itself
15:41:25 <dom> Peter: only if you try to build on top of peerconnection
15:41:39 <dom> ... building an ICE Transport doesn't need to lean on SDP
15:42:21 <dom> Jan-Ivar: creating a third API isn't great for developers
15:42:32 <dom> Peter: hence the proposal of providing a sample app
15:43:10 <dom> Philip: the advantage of a low-level API is that it makes implementation much simpler, and is also simple to explain
15:43:40 <dom> Jan-Ivar: I'm skeptical it's actual simple - it took a very long time to get where we are today, and it took getting a lot of details right
15:44:24 <dom> TimP: we shouldn't regard developers moving away from PeerConnection API as a bad thing
15:44:35 <dom> ... it's not a simple API to learn, and it's not going to get simpler
15:45:07 <dom> ... it would be easy to find people interested to use such a new API - we got a lot of interest
15:45:36 <dom> ... we definitely would use it - datachannels over SCTP just doens't work for our use case
15:45:47 <dom> ... I suspect QUIC might have related problems, but I haven't tried that yet
15:46:00 <dom> ... it does feel like if we build it, they will come
15:46:58 <dom> Philip: re simple, I agree it's definitely not trivial to introduce a new transport
15:47:15 <dom> ... but this API is about removing 98% of PeerConnection
15:47:37 <dom> ... the main thing that needs solving is the app-level bandwidth estimation to prevent abuse
15:48:12 <dom> Jan-Ivar: I would be supportive to look QUIC over ICE and solve individual issues
15:48:36 <dom> ... would be interesting to learn more about implementation challenges
15:48:58 <dom> Harald: congestion-control and encrypted transport needs key negotiation and feedback format on congestion
15:49:23 <dom> ... they're not trivial problems; I'm hesitant to give an answer without a clearer sense of how they would be solved
15:49:36 <dom> ... IETF has banned "simple" in protocols based on their experience
15:49:59 <dom> Peter: re feedback, if we went with QUIC, we would need the receivetimestamp extension
15:50:11 <dom> ... if we want with RTP, we would go with RFC @@@
15:50:27 <dom> ... re keys negotiation, QUIC partially solves it
15:51:06 <dom> Philip: I think there are solutions; feedback format are technically possible
15:51:16 <dom> Peter: but there aren't solutions already out there
15:52:12 <dom> Jan-Ivar: solving real-time congestion is inteesting for WebTransport in general, outside of P2P
15:52:26 <dom> ... this could be done a separate deliverable to WebTransport 1.0
15:52:38 <dom> Peter: solving QUIC to make it real-time would be great
15:52:42 <dom> ... likewise for P2P
15:52:47 <dom> ... and I agree they're orthogonal
15:54:59 <dom> RESOLVED: Jan-Ivar to discuss with WebTransport co-chair on interest; Peter to share details on QUIC over ICE
15:55:00 <dom> -> Peter's expired ICE+QUIC IETF draft: https://www.ietf.org/archive/id/draft-thatcher-p2p-quic-00.html
15:55:25 <dom> Topic: -> https://github.com/w3c/webrtc-pc/ DataChannel transfer issues
15:55:25 <dom> Subtopic: Issue #3063: Data channels in workers get initialized on wrong thread
15:55:25 <dom> [slide 27]
15:59:47 <dom> TimP: is that the only property that is mishandled or does that apply to labels as well?
16:00:17 <dom> Jan-Ivar: only id afaict
16:00:19 <dom> Present+ Varun
16:01:54 <dom> Guido: Chrome is implementing the spec; before we agree to change the spec, I would like to take a look at why Chrome is doing that way, and if changing it would cause any problem - let continue the discussion
16:02:29 <dom>  Jan-Ivar: part of the issue is that when SCTP connects, it queues a task on the main thread and does a lot of initialization on that thread, which could be an issue with worker threads
16:02:49 <dom> ... there is a separate task to announce the channel as open - we could move id initialization there, but that could be a breaking change
16:03:25 <dom> ... an alternative would to change how initialization is done specifically in workers channel, where id initialization would come alter
16:04:09 <dom> RESOLVED: continue discussion in issue based on implementation analysis
16:04:17 <dom> Subtopic: Issue #3062: Prevent GC of non-closed RTCDataChannels in workers
16:04:17 <dom> [slide 28]
16:06:44 <dom> RESOLVED: move forward with proposal
16:06:49 <dom> Subtopic: Issue #3058: Avoid losing data channel events during transfer
16:06:49 <dom> [slide 29]
16:08:40 <dom> Jan-Ivar: more of a heads up for implementors; the spec seems already correct
16:09:21 <dom> RESOLVED: the issue can be closed since no spec change is needed
16:10:08 <dom> Topic: -> https://github.com/w3c/webrtc-pc/ WebRTC API
16:10:08 <dom> Subtopic: Issue #3052: RTCPeerConnectionIceErrorEvent should not expose STUN reason phrase to JS
16:10:08 <dom> [slide 34]
16:11:32 <dom> Harald: I think we should keep errorText, but that it doesn't need to reflect the error message from the STUN attribute; it should help with debugging
16:12:41 <dom> RESOLVED: keep errorText but call out risk with STUN reason
16:12:55 <dom> Subtopic: Issue #3064: RTCError constructor fails the copy constructor pattern
16:12:55 <dom> [slide 35]
16:14:08 <dom> RESOLVED: move forward with proposal
16:14:19 <dom> Topic: -> https://github.com/w3c/webrtc-stats/issues/800 Can we delete webrtc-provisional-stats spec?
16:14:19 <dom> [slide 36]
16:15:20 <dom> Jan-Ivar: I'm supportive of Henrik's proposal
16:15:56 <dom> Harald: do we have a list of what's implemented and not in provisional stats?
16:16:08 <dom> Jan-Ivar: not that I know of; I know Firefox hasn't implemented any of those
16:18:27 <dom> Harald: part of the motivation was to allow webrtc-stats move to PR
16:18:53 <dom> Dom: right - we need to look again at what's implemented to move forward with webrtc-stats
16:19:12 <dom> ... we could re-import things that have only one implementation as feature at risk for later integration through amendments
16:19:28 <dom> ... my recollection was that stats was also used as a collection of "good ideas" - not sure if that's useful
16:19:39 <dom> Varun: +1 on the value of documenting them
16:20:07 <dom> ... to avoid reinventing the wheel all the time
16:21:30 <dom> Dom: this could be done as markdown files under a subfolder in webrtc-stats
16:22:36 <dom> Jan-Ivar: we recently added a stat for PSNR; it took a long time, but making it through the traditional standardization process rather than hiding them in provisionign is valuable
16:22:59 <dom> Varun: provisional stats has lots of stats that have been implemented in the stack, but not exposed via getStats() atm
16:25:44 <dom> Harald: I would object to the goal on deleting that document without a clearer process to documenting, evaluating stats over time
16:26:06 <dom> ... given that barrier to adding stats to the main document
16:26:43 <dom> ... I expect triage will end up with a random set moved to main, with information loss in the process
16:27:10 <dom> Varun: moving to markdown with the same information doesn't feel like progress
16:27:43 <dom> ... the doc is already marked as unofficial, and makes it easier to move stats from one doc to another
16:29:00 <dom> ... it all  comes down to process; we should clarify our expectations for proposing new stats
16:30:27 <dom> Guido: we should bring this back when Henrik is around
16:31:20 <dom> Harald: FYI: the document hasn't been updated in 2 years, or looking at issues
16:31:29 <dom> RESOLVED: bring this back when Henrik is available
16:31:33 <dom> RRSAgent, draft minutes
16:31:35 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/15-webrtc-minutes.html dom
18:29:34 <Zakim> Zakim has left #webrtc