- From: docfaraday via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Feb 2024 19:17:50 +0000
- To: public-webrtc-logs@w3.org
When it comes to what a bfcached peerconnection being revived looks like, I think the key thing to be thinking about is whether there is any other endpoint that is likely to have state lying around that corresponds to that peerconnection. Is there anything else that remembers the offer/answer state, for example? Does anything remember its own DTLS certificate? Does anything remember what the stream ids mean? Does anything remember the RTP mid -> ssrc mappings it discovered? I think the answer to most of these is "probably not". Now, _maybe_ we could keep the bfcached peerconnection _just alive enough_ to do ICE consent checks (perhaps for a limited time?). If those are still working, there's a pretty good chance we can pick up where we left off. If not, that likely means that the other end is gone and forgotten. I don't know if I like the idea of continuing to send any packets when we navigate away, though. As for whether we disable bfcache outright, as long as we do something sensible with the cached peerconnections, bfcacheing is probably fine. Personally, I would be _very_ irritated if hitting back or reopening a tab turned my camera/microphone on and dumped me back into a meeting. I think many other users would feel the same way. -- GitHub Notification of comment by docfaraday Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/200#issuecomment-1961861356 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 February 2024 19:17:51 UTC