As federated users can now join calls the setting to show the media
settings or not before joining a call is also shown for federated
conversations.
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>
In federated conversations the recording consent is got directly from
the host room (through the propagated property), no matter the global
configuration for recording consent in the federated instance.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"In call" status is set from two different properties, "active since"
and "call flag". Call flags can be modified independently, but "active
since" is always linked to setting call flags, so the event needs to
include both properties.
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>
The cloud id will be used as the user id by the external signaling
server, which will make possible to notify federated users from the
remote Nextcloud server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before there was no session for federated participants, so it was not
possible to know if a federated participant was active or not in the
conversation. Now that federated participants join and leave the room
with a session it is possible to show them as active or not in the room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The signaling settings are got before joining a room, but they were
simply ignored unless the conversation cluster mode was used (as in that
case the signaling object was destroyed and the settings were applied to
the new signaling object when chaning between different signaling
servers). However, with federation the settings must be refreshed when
changing between federated rooms, or between federated and non federated
rooms, so for simplicity the settings are now always set after fetching
them.
Note that, in any case, getting the settings before joining any room
might be unnecessary and it may need to be refined, but for now it is a
convenient way to refresh the setting when changing between federated
and non federated rooms.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
With them the signaling server establishes a connection with the remote
signaling server and proxies its messages, also converting the room and
session ids from the remote server to the federated server as needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Unfortunately this prevents to join a room as a local federated user, as
in that case the session will be already in use.
On the other hand, this avoids the need to convert sessions between
host and federated servers, and with that also avoids having to keep a
map between sessions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Federated request handling in "join/leaveRoom" is a leftover from the
past, when federation requests were still not proxied by the federated
server (and federation itself was not fully implemented). Currently
federated requests are sent only to "joinFederatedRoom", so the related
code in "join/leaveRoom" can be removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This will make possible to join a room in a remote Nextcloud server with
the same session used in the local one avoiding the need to keep a map
of sessions to convert between them and ensuring that a duplicated
session id will not be used.
The column length for the session id is 512, while generated session ids
are only 255 characters long, so in most cases the cloud id can be added
as is. Only if the cloud id is longer than 256 characters (one character
needs to be reserved for the separator character) it will need to be
trimmed, but that is unlikely to happen; user ids are at most 64
characters, so the "@" plus the domain would need to be longer than 192
characters. Therefore any cloud id longer than 256 characters is just
trimmed at the end as a safety measure, but a fancier algorithm, for
example to ellipsize it, is not needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The length of the "sender" and "recipient" columns in the
"talk_internalsignaling" table was 255 (defined in
Version11000Date20201209142525.php), but the maximum session id length
is 512 (defined in Version10000Date20201015134000.php).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
dependabot[bot]
Nextcloud bot
Daniel Calviño Sánchez
Maksim Sukharev
Marcel Müller
Joas Schilling
Grigorii K. Shartsev
Joas Schilling