Meeting minutes
Recording: https://
Slideset: https://
Header Extension Control to WebRTC MainSpec 🎞︎
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
… so no objection from me
RESOLUTION: move forward with pull request for #3060
Jan-Ivar: will this help wrt codecs/negotiation?
Harald: some of the same things apply, but this won't help in the short term
RtpTransport 🎞︎
Peter: SimpleRtpTransport is a working name for this proposal, can be bikeshed later
PeterT: it's a peer-to-peer bandwidh-controlled congestion controlled packet API
Jan-Ivar: re slide 19, doesn't WebTransport solve this with its echo server? what's missing?
Peter: P2P, real-time, customized congestion control
Jan-Ivar: a lower level API than WebTransport is not something I would be excited about
Peter: it doesn't have to be lower level, but allow for custom bandwidth estimate, P2P and real-time
Jan-Ivar: how about negotating WebTransport over SDP?
… WebTransport has some congestion control, and I/O is solved with Streams
… having yet another API for P2P feels suboptimal
… and instead catalyze on what we've already solved
… re which WG - there have been efforts on QUIC over WebRTC which may be worth discussing how to revive them
TimP: stepping back a bit: there are real use cases that can't be done with WebRTC or WebTransport
… 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
… Peter's requirements are right in that regard
… there is no appetite on implementing the closely related WebRTC API that would satisfy this
… layering WebTransport and WebRTC together with a bit of QUIC, I don't see who would implement this
… maybe that's the fundamental question that needs answering
Peter: I understand interest from Google to implement something like SimpleRtpTransport
Philip: that's correct
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
… Quic gives some congestion control and flow control
Peter: my main question is not on specific API shape and network protocols, but rather move away from piecemeal, and if so where
Jan-Ivar: we would have to dive into which technical problems need solving - e.g. WebTransport not being P2P
… send/receive packets methods in JS doesn't feel realistic - WebTransport solved some of that with streams
… it would be easier with more implementation experience on WebTransport, but it still feels like the most promising option
… we would be more likely to implement WebTransport over SDP - QUIC seems quite compatible with ICE
… 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
TimP: +1 to pursuing an API in that space; not an expert on the right place for the work
… although if it starts from ICE, this WG feels reasonable
… otherwise, if it doesn't tie to existing objects, not obvious it would need to be here
Philip: the proposed work could fit in other groups, but the motivating factor behind this API feels like a good fit for this group
… it's RTC focused, with its low latency congestion control
Jan-Ivar: QUIC over ICE would need IETF involvement, on which we could add an API
… WebTransport is getting close to wide review on level 1.0
… I could discuss with my co-chair over feasability of P2P connection
Peter: QUIC over ICE isn't complicated - I've written a draft to describe it
… P2P QUIC could be done without ICE (but ICE-like)
… (distinguishing the ICE packet format vs the ICE approach - the latter can be done with QUIC packets)
… QuicTransport was just that
… it would still need solving real-time
Jan-Ivar: why would we solve real-time congestion only for P2P?
Peter: this would also solve it for client-server
… I haven't seen an implementation of QUIC with real-time congestion control on par with what we get with PeerConnection today
Philip: true real-time communication is different from just data flows
… doing real-time congestion control is quite different, it could complicate things quite a bit
Jan-Ivar: part of the question is how much browsers should be involved in congestion control vs apps
… we would prefer reusing existing approaches as much as possible
Peter: so if we're making WebTransport real-time and P2P, which group should it happen in?
Jan-Ivar: either would be fine from my perspective
… it would be good to have an IETF spec to lean on
… a simpler API could also be done by polyfilling on top of SDP
… e.g. what is missing from datachannels?
Peter: there are some downsides to re-using the datachannel API
Jan-Ivar: I was thinking instead of getting WebTransport streams out of the negotiation
Peter: that's roughly what QuicTransport was
… you don't need SDP for this, but you could build it on top of SDP
Jan-Ivar: getting rid of SDP would be a large task by itself
Peter: only if you try to build on top of peerconnection
… building an ICE Transport doesn't need to lean on SDP
Jan-Ivar: creating a third API isn't great for developers
Peter: hence the proposal of providing a sample app
Philip: the advantage of a low-level API is that it makes implementation much simpler, and is also simple to explain
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
TimP: we shouldn't regard developers moving away from PeerConnection API as a bad thing
… it's not a simple API to learn, and it's not going to get simpler
… it would be easy to find people interested to use such a new API - we got a lot of interest
… we definitely would use it - datachannels over SCTP just doens't work for our use case
… I suspect QUIC might have related problems, but I haven't tried that yet
… it does feel like if we build it, they will come
Philip: re simple, I agree it's definitely not trivial to introduce a new transport
… but this API is about removing 98% of PeerConnection
… the main thing that needs solving is the app-level bandwidth estimation to prevent abuse
Jan-Ivar: I would be supportive to look QUIC over ICE and solve individual issues
… would be interesting to learn more about implementation challenges
Harald: congestion-control and encrypted transport needs key negotiation and feedback format on congestion
… they're not trivial problems; I'm hesitant to give an answer without a clearer sense of how they would be solved
… IETF has banned "simple" in protocols based on their experience
Peter: re feedback, if we went with QUIC, we would need the receivetimestamp extension
… if we want with RTP, we would go with RFC @@@
… re keys negotiation, QUIC partially solves it
Philip: I think there are solutions; feedback format are technically possible
Peter: but there aren't solutions already out there
Jan-Ivar: solving real-time congestion is inteesting for WebTransport in general, outside of P2P
… this could be done a separate deliverable to WebTransport 1.0
Peter: solving QUIC to make it real-time would be great
… likewise for P2P
… and I agree they're orthogonal
RESOLUTION: Jan-Ivar to discuss with WebTransport co-chair on interest; Peter to share details on QUIC over ICE
DataChannel transfer issues 🎞︎
Issue #3063: Data channels in workers get initialized on wrong thread 🎞︎
TimP: is that the only property that is mishandled or does that apply to labels as well?
Jan-Ivar: only id afaict
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
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
… there is a separate task to announce the channel as open - we could move id initialization there, but that could be a breaking change
… an alternative would to change how initialization is done specifically in workers channel, where id initialization would come alter
RESOLUTION: continue discussion in issue based on implementation analysis
Issue #3062: Prevent GC of non-closed RTCDataChannels in workers 🎞︎
RESOLUTION: move forward with proposal
Issue #3058: Avoid losing data channel events during transfer 🎞︎
Jan-Ivar: more of a heads up for implementors; the spec seems already correct
RESOLUTION: the issue can be closed since no spec change is needed
WebRTC API 🎞︎
Issue #3052: RTCPeerConnectionIceErrorEvent should not expose STUN reason phrase to JS 🎞︎
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
RESOLUTION: keep errorText but call out risk with STUN reason
Issue #3064: RTCError constructor fails the copy constructor pattern 🎞︎
RESOLUTION: move forward with proposal
Can we delete webrtc-provisional-stats spec? 🎞︎
Jan-Ivar: I'm supportive of Henrik's proposal
Harald: do we have a list of what's implemented and not in provisional stats?
Jan-Ivar: not that I know of; I know Firefox hasn't implemented any of those
Harald: part of the motivation was to allow webrtc-stats move to PR
Dom: right - we need to look again at what's implemented to move forward with webrtc-stats
… we could re-import things that have only one implementation as feature at risk for later integration through amendments
… my recollection was that stats was also used as a collection of "good ideas" - not sure if that's useful
Varun: +1 on the value of documenting them
… to avoid reinventing the wheel all the time
Dom: this could be done as markdown files under a subfolder in webrtc-stats
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
Varun: provisional stats has lots of stats that have been implemented in the stack, but not exposed via getStats() atm
Harald: I would object to the goal on deleting that document without a clearer process to documenting, evaluating stats over time
… given that barrier to adding stats to the main document
… I expect triage will end up with a random set moved to main, with information loss in the process
Varun: moving to markdown with the same information doesn't feel like progress
… the doc is already marked as unofficial, and makes it easier to move stats from one doc to another
… it all comes down to process; we should clarify our expectations for proposing new stats
Guido: we should bring this back when Henrik is around
Harald: FYI: the document hasn't been updated in 2 years, or looking at issues
RESOLUTION: bring this back when Henrik is available