Connections may not be established again when rejoining a call after leaving it failed

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Pending from #7799

This could be caused by triggering an ICE restart in an existing RTCPeerConnection and connecting to a completly different RTCPeerConnection object than before. It is possible that this is a bug in the browser itself (tested with Firefox 103), as similar issues were found some time ago when experimenting with ICE restarts, and the final state of the RTCPeerConnections is suspicious.

How to test

• Do not setup the HPB
• Force a failure when leaving the call by adding return new DataResponse([], Http::STATUS_NOT_FOUND); to the beginning of CallController::leaveCall
• Create a public conversation
• Start a call
• In a private window, open the conversation
• Join the call
• Open the browser console in both windows
• Once the connection is established, look for the participant who sent the answer with OCA.Talk.SimpleWebRTC.webrtc.peers[0].pc.localDescription.type
• Leave the call as that participant
• Join the call again
• In the other window the previous connection will end and an ICE restart will be triggered to establish the connection again; note that in some cases due to the timeouts both participants may overlap each other and end both with an answer, that is a different issue

Expected result

The connection is established again and both participants can hear and see each other

Actual result

The connection is established, but the participants can not hear nor see each other.

The candidate-pair of the RTCPeerConnection stats show that the participant that joined is sending media, but not receiving anything, and the participant that stayed is receiving media, but not sending anything. Even if that participant is receiving the received video shown is frozen (and in the window that is sending an empty video, not even a frozen one, is shown for the participant that joined again).

The state of the RTCDtlsTransports for the peer that stayed is stopped, while the state of the RTCDtlsTransports for the peer that joined again is connecting. The iceConnectionState for both peers, however, is connected.

Reproduce the failure using the steps in the issue, including the temporary response in lib/Controller/CallController.php at CallController::leaveCall. Inspect OCA.Talk.SimpleWebRTC.webrtc.peers[0].pc and the RTCPeerConnection, RTCDtlsTransport, and ICE states during the leave and rejoin sequence. Done means both participants can again hear and see each other after the failed leave.