nextcloud
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.
Is it same issue as I have? Sometimes some users stop hear some other users (not all other users), but after reconnect they can hear each other again. For example:
- user1, user2, user3 in meet and all users hear each other;
- user1 and user2 stop hear each other, but both hear user3 and user3 hear their both too;
- user1 or user2 reconnect - all users hear each other again. Probably this happen if some of users have bad connections (wifi, 3 or 4g) or slow CPU (very busy CPU).
Our installation are on virtual machine in intranet with access via apache 2.4 mod_proxy as reverse proxy on gateway for frontend and coturn (STUN/TURN Server) on gateway too (with nat).
If it's other issue, then I'll create new issue. Thanks!
Is it same issue as I have?
Probably not, as in this issue the participants can not hear each other after a reconnection, while in your description the reconnection makes possible for the participants to hear each other again.
Nevertheless, when you say that users reconnect, do you mean that they manually leave the call and join it again? Or do you mean the automatic reconnection (the spinner over certain participant and the message about connection problems and that a reconnection will be tried)?
I had the same issue as @VVD (not hearing one specific person on a call) Then I noticed the message 'OC.requestToken changed <long ID>' and suddenly I could hear that person again.
on Linux, Debian, Firefox 110 with arkenfox
@danxuliu
when you say that users reconnect, do you mean that they manually leave the call and join it again?
Yes, manually.
Or do you mean the automatic reconnection (the spinner over certain participant and the message about connection problems and that a reconnection will be tried)?
Sometimes it's look like user is reconnecting forever (small rolling circle) until reconnect manually.
My server is on FreeBSD, clients on different OSes - FreeBSD, Linux, Win, Android (mobile) with different browsers - chrome (and clones), firefox (and clones).