W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2023

Re: [webrtc-pc] RTCDataChannel.send during 'closing' state (#1827)

From: johzzy via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Feb 2023 11:36:10 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1422454703-1675856168-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:20:00 UTC