When the Nextcloud server notifies the signaling server about updates in
the participants it provides a list of properties about each participant
that will be relayed to the clients in the "participants->update"
signaling messages. When federated users were added to the participants
whose properties were relayed the "userId", which until then was set
only for regular users, was set too to the actor id for federated
participants. However, this approach was lacking, as it was not possible
for clients to really know from the "userId" property if the participant
was federated or not or, in a more general way, its actor type.
Due to that the "userId" is again set only for regular users for
backwards compatibility, and the "actorType" and "actorId" properties
are added to the data of each participant included in the
"participants->update" signaling message.
For consistency, "actorType" and "actorId" is also set in the equivalent
message of the internal signaling server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The federated users are now included in the "inCall" and "participants"
notfications sent from the Nextcloud server to the signaling server, so
their data is also included in the "participants->update" events sent
from the signaling server to the clients. Otherwise the clients would
not be notified when the properties of a federated user change, not even
for their own participant.
Note that the "participants->update" is also received by federated
clients when the default permissions of the room change, even if the
default permissions themselves are not propagated to the federated room,
as the change in the default permissions also cause a change in the
participant permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a participant is invited or disinvited to a conversation, or a
session is removed, the affected user receives a "roomlist" message with
type "invite" or "disinvite", while the rest of users in the
conversation receive a "roomlist" message with type "update" and a
"participant-list: refresh" property. Now both federated users and local
users receive the "roomlist" update.
Local users are also notified with a "roomlist" update when the
properties of the room change. However, in that case the signaling
server of federated users will be notified by the federated Nextcloud
server when the property changes are propagated to it, so there is no
need to notify federated users from the remote Nextcloud server in that
case.
Note, however, that independently of the users explicitly notified with
the "userids" parameter (which can include inactive participants) that
receive the "roomlist" message, the signaling server automatically
notifies all active participants in a conversation when it is modified,
so active federated users will receive a "room" message with the updated
properties (which may never be reflected in the proxy conversation, as
some properties are not propagated to the federated conversations).
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>
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>
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>
When a participant does not have publishing permissions the HPB will
block signaling messages related to establishing a connection, like
sending the candidates. This would prevent participants using clients
not supporting yet the publishing permissions (and thus still trying to
publish even if they are not allowed to) from sending media in a call.
Unfortunately the lack of permissions only prevents the connection from
being established. If a participant is already sending media revoking
the publishing permissions will not cause the connection to be stopped
by the HPB.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the internal signaling server is used the Nextcloud session id and
the signaling session id are the same. However, if the external
signaling server is used they are different.
Signaling messages for participants in calls (like joining the call,
muting and so on) are identified only by their signaling session id, so
when the external signaling server is used it was not possible to
associate participants in calls with the participant information
provided by the Nextcloud server.
However, when a participant joins a call her client notifies the
Nextcloud server (either directly or, in the case of SIP clients,
through the signaling server). The Nextcloud server then notifies the
signaling server which, in turn, notifies all the clients. When
Nextcloud notifies the signaling server the participant is identified
with the Nextcloud session id, and the signaling server then replaces
that with the signaling session id before relaying the message to the
clients.
Due to this when a participant joins (or leaves) a call now the
Nextcloud session id is sent too in an extra property. This property is
not adjusted by the external signaling server, so the clients receive
both the signaling session id and the Nextcloud session id and thus are
able to map them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
