Can PeerConnection recover from failed state?

Skip to first unread message

Michal Śledź

Nov 27, 2023, 7:08:38 AM11/27/23
to discuss-webrtc

I am trying to understand PeerConnection state machine, in particular whether it's possible to recover from the PeerConnection failed state.

Reading W3C WebRTC standard, we can move to the failed state when ICETransport or DTLSTransport moves to the failed state.

Let's assume that our peer sent us their description with an invalid cert fingerprint.
Our DTLSTransport will move to the failed state so the whole PeerConnection.
Should we allow for recovering from this state?
If yes, is ICE restart required or simply generating and setting descriptions on both sides will be enough? 
I assume that ICE restart is needed as we won't get ICE candidates unless we buffered ones from the previous exchange.  

Another question is what we should do with transports when PeerConnection fails? Should we close them, in particular should we close ICETransport and its agent or is it left for the implementators? 

Harald Alvestrand

Nov 27, 2023, 7:50:59 AM11/27/23
The RTCPeerConnectionState enum is  summary of the states of the components, it's not really an individual state.

So if the IceConnectionState or the RTCDtlsTransport is capable of getting out of the "failed" state, the PC can get out of it too.
The RTCIceConnectionState enum tells you that this is a collective of the RTCIceTransport state.

I don't think RTCDtlsTransport is capable of recovering from "failed", so if it fails, you need a new one.
RTCDtlsTransport objects are created when a description is applied (search for "newly created RTCDtlsTransport"). It's not obvious that even doing a new ICERestart will get you a new DTLS transport.

So the safe procedure is to delete the RTCPeerConnection and start over.

This list falls under the WebRTC Code of Conduct -
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Michal Śledź

Nov 27, 2023, 7:54:00 AM11/27/23
Reply all
Reply to author
0 new messages