Commit graph

5978 commits

Author SHA1 Message Date
Daniel Calviño Sánchez
29117e8b1b Get user ID from signaling message when creating ParticipantDisplayItem
The user ID set when creating the ParticipantDisplayItem was got from
the join event when the external signaling server was used, and from an
API call when the internal signaling server was used. However, the user
ID is already known from the signaling message that updates the
participant list, and is the one set on the ParticipantDisplayItems
when a participant joins the call. Therefore the other sources are not
needed, so now it is unified to always use the value from the signaling
message.

Note that in the rare cases in which a ParticipantDisplayItem is created
before the participant is seen as in the call the user ID will be
temporary unknown, although it will be automatically fixed once the
participant list update is received. Moreover, even if the other sources
were used it was not guaranteed that the user ID was known, so this
should not be a problem.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 15:48:45 +01:00
Daniel Calviño Sánchez
6e222e7cd2 Create ParticipantDisplayItem when creating the connections
The ParticipantDisplayItem for "video" was created when a participant
joined the room, but the item for "screen" was created when the stream
for the screen was connected. Due to this the item for the remote screen
share just "popped up" once connected, but there was no hint of a
connection being established, like done with the video streams.

Now the ParticipantDisplayItems are created as soon as a
PeerConnectionWrapper is created and then updated as needed (for example
to set the user ID or the stream), which causes the item to immediately
appear and a progress bar to be shown until the connection is
established.

Although the ParticipantDisplayItem may be created on a different thread
(the main thread) than the PeerConnectionWrapper "runOnUiThread"
executes the enqueued messages in order (and it also establishes a
"happens-before" relation with further calls of "runOnUiThread" due to
the internal use of synchronized blocks, although it is not explicitly
documented), so the item will be already created when later updated.

This also holds true when an offer is received even before the
participant is seen as joined (a very rare case that can happen if the
signaling message with the updated participant list is lost for any
reason); the ParticipantDisplayItem is created when the offer is
received and it is later updated with the user ID once a new signaling
message with the updated participant list is received.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 15:48:43 +01:00
Daniel Calviño Sánchez
29d0574667 Create ParticipantDisplayItem on media event if it does not exist yet
Instead of creating a new ParticipantDisplayItem from scratch, which
resets the full grid, now the existing one is updated; a new one is
created only if no item existed already for the session and video stream
type of the media event.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 15:41:46 +01:00
Daniel Calviño Sánchez
dc53023572 Update displayed nick when received in offers or answers
The nick was displayed when updated through a data channel message, or
when a ParticipantDisplayItem was created and the nick was already
received. However, when the HPB is not used the nick is not sent after a
connection is established, as it was sent already in the offer or
answer. The nick from the offer or answer has not been received yet when
the ParticipantDisplayItem is initially created, so the nick only
appeared because a new ParticipantDisplayItem is created again when the
connection is finally established. Due to all that the displayed nick is
now updated as soon as it is received in an offer or answer, which
ensures that the nick is shown independently of when was the
ParticipantDisplayItem created.

Note that this only applies to non-HPB scenarios; when the HPB is used
the nick is got from the participant list update sent through signaling
messages, so it is already known when creating the display item (in some
very strange cases it might happen that an offer is received before the
participant list was updated, but this should not happen, and in any
case it will be handled at a later point).

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 15:41:46 +01:00
Tim Krüger
5786baaeb7
Merge pull request #2545 from nextcloud/add-listener-for-data-channel-messages
Add listener for data channel messages
2022-12-28 15:30:20 +01:00
Daniel Calviño Sánchez
3762526318 Rewrite if/else chain as if/return blocks
Just a matter of preference :-)

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:56 +01:00
Daniel Calviño Sánchez
dceb4a6d79 Add listener for data channel messages
For now only the same data channel messages that were already handled
are taken into account, but at a later point the missing messages
("speaking" and "stoppedSpeaking") could be added too.

Note that the thread used to handle the data channel messages has
changed; the EventBus subscriber mode was "MAIN", but as the messages
were posted from a DataChannel observer, which run in a worker thread
rather than in the main thread, the subscriber was executed in the main
thread rather than in the same thread as the poster. Due to this the
actions performed by the handler now must be explicitly run in the main
thread.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
a65e56a9ce Remove unneeded condition
If the call is a voice only call there will be no received video tracks
(they would have been stopped when each connection is established), so
changing the enabled state has no effect (as the adapter only tries to
show the received video if it is available).

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
ac4be52b84 Do not guard code that can not throw the caught exception
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
af514b142a Reorder code that handles nick changed events
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
81f353f7f0 Return empty display name rather than default nick from web socket
If the display name is not known whether "Guest" or something else needs
to be shown is not a responsibility of the web socket, so now an empty
string is returned instead.

In practice this should not make any difference, though, as the display
name of users is always known as soon as the user joined, and if the
nick of a guest is not known the UI will set it to "Guest".

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
0dcdd6161f Move nick handling out of PeerConnectionWrapper
PeerConnectionWrappers should not be concerned with the nick of
participants. Moreover, the nick is included in offers and answers due
to legacy reasons and only when the internal signaling server is used.
Due to that the nick was moved out of PeerConnectionWrapper; although
the handling is now different the end result should be the same (there
might be some differences in very specific sequences of events, but in
any case all this is just a temporary step and any leftover issue should
be addressed once call participants and peer connections are split).

As the PeerConnectionWrapper does not keep track of the nick now the
nick changed event is always emitted when a nick changed data channel
message is received, even if the nick did not actually change.
Nevertheless, before it was anyway always emitted if it was for a user
and only when it was for a guest it was emitted only on real changes. In
any case this is not expected to cause any issue (other than some
unneeded view updates, but that will be addressed at a later point by
updating the views only when the model actually changed).

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
2eac8c2cba Move default nick out of PeerConnectionWrapper
If the nick is not known whether "Guest" or something else needs to be
shown is a responsability of the UI, so now the PeerConnectionWrapper
just returns an empty string and the UI shows the default guest nick if
needed.

Moreover, the nick stored in the PeerConnectionWrapper was not always
correct, as if no nick was received it was returned as "Guest" even
if the connection belonged to a user. Now "Guest" is used only for
actual guests.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
68cf4ee028 Use generic data channel message instead of nick specific one
The generic data channel message works fine for receiving, but it could
not be used for sending, because the serialization of the payload failed
(the generated JsonMapper did not call 'writeFieldName("payload")',
apparently because the payload was defined as "Any", so there was no
field name set when serializing the payload contents).

It is very likely that the nick data channel message, which has an
explicit payload type and was used only for sending but not for
receiving, was added back in the day just to work around that
limitation. However, due to how the JsonMappers are generated if several
properties with the same name are defined only the first one will be
parsed, and only those with a value will be serialized. This makes
possible to define first a generic payload property and then a payload
property with an explicit type to have a single data channel message
class that can be used both for sending and receiving.

As the nick data channel message is now no longer needed it was removed.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Daniel Calviño Sánchez
faf25f8071 Replace concrete implementation with interface
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-28 11:47:55 +01:00
Andy Scherzinger
e4e9a51889
Merge pull request #2543 from nextcloud/add-interface-for-sending-signaling-messages
Add interface for sending signaling messages
2022-12-27 15:44:40 +01:00
github-actions
d217c0a8cb
Analysis: update lint results to reflect reduced error/warning count
Signed-off-by: github-actions <github-actions@github.com>
2022-12-27 14:28:58 +01:00
Daniel Calviño Sánchez
65ff4efcb9
Send signaling messages directly from PeerConnectionWrapper
Note that the thread used to send the message does not change; the
EventBus subscriber mode was "BACKGROUND", but as the messages were
posted from a WebSocket handler (when requesting offers to the HPB) and
peer connection observers (when sending offers/answers and candidates,
both with and without HPB), which run in worker threads rather than in
the main thread, the subscriber was executed in the same thread as
the poster.

For legacy reasons, when the internal signaling server is used the
offers and answers are expected to also provide the nick of the local
participant. When the external signaling server is used the field can be
included, but it is just ignored and not sent to the other clients. As
the local participant nick is a value unrelated to the peer connection
and is only needed with one type of signaling server the messages are
adjusted as needed before being sent rather than handling this inside
the PeerConnectionWrapper.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:57 +01:00
Daniel Calviño Sánchez
58e371c98c
Do not apply "toLowerCase()" on already lower case canonical form
The canonical form is already in lower case (see
https://webrtc.googlesource.com/src/+/79d8df02/sdk/android/api/org/webrtc/SessionDescription.java#29),
so there is no need to apply "toLowerCase()".

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:57 +01:00
Daniel Calviño Sánchez
473b8b238d
Extract interface to send signaling messages
Like done with SignalingMessageReceiver, an implementation specific to
each signaling server type (internal or external) is added.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:57 +01:00
Daniel Calviño Sánchez
6b032fc55a
Replace constant String of length 1 with character
Fixes UCPM_USE_CHARACTER_PARAMETERIZED_METHOD issue from SpotBugs.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:57 +01:00
Daniel Calviño Sánchez
4086499a32
Remove special method to request offers
As the "requestoffer" message is just a signaling message the generic
method can be used instead.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:57 +01:00
Daniel Calviño Sánchez
37db855170
Use generic message rather than specific one for requesting offers
"requestoffer" messages are compatible with the generic messages, so for
simplicity the generic message is used now instead of having specific
classes just for it.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:56 +01:00
Daniel Calviño Sánchez
95007882f4
Remove no longer used JSON model
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:56 +01:00
Daniel Calviño Sánchez
48a64fde7e
Fix message wrapper type in documentation
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:56 +01:00
Daniel Calviño Sánchez
b4d4cdf219
Remove unused wrapper in the internal signaling server
Messages sent to the internal signaling server need to be serialized
twice, first the signaling message and then the wrapper as a whole. Due
to this the NCMessageWrapper was not actually used.

For simplicity the manual serialization was kept rather than adding
something like "NCMessageWrapperToSend" where a serialized signaling
message could be set before serializing it.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:56 +01:00
Daniel Calviño Sánchez
e1eca7764f
Replace wrapper with actual message in external signaling server
NCMessageWrapper is used only for messages sent and received by the
internal signaling server. However, it is unused by the external
signaling server, except for getting the NCSignalingMessage, which is
the common message for both signaling servers.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-27 14:28:55 +01:00
Andy Scherzinger
3dac8fb9ce
Merge pull request #2653 from nextcloud/dependabot/github_actions/actions/stale-7.0.0
Bump actions/stale from 6.0.1 to 7.0.0
2022-12-27 10:07:57 +01:00
Andy Scherzinger
50549ae652
Merge pull request #2654 from nextcloud/dependabot/github_actions/ossf/scorecard-action-2.1.2
Bump ossf/scorecard-action from 2.1.1 to 2.1.2
2022-12-27 10:06:02 +01:00
Nextcloud bot
5fe33f47a1
Fix(l10n): 🔠 Update translations from Transifex
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-27 07:13:47 +00:00
Nextcloud bot
df0baba6e2
Fix(l10n): 🛠️ Update Transifex configuration
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-27 07:12:37 +00:00
dependabot[bot]
a221500ba3
Bump ossf/scorecard-action from 2.1.1 to 2.1.2
Bumps [ossf/scorecard-action](https://github.com/ossf/scorecard-action) from 2.1.1 to 2.1.2.
- [Release notes](https://github.com/ossf/scorecard-action/releases)
- [Changelog](https://github.com/ossf/scorecard-action/blob/main/RELEASE.md)
- [Commits](15c10fcf1c...e38b1902ae)

---
updated-dependencies:
- dependency-name: ossf/scorecard-action
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-12-26 23:03:16 +00:00
dependabot[bot]
2158bae4e7
Bump actions/stale from 6.0.1 to 7.0.0
Bumps [actions/stale](https://github.com/actions/stale) from 6.0.1 to 7.0.0.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](5ebf00ea0e...6f05e4244c)

---
updated-dependencies:
- dependency-name: actions/stale
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-12-26 23:03:13 +00:00
Nextcloud bot
4e86f450f2
Fix(l10n): 🔠 Update translations from Transifex
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-26 06:52:45 +00:00
Nextcloud bot
cd787ae8aa
Fix(l10n): 🛠️ Update Transifex configuration
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-26 06:51:52 +00:00
Nextcloud Android Bot
198a9e3145 Weekly 15.2.0 Alpha 03 2022-12-26 03:12:55 +00:00
Nextcloud bot
5e276fef80
Fix(l10n): 🔠 Update translations from Transifex
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-25 07:52:26 +00:00
Nextcloud bot
7bbac1e823
Fix(l10n): 🛠️ Update Transifex configuration
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-25 07:50:59 +00:00
Nextcloud bot
98d6132416
Fix(l10n): 🔠 Update translations from Transifex
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-24 09:56:54 +00:00
Nextcloud bot
588a64b778
Fix(l10n): 🛠️ Update Transifex configuration
Signed-off-by: Nextcloud bot <bot@nextcloud.com>
2022-12-24 09:55:01 +00:00
Marcel Hibbe
93137e1eeb
Merge pull request #2536 from nextcloud/add-listeners-for-signaling-messages
Add listeners for signaling messages
2022-12-23 21:48:24 +01:00
Daniel Calviño Sánchez
c4c64df5a6 Remove no longer needed code after removing EventBus message
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:44:41 +01:00
Daniel Calviño Sánchez
5e224c5a24 Use listener for participant list messages
Note that the thread used to handle the participant list messages from
the external signaling server does not change; the EventBus subscriber
mode was "BACKGROUND", but as the message was posted from a WebSocket
handler, which runs in a worker thread rather than in the main thread,
the subscriber was executed in the same thread as the poster.

Also note that the removed "userId" remark was not fully accurate;
although some external signaling messages do actually use "userid" those
currently handled to process the users do not, they always use "userId"
(as documented in the SignalingMessageReceiver).

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:44:41 +01:00
Daniel Calviño Sánchez
e0c676bb35 Add listener for participant list messages
For now only the same participant list messages that were already
handled are taken into account, but at a later point further messages,
like participants joining or leaving the conversation, could be added
too.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:44:41 +01:00
Daniel Calviño Sánchez
c8e77c3d3b Split message receiver for internal and external signaling servers
Note that the thread used to handle and notify messages from the
external signaling server does not change; the EventBus subscriber mode
was "BACKGROUND", but as the message was posted from a WebSocket
handler, which runs in a worker thread rather than in the main thread,
the subscriber was executed in the same thread as the poster.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:44:41 +01:00
Daniel Calviño Sánchez
9df56dccda Process signaling message directly in the SignalingMessageReceiver
This will no longer log an error if the room type of the received
message is neither "video" nor "screen". However, that should never
happen, and it would be useful only while debugging, so it is fine to
lose that.

Note that the check is not added to SignalingMessageReceiver itself to
keep it as generic as possible (and due to the low value of adding it as
explained above). Nevertheless, if needed in the future it would be
possible to add a special listener that receives raw messages in order
to validate them and log the errors, if any.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:44:20 +01:00
Daniel Calviño Sánchez
bda7d2719b Add listener for call participant messages
Although "unshareScreen" is technically bound to a specific peer
connection it is instead treated as a general message on the call
participant.

Nevertheless, call participant messages will make possible (at a later
point) to listen to events like "raise hand" or "mute" (which, again,
could be technically bound to a specific peer connection, but at least
for now are treated as a general message on the call participant).

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:41:34 +01:00
Daniel Calviño Sánchez
d42fe61e89 Add listener for offer messages
Unlike the WebRtcMessageListener, which is bound to a specific peer
connection, an OfferMessageListener listens to all offer messages, no
matter which peer connection they are bound to. This can be used, for
example, to create a new peer connection when a remote offer for which
there is no previous connection is received.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:40:01 +01:00
Daniel Calviño Sánchez
476fb59a08 Use temporary SignalingMessageReceiver implementation in CallActivity
Eventually all signaling related code should be moved to a Signaling
class that abstracts the differences between the internal and external
signaling servers, including how messages are sent and listened to. In
the meantime a temporary SignalingMessageReceiver implementation is
added to CallActivity to be able to start using it.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:40:01 +01:00
Daniel Calviño Sánchez
45787caf0a Add SignalingMessageReceiver class to listen to signaling messages
For now only WebRTC messages can be listened to, although it will be
extended with other kinds later.

This commit only introduces the base class, although it is not used yet
anywhere; a concrete implementation will be added in a following commit.

The test class is named "SignalingMessageReceiverWebRtcTest" rather than
just "SignalingMessageReceiverTest" to have smaller, more manageable
test classes for each listener kind rather than one large test class for
all of them.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
2022-12-23 20:40:01 +01:00