Exception java.lang.NullPointerException:
at com.nextcloud.talk.activities.CallActivity.hangupNetworkCalls (CallActivity.java:1749)
at com.nextcloud.talk.activities.CallActivity.hangup (CallActivity.java:1741)
at com.nextcloud.talk.activities.CallActivity.lambda$initClickListeners$8$com-nextcloud-talk-activities-CallActivity (CallActivity.java:465)
at com.nextcloud.talk.activities.CallActivity$$ExternalSyntheticLambda16.onClick
at android.view.View.performClick (View.java:7792)
at android.view.View.performClickInternal (View.java:7769)
at android.view.View.access$3800 (View.java:910)
at android.view.View$PerformClick.run (View.java:30218)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
The peer connections will be of either "video" or "screen" type, so they
can be simply removed based on the session id and an explicit type.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of trying to create a video peer connection for any joined
participant now only a call participant is created for any joined
participant, and a video peer connection is created only for those
participants that are publishing audio or video.
If a call participants does not have a video peer connection the call
participant is now seen as "connected" from the UI, as there is no need
to show a progress bar for that participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As CallParticipantList starts listening on the signaling messages as
soon as it is created it needs to be created and destroyed right before
entering and exiting a call. Otherwise it could receive messages on
other states (for example, while the "connection timeout" message is
shown) and thus once the local participant joined the event would not
include the other participants already in the call as joined (although
they would be anyway reported as unchanged).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The observers were created for any peer connection, but after recent
changes they ignored all changes but those from the self peer
connection. Therefore it is enough to just add an explicit listener on
that peer connection rather than on all of them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The connection state changes to "closed" only when the connection is
closed. However, closing a connection does not fire any event (not even
the "iceConnectionStateChanged" event), so the event handler can be
removed as it will never be executed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The ParticipantDisplayItems were created and destroyed based on the peer
connections. Now a ParticipantDisplayItem of "video" type is associated
to a call participant, while an additional item is created and destroyed
depending on the state of the screen peer connection of the call
participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The listeners for call participant messages and for the call participant
nick provided by offers / answers were created and destroyed based on
the peer connections, although they were implicitly associated to a call
participant. Now they are explicitly created and destroyed based on its
associated call participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
CallParticipant provides a read-only CallParticipantModel and internally
handles the data channel and peer connection events that modify the
model. Nevertheless, the CallParticipant requires certain properties to
be externally set, like the userId or the peer connections.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of explicitly setting the values on the ParticipantDisplayItems
now the values are set on the CallParticipantModels, and the items are
automatically updated from their model when they change.
Different items are still used for the audio/video and screen shares of
the same participant, so the type is used to select from which
properties of the model is the item updated.
As the model may be updated from background threads it is explicitly
observed by the items from the main thread using a Handler shared by all
the items.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of explicitly calling "notifyDataSetChanged" after setting
values on a ParticipantDisplayItem now the adapter observes all its
items and calls "notifyDataSetChanged" automatically when any of them
changes.
Although this adds some boilerplate code it will make possible to update
the ParticipantDisplayItems and automatically propagate the changes to
the adapter when a model changes, rather than having to explicitly do it
from the CallActivity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than just providing a coarse "connected" or "not connected" value
now the views receive the raw ICE connection state. Combined with other
properties this will make possible to show a finer grained status (like
done in the WebUI), although for now just "connected" or "not connected"
is still shown as before.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that the event is posted only for proximity sensor changes the
condition is no longer needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Proximity sensor events should not have been part of
PeerConnectionEvent. However, now that all the peer connection related
properties were removed the remaining event can be renamed to something
more accurate.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The observer is just an adapter for the "PeerConnection.Observer"
provided by the WebRTC library; a custom observer is used to expose only
the events needed outside "PeerConnectionWrapper".
For now only the same events that were already handled are taken into
account, but at a later point additional events (like "onAddTrack"
instead of "onAddStream", which is deprecated) could be added too.
Note that the thread used to handle the events has changed; the EventBus
subscriber mode was "MAIN", but as the events were posted from a
PeerConnection 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>
Rather than simplifying the states to "CONNECTED" and "DISCONNECTED" now
the raw state is posted, and the handler then decides how to treat them
(which, for now, is exactly as before).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than emitting PUBLISHER_FAILED when the publisher connection
fails now PEER_FAILED is emitted when any connection fails, and the
handler checks if the connection was the publisher one to apply the
specific behaviour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
