When pulling signaling messages failed the source observable was
immediately subscribed again, which immediately triggered another pull.
Rather than hammering the server or a flaky network with new requests
again and again now further requests are performed with an incremental
delay (up to 16 seconds).
The delay is increased only when several requests fail in a row, and it
is reset as soon as a request succeeds.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the internal signaling server is used the observable to pull
signaling messages is subscribed again after each completion, but in
case of an error it was retried only 3 times. Those 3 times are not in a
row, though, but in total for the whole observable, no matter how many
times it was subscribed again.
Due to the limitation on retries in a long call with a flaky connection
pulling the signaling messages could fail more than 3 times, which
caused the observable to finish with an error and therefore stop further
pullings. In this situation the Android app would not notice if other
participants joined or left the call, and thus it would not establish a
connection with them or stop it. To prevent that now the number of
retries is unlimited (although the retry is still stopped if the local
participant is no longer in the call).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The URL for the avatar depends on whether the call participant is a user
or a guest and, if it is a guest, on its nick. Although the user id of a
participant does not change if the participant is a guest the nick may
be changed during a call, so the avatar URL needs to be updated as well.
As the avatar URL is fully derived from other properties it is now
calculated internally in the ParticipantDisplayItem and calculated when
any of the properties it depends on changes (also for the user id for
completeness, as technically the item could be reused for a different
participant with a different user id, even if it is not currently done).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The new sessions are computed by substracting the old sessions (those
for which a PeerConnectionWrapper exists) from the sessions currently in
the call. However, when "oldSessions" was used for that it no longer
contained the old sessions, it only contained the sessions which were no
longer in the call. As those sessions are mutually exclusive with the
sessions currently in the call nothing was substracted from
"newSessions", and it ended being the sessions currently in the call
instead.
When the HPB is not used the list of participants in the conversation is
periodically updated every 30 seconds if no other signaling message was
received in the meantime. As the layout for a participant overrides any
previous layout for that participant this periodically reset the layout
of all participants in the call, as they were all treated as new
sessions.
When the HPB is used the list of participants in the conversation is
updated only when something changed. However, similarly to the previous
case, when that happens the layout of all participants in the call is
also reset for the same reason.
To solve that now "oldSessions" is not modified, so it contains the
sessions for which a PeerConnectionWrapper exists, and substracting it
from "newSessions" now gives only the new sessions.
The other usages of "newSessions" besides creating the connection and
setting up the layout, that is, getting the peers in the call and
changing the call status to "In conversation", should be safe if
executed only when there are new sessions rather than when there are
participants in the call but they did not change.
Resolves: #2486
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The old sessions are used to know which connections need to be ended
because they are no longer in the call. However, if a participant is no
longer in the call but there was no connection yet then there is no
connection that needs to be ended; any existing connection will be added
when looping through the connection list, and if it needs to be stopped
it will be found when substracting the sessions that are currently in
the call.
The old sessions are also used to find the new sessions in the call. Due
to an issue in how that is computed "newSessions" currently store the
sessions in the call rather than only the new sessions (this will be
addressed in a following commit). Nevertheless, in both cases any
session not in the call for which there is no connection either will not
make any difference in the computed "newSessions" (as they are mutually
exclusive, so they will never be removed from "newSessions" when
substracting the old sessions).
Due to all that it is not needed to store sessions not in call as old
sessions / sessions to end.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a new participant is found and the layout for that participant is
set up the participant data might have not been fetched yet. If that
happens the user ID can not be got from the data and therefore a guest
avatar would be shown for that participant, even if that participant is
a normal user.
However, the signaling message that is used to find new participants
already includes the user ID, so it is now explicitly given and, if not,
then it is got from the participant data (which is needed when handling
the establishment of a connection, as in that case the event does not
contain the user ID).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When setting the participant layout, if the HPB is not used, the user ID
is got from the participant list data fetched when a new participant is
found. However, as the participant layout is setup as soon as a new
participant is found the data may have not been received yet, which
ended in a crash (NullPointerException). Now the access to the
participant object is guarded to prevent that.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
So that my future self and other valued developrs don't must also
research that the variable 'isPTTActive' is renamed to
'isPushToTalkActive'.
Signed-off-by: Tim Krüger <t@timkrueger.me>
With this implementation the can publish audio & video permission are
set during the creation of the 'CallActivity'. This permissions are
fixed for the complete call. If the permissions are changed by a
moderator the call must be left and joined again.
Resolves: #1783
Signed-off-by: Tim Krüger <t@timkrueger.me>
During the migration from Java to Kotlin this was not done and resulted
in
BundleKeys.INSTANCE.getKEY_CALL_VOICE_ONLY()
instead of
BundleKeys.KEY_CALL_VOICE_ONLY
Signed-off-by: Tim Krüger <t@timkrueger.me>
"endPeerConnection()" removes the item from the list, so neither a
for-each loop nor an iterator can be used to traverse the list (as a
"ConcurrentModificationException" would be thrown). To solve that now
the list of connections is first traversed to get all the sessions, and
then the list of sessions is traversed to end the connections.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The call activity unregisters from the event bus events when stopped.
However, when the call activity is being closed the new activity can
start before the call activity is stopped; if the new activity causes
new signaling messages to be sent those messages were handled by the
call activity too.
The chat controller joins the conversation again when it is attached,
and the call activity automatically joins the call when it receives a
"roomJoined" event. Due to all that, when the call activity was closed
and the chat controller was opened the call was joined again (and then
left once the call activity was finally destroyed).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the local participant leaves the call the participant list will be
updated with the new call flags. However, that does not necessarily mean
that a moderator ended the call; the call could have been left too by
the Android app due to a forced reconnection or a time out when starting
the call. In those cases the call activity should be kept open, and only
when the local participant left the call due to a remote action the call
activity should be closed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the view is shutting down the call is always left, so the status
should be accordingly set.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the HPB is used and the publisher fails (which is a disconnection
that can not be automatically solved by itself) a forced reconnection is
triggered. This restarts the call, so some feedback should be provided
in the UI about it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As the participants that are not connected yet are clearly marked as
such now the participants are shown as soon as they are found rather
than waiting for a connection to be established.
There is a drawback, however; if a participant will never have a
connection (for example, if the HPB is used and that participant does
not have publishing permissions) the participant will be endlessly shown
with the progress bar. Nevertheless, before they were not shown at all,
which was probably even more puzzling.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that this still notifies a data set change if the properties are
set to the same value that they had already, but at least it is not
notified when no data was actually changed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The local stream is set only when the activity is created. However, it
was disposed when hanging up, which happens not only when closing the
activity, but also in cases in which the call activity is kept open and
the participant reconnects to the call (for example, when starting the
call times out), which caused the local stream to freeze. Now the local
stream is disposed only when the call activity is destroyed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a publisher fails during a call a reconnection is triggered, which
first leaves the call and then initiates it again. Initiating a video
call first request the permissions, but it seems that the request hangs
when done while in PiP mode. Due to this if the publisher fails while in
PiP mode and the call is initiated again the call will be simply left,
without reconnecting to it.
The problem is specific to video calls, as in voice only calls
"onMicrophoneClick" is used instead, and it explicitly checks if the
permissions are already granted. Checking if the permissions are already
granted before requesting them is also recommended in the Android
developer guide, and as the permissions are requested during the
original call initialization it is expected that they will be already
granted if the call is changed to PiP mode, so the problem is work
arounded that way (but if the permissions are not granted when the
publisher fails in PiP mode the problem would still happen, although
that should be quite uncommon).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When coming back from PiP mode the self video occupied the full height
of the window. Now the height is set to the default value set in the
layout, so it matches the size used when starting the call activity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
