BigBlueButton/bigbluebutton-Github
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

video-provider: fix setReconnectionTimeout race condition that caused webcams to drop

Browse Source 
Problem: setReconnectionTimeout was being called in the first candidate generation to set the negotiation/reconnection timeout up. That caused some browsers or specific scenarios (mainly envs without STUN) to establish the negotiation (playStart) before generating any useful out-of-band candidates (relay). That would cause the timeout to be set AFTER it is supposed to be cleared due to success (playStart), making the webcam drop after a while

So I moved the setReconnectionTimeout call to a safer spot: right after the first negotiation requisition goes out to bbb-webrtc-sfu
This commit is contained in:
prlanzarin 2021-01-28 12:27:14 -03:00 committed by prlanzarin
parent 6418d0f556
commit db15d1b280
1 changed files with 1 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
bigbluebutton-html5/imports/ui/components/video-provider/component.jsx
View File

@ -568,6 +568,7 @@ class VideoProvider extends Component {
}, `Camera offer generated. Role: ${role}`);
this.sendMessage(message);
this.setReconnectionTimeout(cameraId, isLocal, false);
return false;
});
@ -700,10 +701,6 @@ class VideoProvider extends Component {
return (candidate) => {
const peer = this.webRtcPeers[cameraId];
const role = VideoService.getRole(isLocal);
// Setup a timeout only when the first candidate is generated and if the peer wasn't
// marked as started already (which is done on handlePlayStart after
// it was verified that media could circle through the server)
this.setReconnectionTimeout(cameraId, isLocal, false);
if (peer && !peer.didSDPAnswered) {
this.outboundIceQueues[cameraId].push(candidate);