[2.4] Webcams: viewing may fail if an user joins a room with webcams already being shared

[prlanzarin]

Describe the bug

Joining a room with webcams already being shared may cause any of the subscriber streams to fail after the user closes the audio modal.

This is a bug exposed somewhere between 2.4-beta.3 and the current develop HEAD.

To Reproduce
Steps to reproduce the behavior:

1. Join with a session, call it s1
2. s1: share a camera
3. Join with another session, call it s2. Don't mess with the audio modal, wait a couple of seconds.
4. Close the audio modal. s1's camera might not load for s2.

I'm not entirely sure this is 100% reproducible, but happens more often than not.

Expected behavior

Everything should be viewable.

BBB version:

develop branch up to 36b2881 (2.4-beta.3, 2.4-RC1].

Environment

Reproduced in both Chrome and Firefox (latest, desktop).

Additional context

This equates to a potential problem that's apparently been here forever, but was exposed by a combination of two different changes

• Overall layout changes which somehow changed the timings of how the audio modal barrier for rendering webcams is layed out. There's always a video-provider mount on join because the initial audioModalIsOpen session var is undefined by default and the component mount check is being run before that var is set, initially.
• 631e8fc#diff-c212dd5f7f44b7da404291e25454dbf4d852d1c26ff72d3b36966d9cb5c711a0R112
• Now couple those two and you have: 1) video-provider mounting 2) triggering a peer instantiation (which is async) 3) video-provider un-mounting 4) the peer instantiation finishing and being stored in the webRtcPeers object hash, which is now not destroyed when the component is unmounted (because its root ref was moved to the service) 5) you have a leaked peer taking up space, and it's key is always the same for a single session 6) when the audio modal barrier is lifted, things for that leaked peer are in an inconsistent state and fail.

[prlanzarin]

Re-opening; this can still happen under the right circumstances. Yay.

[Jossef-767]

On my 2.4_B4 server this problem is consistent.
And I get this error every time! a viewer gets a video to view. (regardless of audio modal)

However, on the test24.bigbluebutton.org server, the error does not appear.
is it related to a TURN server that is different for the servers?
Was there a fix, or Configuration change that fixed this error on test24?
What can I do to help debugging this serious problem?

[prlanzarin]

Please attach complete console logs.

[Jossef-767]

I can confirm that when you stop using multiple kurento there are no problems.
But when using multiple kurento, "Camera VIEWER failed" will always appear.
in the second attempt, after "camera subscribe reconnection timeout",
It will connect and display the video.

Attaches console logs

Camera VIEWER failed.log

[prlanzarin]

I can confirm that when you stop using multiple kurento there are no problems.

It's unrelated to this issue, then.

The multiple Kurento thing is probably addressed in the next release with webrtc-sfu v2.6.0-beta.0.

Thanks for the logs anyways.

[Jossef-767]

so the reason for this error not Happening on test24.bigbluebutton.org is that multiple kurento is disabled on that server?

[prlanzarin]

@Jossef-767

so the reason for this error not Happening on test24.bigbluebutton.org is that multiple kurento is disabled on that server?

I have no idea if that server is using more than one Kurento.

RC-1 is out. Please confirm whether your specific problem has been addressed with it, thanks.

[prlanzarin]

there an "easy" way to "fix" that which is restoring the 2.3 behavior
2.4 mounts video-provider once before checking whether the "audio modal is open" flag is populated/truthy (may cause the problem due to a mount-unmount-mount race condition leaking peers)
2.3 only mounts video-provider after "audio modal is open" flag is populated/truthy, and that's the behavior we want to work around the issue in #13130

[prlanzarin]

:)