Fix "silent" parameter not sent again when reconnecting

[danxuliu]

When a call was joined the value of the silent parameter was not tracked by the signaling object, so if the call was joined again (for example, in a forced reconnection, or if joining the call was deferred because the room was not joined yet by the signaling) silent was undefined, which was treated as false by the API.

The current set of scenarios that could trigger the issue is unlikely to happen in the real world, although it is possible nevertheless. Other slightly more common cases, like the participant starting without audio and video and then selecting the devices while already in the call would not trigger a reconnection, just an update of flags (at least if no one else joined yet, but if someone else joined then the reconnection will not cause the call to be started again, it would be just a participant leaving and then joining again).

I was surprised to find that the second scenario below is also fixed by this pull request. But it turns out that when another participant joins the call it always uses silent = true, no matter how the call was originally started (I assumed that, as the call was already started and no notification would be sent anyway, silent would be false, which would have caused a notification to be sent if the rest of participants left and a participant that joined once the call was already started then had a reconnection, as that would cause the call to be started again). But it is fixed, so 🥳

How to test (scenario 1)

• Enable the notifications app
• Create a conversation and add user A and user B
• Set default permissions of the conversation to allow starting a call, but do not allow publishing audio and video
• In a private window, log in as user A
• Open the conversation
• Start a silent call
• In another browser, log in as user B
• In the original browser window, grant all permissions to user A

Result with this pull request

The user B does not receive any notification about a started call, even if the call was started again due to the reconnection of user A

Result without this pull request

The user B receives a notification about a started call

How to test (scenario 2)

• Enable the notifications app
• Create a conversation and add user A and user B
• Set default permissions of the conversation to allow starting a call, but do not allow publishing audio and video
• Start a silent call
• In a private window, log in as user A
• Open the conversation
• Join the call
• In another browser, log in as user B
• In the original browser window, leave the call
• Grant all permissions to user A

Result with this pull request

The user B does not receive any notification about a started call, even if the call was started again due to the reconnection of user A

Result without this pull request

The user B receives a notification about a started call

[danxuliu]

/backport to stable27

[danxuliu]

/backport to stable26

[danxuliu]

/backport to stable25

[nickvergessen]

I was surprised to find that the second scenario below is also fixed by this pull request. But it turns out that when another participant joins the call it always uses silent = true, no matter how the call was originally started

This was done, so that people that click "Join call" while the call is being ended by a moderator do not recall everyone. Had this too often with the company call after "End for everyone" was added

[Antreesy]

Got this when updating audio/video permissions, while participant is in call:

• Screen 'Waiting for others to join the call …' was replaced with infinite "Connecting ..." spinner.

Might be a visual bug only, but trace look like this:

• EmptyCallView
• this.isConnecting === true
• participantsStore.state.connecting is not falsy
• commit('finishedConnecting') is not called
• EventBus.$once('signaling-users-in-room') is triggered only once (same for setTimeout)
  

  spreed/src/store/participantsStore.js

  Line 630 in a3009bb

  async joinCall({ commit, getters }, { token, participantIdentifier, flags, silent }) {

[nickvergessen]

Screen 'Waiting for others to join the call …' was replaced with infinite "Connecting ..." spinner.

Didn't happen for me 🤔

[danxuliu]

I can reproduce with the HPB. It is unrelated to this pull request, so I will merge it :-)

During a forced reconnection with the HPB connecting is set again due to calling setInCall to disconnect the previous session and then connect the new one. However, connecting is reset only once the first time that the signaling users are got after joining the call, or 10 seconds after joining the call, whichever comes first. As joinCall is not called again in the store during a forced reconnection connecting = true is kept until the user leaves the call.

[nickvergessen]

/backport to stable27

[nickvergessen]

/backport to stable26