Add support for federated calls #4120
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
danxuliu
added
enhancement
Starting with Talk 20 the signaling settings include a "federation" property that provide the values needed to join a federated room in the external signaling settings. The "federation" property is specific to each conversation, and it will be returned although empty for non-federated conversations. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
This is necessary to get the specific federation properties for the room. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The "federation" values are used by the external signaling server to establish a connection with the remote signaling server in a federated room. For now this is applied only in calls; when the room is joined in the chat view again after a call it will still join it in the old way, without federation properties, which will cause the connection with the remote signaling server to be closed. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Starting with Talk 20 the signaling messages that provide updates to the
participants ("participants->update" in the external signaling server,
"usersInRoom" in the internal signaling server) now include "actorType"
and "actorId" properties for each participant.
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
…signaling Signed-off-by: Daniel Calviño Sánchez <[email protected]>
…signaling Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
…signaling Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Otherwise the WebSocket configuration and session clashes with the one from the CallActivity, which already uses the federated settings. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
mahibi
force-pushed
the
add-support-for-federated-calls
branch
from
0985052
to
4cea7b2
Compare
|
/backport to stable-20.0 |
mahibi
approved these changes
Sep 13, 2024
Signed-off-by: Marcel Hibbe <[email protected]>
|
APK file: https://www.kaminsky.me/nc-dev/android-artifacts/4120-talk.apk |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds support for federated calls when using the external signaling server (note that support for the external signaling server in a federated conversation was not added to the chat view, though, only to the call view for now).
To do that now the federation properties from the signaling settings are given to the external signaling server when joining a room (as described in nextcloud/spreed#12604), and the avatar of participants in call view now take into account the
actorTypeandactorIdfields in theparticipants->updatesignaling message to get a federated avatar if needed (as described in nextcloud/spreed#12863).Both changes should be backwards compatible with older Talk versions; if an older Talk version is used the federation properties will not be included in the signaling settings and neither will be
actorTypeandactorIdin theparticipants->updatesignaling messages, so everything should work just as before.TODO
Follow-ups
darkThemeingetUrlForFederatedAvatarwas a boolean rather than an integer. The server API expects a boolean (or even a different endpoint for a light and dark mode avatar, and using a boolean would avoid an unnecessary conversion from a boolean to an int (which is not exclusive to theParticipantDisplayItem, it can be seen in other calls togetUrlForFederatedAvatar).🏁 Checklist
/backport to stable-xx.x