Media capture is not stopped when failing to leave a call

[danxuliu]

Although the specific steps below are a regression introduced in Talk 9 with the handling of conflicts between sessions the issue is unrelated to that. It could be tested too by forcing errors when leaving a call by adding return new DataResponse([], Http::STATUS_NOT_FOUND); to CallController::leaveCall

How to test

• Use the external signaling server
• Open the Files app
• Share two files
• Refresh (due to the bug in the Files app that causes the FileInfo to not be updated)
• Open the sidebar for the first shared file
• Open the Chat tab
• Join the conversation
• Start a call
• Open the sidebar for the second shared file (without leaving the call first)

Expected result

The browser stops audio and video capture.

Actual result

The browser is still capturing audio and video, even if the UI no longer shows the call.

[PVince81]

Not sure if related but something that happened to me once or twice was when leaving the company call the UI showed as if I had left but I could still hear people talking, so it "failed to leave" somehow. Next time it happens I'll open the debugger...

[danxuliu]

the UI showed as if I had left but I could still hear people talking, so it "failed to leave" somehow.

Note that you may have successfully left too. It could have been that your audio buffers had accumulated some latency so they were still playing by PulseAudio (not the browser), or that the UI was updated before the WebRTC connections were fully closed.

[PVince81]

Not sure if it was the buffers because the audio really lasted many more seconds until I hit page refresh. I'll keep an eye on this.

In any case, if it's the WebRTC connection still being there, we should sync up the UI to that somehow...

[PVince81]

I had a similar case just now in a 1-1 call with no file sharing involved.

I refreshed too quickly and missed the opportunity to look at the network console.

Nevertheless, we should catch that error and keep the call view visible so that users don't think that the call is done. Not sure what the server side state is and whether we need to retry or whether it will time out.

If we are confident that it will time out anyway we could also close the camera/audio as if it had succeeded.

[PVince81]

The browser is still capturing audio and video, even if the UI no longer shows the call.

@danxuliu should we maybe as a hardening measure call the "leaving call" code path whenever the CallView is getting destroyed ? This way we don't need to think about all cases where that view might be disappearing.

[danxuliu]

Mmm, that might have some undesirable side effect, as the call view sometimes gets destroyed and recreated while in a call. For example, in those cases in which there is a bit of lag of the status received from the server when starting a call and the chat view briefly appears again.

[nickvergessen]

Then setTimeout(() => {}, 90000) to stop it after 90sec of not using?

[PVince81]

I found other scenarios where the camera is not ungrabbed after being kicked out as participant:

• lock a conversation as moderator to kick out other participants
• delete a conversation as moderator during a call to kick out other participants

There might be more. These are consistently reproducible.

Let me know if related at all with this ticket or requires a different one. @danxuliu

[nickvergessen]

Just a question, is this still a thing, or can we close it?

[danxuliu]

The original issue as well as the scenario mentioned by Vincent about locking a conversation are no longer reproducible (they were probably fixed by #7799).

The scenario about deleting a conversation is still reproducible for guests when using the HPB; I have opened a specific issue for that here: #7962