If the external signaling server is used, when a participant is
disinvited it is expected that the client leaves the conversation if
still in it. Therefore, self-joined users should not be disinvited when
they disconnect from a conversation, as they can still have other
sessions in it.
To ensure that self-joined users will be disinvited when their last
session leaves the conversation now a USER_REMOVE event is explicitly
triggered when that last session leaves and the user is, in fact,
removed from the conversation.
Note that this does not cause the system message about the participant
leaving to be sent, as it is explicitly guarded against self-joined
users leaving the conversation. However, this change will cause other
handlers to be called now, like those to invalidate resources, but it is
very likely that they should have been called and that this change is
actually a fix too in that regard.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the breakout room status changes a "switchto" message is sent to
all the active sessions in either the parent or the breakout rooms
(depending on whether they are being started or stopped) with the token
of the room that they have to switch to.
When the breakout rooms are started the message is sent only to non
moderators, as moderators do not have a single breakout room assigned.
On the other hand, when the breakout rooms are stopped the message is
also sent to all moderators (who are in a breakout room and not already
in the parent room), as all participants need to switch to the parent
room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the same room is joined again from the same PHP session the room is
left with the previous Nextcloud session before joining with the new
one. However, "disinvite" messages were not sent to the external signaling
server for regular users, so their UI was not updated to show that the
previous Nextcloud session was kicked out from the conversation.
Note, however, that as a "disinvite" message is now sent the UI will
show a "conversation not found" message rather than a "duplicated
session" state.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is needed to prevent issues with the request body size:
POST https:\/\/192.168.178.101:18443\/api\/v1\/room\/3097975620`
resulted in a `413 Request Entity Too Large` response:\nRequest entity
too large
Signed-off-by: Joas Schilling <coding@schilljs.com>
Before all sessions of a user where seen as changed, instead of
only the one session that actually was changed.
It is a regression from introducing multi-session support I assume.
Signed-off-by: Joas Schilling <coding@schilljs.com>
When the room or call permissions are set the permissions of all
participants could be modified. However, without HPB the participant
list was not updated in this case, so the participants may not be aware
of the change until up to 30 seconds, when the participant list was
automatically fetched again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the room or call permissions are set the permissions of all
participants could be modified. However, in this case the signaling
permissions were not updated, so the signaling server could allow or
reject media from participants that were already in the room when the
permissions changed. Now a message to update all the participants
currently in the room is sent to the signaling server when the room or
call permissions are set.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the local participant joins a call the sent media is based on the
last fetched permissions. However, once the call is joined the sent
media is based on the participant permissions updates notified by the
signaling messages.
When the HPB is used the "participantPermissions" property of the
"participants->update" signaling messages is used. Those messages are
sent when the permissions are modified and also when a participant joins
a call, but in this last case it did not include the expected property.
Due to this, if the permissions of the local participant were updated
right before the participant joined the call and the participant data
was not fetched again yet the previous permissions would be used. If the
message sent when the permissions were updated was received before
actually joining the call then it would be ignored, and although the
message sent due to joining the call would be processed the WebUI would
not notice the permission change, as the message did not provide them.
To solve that now the "participants->update" message sent when joining a
call also includes the permissions. This way, even if the previous
permissions are initially used when joining the call as soon as the
signaling message sent due to joining the call is received the WebUI
will adjust the sent media to the new permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This will allow the clients to react to "publishingPermissions" changes
directly from the signaling messages, without needing to fetch again the
participants (although they may need to fetch them again nevertheless
for UI updates).
The internal signaling server also needs to listen to changes on the
property to be able to know when to send the message (the external
signaling server already listened to the changes to be able to update
the permission flags internally).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joas Schilling
Vitor Mattos
Daniel Calviño Sánchez
Joachim Bauch