When the HPB is used and the connection to receive media from a participant fails a new connection is established again.
However, in some strange cases it seems that the connection can fail yet the browser does not change the ICE connection state of the peer to failed. When that happens the connection is just lost and never restored.
It might be possible to detect this scenario by periodically checking the received data from a peer, but unfortunately I do not know, as I have not been able to reproduce this (and it could even be a browser bug); I have seen it happen once (Chromium got stuck in new state after the answer from Janus got delayed) and I have deduced that this has happened for others too based on HPB logs (but without really knowing what happened in the client). Thus this needs more investigation 🤷
When a "phantom" connection failure happens a loading spinner might be shown on the remote participant in your browser, while the rest of the participants in the call do not have that loading spinner for that participant. Running OCA.Talk.SimpleWebRTC.webrtc.peers.forEach(peer => { console.log(peer.id, peer.pc.iceConnectionState) }) in the console will show that participant with a state different than connected or completed (and knowing which one would be interesting ;-) ).
When the HPB is used and the connection to receive media from a participant fails a new connection is established again.
However, in some strange cases it seems that the connection can fail yet the browser does not change the ICE connection state of the peer to
failed. When that happens the connection is just lost and never restored.It might be possible to detect this scenario by periodically checking the received data from a peer, but unfortunately I do not know, as I have not been able to reproduce this (and it could even be a browser bug); I have seen it happen once (Chromium got stuck in
newstate after the answer from Janus got delayed) and I have deduced that this has happened for others too based on HPB logs (but without really knowing what happened in the client). Thus this needs more investigation 🤷When a "phantom" connection failure happens a loading spinner might be shown on the remote participant in your browser, while the rest of the participants in the call do not have that loading spinner for that participant. Running
OCA.Talk.SimpleWebRTC.webrtc.peers.forEach(peer => { console.log(peer.id, peer.pc.iceConnectionState) })in the console will show that participant with a state different thanconnectedorcompleted(and knowing which one would be interesting ;-) ).