When the HPB is not used forcing a reconnection causes the call to be
left and then joined again. Although it was waited for the call to be
left first before joining again in some cases it could happen that,
after sending the join request but before receiving its response, the
"usersInRoom" event was received. In that case the call flags for the
participant will be "disconnected" (as at this point it is actually
disconnected), but as the join request was already sent it is seen as "a
moderator ended the call", and thus the call is left again. To prevent
that now it is explicitly waited for the "disconnected" flags to be
received and, then, the call is joined again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the HPB is not used forced reconnections just leave and then join
the call again. However, it was not waited for the call to be left first
before joining it again, so it could happen that the join request ended
being processed first and thus once the leave request was processed the
participant did not join again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When tracks are replaced the forced reconnections were based on whether
the call was started with local media active or not. However, in some
cases a forced reconnection was needed even if the call was started with
local media active. For example, if after joining a call the user
removed the audio and video devices and then added them again, as if
another participant joined the call in the meantime that participant
would not try to establish a connection after the devices were selected
again, as currently the clients only establish a connection if another
participant has media when the list of participants in the call change.
Besides that, when the flags are updated now the flags are based only in
the current tracks rather than on the previous flags, as if the flags
were updated again before the previous request finished the second
update would be based on the original flags.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the local participant joins a call in most cases the call flags
already reflect the current media being published. However, if the
active media changed since the request to join the call was sent (for
example, if a track started during a forced reconnection, which could
happen if audio was disallowed and video allowed at the same time) the
call flags would need to be updated.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If publishing media is disallowed now the media is also disabled to
ensure that, if the media is then allowed again, it will not be
unexpectedly enabled.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Until now the audio and video publishing permissions were handled as a
whole; either the local participant was able to publish both audio and
video or not. However, the permissions API is actually finer grained,
and it is possible to have one without the other. Now the allowed state
of local media is updated based on the publishing permissions, which
automatically starts and stops the tracks as needed. Nevertheless, in
some cases forced reconnections need to be explicitly triggered to
remove tracks from the senders, as well as to start and stop the local
media.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If media is allowed the track will be started (if a device is
available), and if media is disallowed the current track of its kind
will be stopped.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The constraints given to "MediaDevicesSource.start()" were used to limit
the media to be got. However, this only applied in the initial start; if
a new device from a media kind initially disallowed was selected later
the node got a track from it. Now "setAudioAllowed(bool)" and
"setVideoAllowed(bool)" are introduced to restrict the media to be got
whenever the node is active.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The constraints are used in the caller code for things like setting the
current call flags. The constraints were modified by the
MediaDevicesSource and the MediaDevicesManager depending on the
available devices, but they did not reflect things like a node further
in the pipeline failing to set the track (for example, if the
VirtualBackground failed hard) and causing the final track to be null.
Basing the constraints on the tracks instead should address those
(corner) cases while behaving the same in the general cases.
Besides that, this will make possible to remove the constraints from
"MediaDevicesSource.start()" in a following commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
.substr() is deprecated so we replace it with .slice() which works similarily but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
This reverts commit 99def03db2.
The previous fix was flawed, as the participant permissions were
reloaded only for the participant who changed the general permissions.
Moreover, now all the participants reload the participant list both with
and without HPB when the general permissions change, so the previous fix
is no longer needed even for the participant who made the change.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the call flags were updated after a renegotiation the senders were
checked to decide the flags to set. However, only the track attribute
was checked; when a track is disabled the track is nullified in the
sender and stored in "trackDisabled" instead, so the call flags were not
properly set if any of the tracks was disabled when a new one was added.
Note that when a local track is replaced the call flags are updated and,
in that case, the right flags are used, so sometimes this issue could be
masked by that.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The saved state was restored only when joining a call with media. This
was not a problem for audio or video, as in that case they were
automatically disabled due not having media available, but it caused the
virtual background state to be the default one or the one set in a
previous call.
Rather than also restoring the state after failing to start media the
state is now restored even before the media is tried to be initialized.
This ensures that the state will be the expected one once the media is
initialized, and with that prevent some unneeded changes back and forth
of the tracks caused by adjusting the audio, video and virtual
background once the tracks were already started.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The enabled state of media is saved per conversation using the
conversation token. However, the token was not initialized when joining
a call without media, so either an empty token or a token from a
previous call was used. To solve this now the token is set not only if
media was started, but also if it failed to start.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
marco
Nikola
Joas Schilling
Daniel Calviño Sánchez
Joas Schilling
Tobias Speicher