"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>
Besides the local federation now the server "REMOTE" can be used in
integration tests. The step "using server XXX" can be used to switch
between the LOCAL and REMOTE server, which will change the base URL that
requests are sent to.
The real federated server uses the same code as the main server but a
different configuration and data directory. For simplicity, the
configuration directory is expected to be inside the data directory of
the main server, specifically in
"tests-talk-real-federated-server/config".
If the federated server was not installed in the expected directory
before the tests are run a basic installation using SQLite will be
performed, using "tests-talk-real-federated-server/data" as its data
directory.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This better reflects that it is not a real remote server but the local
server accessed in a remote way with a different address, and it will
make possible to add a real remote server without clashing.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"baseUrl" and "baseRemoteUrl" are now used only to identify request URLs
(including those from dashboard widgets) while "localServerUrl" and
"remoteServerUrl" are used to identify the local and remote server in
the context of federation. This will be needed to be able to send
requests to different servers while keeping consistent replacement names
for participants.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Joas Schilling
Maksim Sukharev
Grigorii K. Shartsev
Nextcloud bot
Joas Schilling