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.