[webrtc-pc] RTCPeerConnection does not move to the closed state when RTCDTLSTransport receives close_notify DTLS alert (#3053)

mickel8 has just created a new issue for https://github.com/w3c/webrtc-pc:

== RTCPeerConnection does not move to the closed state when RTCDTLSTransport receives close_notify DTLS alert ==
When RTCDtlsTransport receives `close_notify` DTLS alert, it moves to the closed state but the RTCPeerConnection does not. It waits until RTCIceTransport moves to the failed state, and then it also moves to the failed state.

This is described here: https://www.w3.org/TR/webrtc/#update-the-connection-state 

> Let newState be the value of deriving a new state value as described by the [RTCPeerConnectionState](https://www.w3.org/TR/webrtc/#dom-rtcpeerconnectionstate) enum.

where RTCPeerConnectionState enum defines the `closed` state as:

> [[[IceConnectionState]]](https://www.w3.org/TR/webrtc/#dfn-iceconnectionstate) is "[closed](https://www.w3.org/TR/webrtc/#dom-rtciceconnectionstate-closed)".

This leads to inconsistent peer connection states - the remote side that called `close()` is in the `closed` state and does not allow for most of the function calls throwing InvalidStateError. The local side that received `close_notify` alert is in the `failed` state and allows for all function calls (addTransceiver, createOffer, setLocalDescription, restartIce, etc.) but it can't re-establish the connection. 

Isn't this misleading? Shouldn't both peer connections move to the `closed` state?

JSFiddle: https://jsfiddle.net/mickel8/puc1dabf/1/

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3053 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 June 2025 16:07:42 UTC