"peerConnectionWrapper" needs to be defined to enter the if and execute
the switch, so just return before the switch if "peerConnectionWrapper"
is null.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The message type is set for all signaling messages. On the other hand,
the payload type is only set for offers and answers (and, if the message
was sent by the Android app, also for candidates). However, in all those
cases the payload type just duplicates the message type, so the message
type can be assigned directly rather than falling back to it if there is
no payload type.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the HPB is used the signaling messages can be received even when
the local participant is not currently in the call (for example, when
starting the call timed out without other participant joining, or when
reconnecting due to the publisher connection failing). Therefore if the
local participant is not in the call it should not try to establish a
connection with the other participants and disconnect them instead.
Moreover, if the connection is tried to be established when not
in the call the HPB will prevent that, and the PeerConnectionWrapper
will stay in a limbo state waiting for an offer to be sent. If the local
participant then joins the call the PeerConnectionWrapper will already
exist for the other participants, so no new connections will be created,
but those previous connections will never be finally established.
Additionally, as the signaling messages can be received before the join
call response the participant list could be received while the call
state is "RECONNECTING" or "PUBLISHER_FAILED". In those cases, as long
as the local participant is already in the call, the participant list
should be processed as if the call state was already "JOINED" (otherwise
the connections were not established either).
For simplicity the participant list is now ignored only when the call
state is "LEAVING"; this means that the participant list would be also
processed in the "CONNECTION_TIMEOUT" state, but the signaling message
should not be received anyway in that case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the call is hung up with a view shutdown (which finishes the
activity) there is no need to do any further processing on the
participant list.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a call is joined the call flags of the local participant change, so
this causes a signaling message to be sent by the server. When the HPB
is used the signaling message is sent through a WebSocket, which is
already connected before joining the call. Therefore, in some cases the
signaling message can be received through the WebSocket even before the
response to the HTTP "joinCall" request.
If there are other participants in the call the call state is changed to
"IN_CONVERSATION" when the signaling message is processed. However, in
the case described above the call state was then set to "JOINED", which
automatically traverses to "CONNECTION_TIMEOUT" if no other call state
was set in 45 seconds. Due to all this the call was joined and the
connections with the other participants were established, but they were
not visible in the UI (although they could be heard) and after 45
seconds the call was left.
To prevent that now the call state is changed to "JOINED" if it was not
already changed to "IN_CONVERSATION" in the meantime.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
did not test why this can happen. autocompleteUser.id must have been null..
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ContactsController.processAutocompleteUserList (ContactsController.kt:498)
at com.nextcloud.talk.controllers.ContactsController.processAutocompleteUserList (ContactsController.kt:482)
at com.nextcloud.talk.controllers.ContactsController.access$processAutocompleteUserList (ContactsController.kt:90)
at com.nextcloud.talk.controllers.ContactsController$fetchData$1.onNext (ContactsController.kt:438)
at com.nextcloud.talk.controllers.ContactsController$fetchData$1.onNext (ContactsController.kt:432)
at io.reactivex.internal.operators.observable.ObservableRetryPredicate$RepeatObserver.onNext (ObservableRetryPredicate.java:69)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal (ObservableObserveOn.java:201)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run (ObservableObserveOn.java:255)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run (HandlerScheduler.java:124)
at android.os.Handler.handleCallback (Handler.java:883)
at android.os.Handler.dispatchMessage (Handler.java:100)
at android.os.Looper.loop (Looper.java:237)
at android.app.ActivityThread.main (ActivityThread.java:7948)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1075)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
The module class is not supposed to have things injected into it. @Provides-annotated methods
will have their parameters injected, instead.
Signed-off-by: Álvaro Brey <alvaro.brey@nextcloud.com>
