- From: johzzy via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Feb 2023 11:36:10 +0000
- To: public-webrtc-logs@w3.org
> @aboba or @lgrahl Excuse me if I'm misinterpreting this, but how would this procedure work for a hard-quit peer, i.e. a browser peer that has been forced to quit and so does not send any reset or anything? I am still stuck in a `closing` state in this scenario and thought it might be relevant here. > > To elaborate: > > I have two connected peers, they share a RTCPeerConnection and a DataChannel. The other peer then force-quits their browser. I receive `oniceconnectionstatechange` with `peerConnection.iceConnectionState = 'failed'`. Because of this event, I want to clean up the RTCDataChannel, so I call `channel.close()` and so `dataChannel.readyState = 'closing'`. Here's where the issue starts: presumably because the RTCPeerConnection that supports the data channel is no longer connected, the reset signal and any queuing operations will fail and `onclose` is not fired. As I type this I wonder if it's more of a chromium bug or if the specification does not provide for this scenario. Thank you, When I handle the `restart-ice` and `renegotiate` of WebRTC, the audio and video work normally, that is, the `data-channel` has been unstable. It turned out to be closed `data-channel`. -- GitHub Notification of comment by johzzy Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1827#issuecomment-1422454703 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 February 2023 11:36:12 UTC