video-provider: fix setReconnectionTimeout race condition that caused webcams to drop
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:
parent
6418d0f556
commit
db15d1b280
@ -568,6 +568,7 @@ class VideoProvider extends Component {
|
|||||||
}, `Camera offer generated. Role: ${role}`);
|
}, `Camera offer generated. Role: ${role}`);
|
||||||
|
|
||||||
this.sendMessage(message);
|
this.sendMessage(message);
|
||||||
|
this.setReconnectionTimeout(cameraId, isLocal, false);
|
||||||
|
|
||||||
return false;
|
return false;
|
||||||
});
|
});
|
||||||
@ -700,10 +701,6 @@ class VideoProvider extends Component {
|
|||||||
return (candidate) => {
|
return (candidate) => {
|
||||||
const peer = this.webRtcPeers[cameraId];
|
const peer = this.webRtcPeers[cameraId];
|
||||||
const role = VideoService.getRole(isLocal);
|
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) {
|
if (peer && !peer.didSDPAnswered) {
|
||||||
this.outboundIceQueues[cameraId].push(candidate);
|
this.outboundIceQueues[cameraId].push(candidate);
|
||||||
|
Loading…
Reference in New Issue
Block a user