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>
Request the 'BLUETOOTH_CONNECT' permissions if not already granted.
If the permission is be granted in this request, the
'MagicBluetoothManger' will be started.
See: #2132
Signed-off-by: Tim Krüger <t@timkrueger.me>
i suspect that peerConnectionFactory could have been null because e.g. "hangup()" was already called which sets it to null. Because of some async task getOrCreatePeerConnectionWrapperForSessionIdAndType might still be called afterwards and it failed because peerConnectionFactory was already null.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
In case a moderator of a restricted room ends the call for all
participants a update participants event with the field 'all=true' will
be thrown by the HPB.
{
"type": "event"
"event": {
"target": "participants",
"type": "update",
"update": [
"roomid": "the-room-id",
"incall": new-incall-state,
"all": true
]
}
}
In that case the call can be ended directly without handling every
single participant.
Resolves: #1881
Signed-off-by: Tim Krüger <t@timkrueger.me>
The call flags describe the streams provided by the client, so in a
video call both audio and video are provided, not just video.
Note that as publishing permissions are currently not implemented in the
Android app the provided flags do not take into account the available
permissions. Nevertheless, the server restricts the flags based on the
permissions, so the other participants would see the appropriate flags.
In the future it would be better to send the right flags directly from
the Android app.
Similarly, for now, it is just assumed that both audio and video tracks
will be provided by the Android app, but the flags should reflect the
actually available tracks (for example, if it was not possible to get a
video track for some reason the call flags should not include
"WITH_VIDEO").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The Android app creates a connection with a participant when that
participant joins the call and ends it when the participant leaves the
call. However, it also created a connection when any signaling message
was received from a participant that had no connection yet. Due to this
if a signaling message was received from a participant before that
participant was in the call the Android app tried to establish a
connection too soon, which would be rejected by the HPB.
Similarly, if a signaling message was received from a participant after
that participant left the call a connection will try to be established.
That would fail, but the connection object was not removed, and if that
participant joined the call again no connection would be established, as
a connection for that participant was already found, even if it was not
usable.
To solve that now a connection is created when a signaling message is
received only if that message is an offer (which is necessary without
HPB if the other participant sends the offer before this participant
"noticed" that she is in the call); otherwise the message is ignored.
Besides that a connection will no longer be created either when setting
up the video stream. However, this would be just for correctness and it
should not make any difference, as the MediaStreamEvents that cause that
are only emitted by changes in peer connections, so they should be
already created.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
