In order to filter control messages the external signaling server needs
to know the permissions of each participant. Those permissions need to
be set when the participant joins the room or if the participant type is
changed.
All participants should have permissions to publish media and screen,
but only logged in moderators should have permission to send control
messages.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The external signaling server expects to receive a "participants"
message from the backend notifier when the participants in a room
change. This message is in turn sent as a participants update signaling
message to the clients, and the WebUI updates the list of participants
whenever that message is received.
However, when the type of a participant changes the backend notifier
sent an "update" message instead, which is in turn sent as a room list
update signaling message to the clients, but it does not trigger any
update in the participants list of the WebUI.
Now a "participants" message is sent too by the backend notifier when
the participants in a room change, so the WebUI updates the list of
participants when handling the participants update signaling message;
the WebUI could have been modified to rely on the room list update
signaling message instead, but using the other message seemed more
appropriate.
Note that the already existing "update" message sent by the backend
notifier is kept for now, as removing it may break the clients in
unexpected ways (although it should go away in the future).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The signaling backend was not notified when the password, type or read
only state of the room was modified so, in turn, the signaling backend
did not notify the clients about those changes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This removes the long-polling against the PHP backend and instead sends an
event to all users in a room through the standalone signaling server to
notify that new chat messages exist.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Clients use the regular joinRoom/-Call API and get a Nextcloud session
id. No special handling for sessions from the standalone signaling
server are required.
The signaling server regularly "pings" active sessions to prevent them
from timing out (in case of guest users).
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Joas Schilling
Daniel Calviño Sánchez
Joachim Bauch
Morris Jobke