The PeerConnectionWrapper does not need to be injected in the
application, nor the Context needs to be injected in the
PeerConnectionWrapper. This all seems to be leftovers from the past, and
removing them would ease adding unit tests for the
PeerConnectionWrapper.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
this is not working yet. It's for now commented out in order to continue with "request help" feature for breakout rooms.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
E/AndroidRuntime: FATAL EXCEPTION: RxCachedThreadScheduler-6
Process: com.nextcloud.talk2, PID: 25086
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean org.webrtc.DataChannel.send(org.webrtc.DataChannel$Buffer)' on a null object reference
at com.nextcloud.talk.webrtc.PeerConnectionWrapper.sendChannelData(PeerConnectionWrapper.java:275)
at com.nextcloud.talk.activities.CallActivity$17.onNext(CallActivity.java:2311)
at com.nextcloud.talk.activities.CallActivity$17.onNext(CallActivity.java:2303)
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.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
at java.util.concurrent.FutureTask.run(FutureTask.java:264)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
When the HPB is not used and a PeerConnectionWrapper is created it
always sent an offer if the local session ID is higher than the remote
session ID. However, in the case of screen shares the participant
sharing the screen always sends an offer, no matter the session ID.
Therefore, when that offer was received the new PeerConnectionWrapper
object sent a new offer, which in turn created an extra connection in
the browser.
Although the screen share connection happens to work the underlying
behaviour was wrong, so now no offer is sent for received screen share
connections and it is always waited until the offer is sent by the other
participant.
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 publisher peer connection when the HPB is used is a sender only
connection, so it never adds or removes a remote stream.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The MediaStreamEvent was posted when the connection with the remote peer
was established. However, the MediaStream is added earlier (as soon as
the remote description is received), so the event is moved to better
reflect that.
Note that checking if the connection is an MCU publisher is no longer
needed, as publisher connections are sender only and therefore no remote
stream is added for publisher connections.
In any case, note that the stream will not start until the connection is
established, and a progress bar will be anyway shown on the
ParticipantDisplayItem until it is connected.
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>
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>
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>
Although the rest of the methods are no longer needed since the handling
of WebRTC messages was moved to PeerConnectionWrapper "setSessionId()"
was not needed even before that.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
RTCPeerConnections have several states but, for simplicity, for now the
events posted reflect only if the connection is fully established or
not (which includes both a broken connection or an established
connection that is unstable or being updated), which is enough for a
basic information about the connection state in the UI.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
After the migration from WebRTC from plan b to unified plan in commit 86f20dc
the media constraints are ignored for creating an answer on a peer
connection:
> Offer to Receive Options/Constraints
>
> These constraints are passed to PeerConnection’s methods for creating SDP to
> add placeholder media sections in case a sending track would not have already
> created one.
>
> With Unified Plan semantics, these are still supported for creating offers
> using a backwards compatibility shim (basically creating an RtpTransceiver if
> one doesn’t exist). It is recommended to switch to the RtpTransceiver API
> (example below). _They are no longer supported when creating answers._
>
> [1]
Because of that now all transceivers of type VIDEO will be stopped if it
is only an audio call. After stopping the transceivers the status for the
video tracks will be automatically set to ENDED.
In the 'ParticipantsAdapter' it will be checked if the video tracks are
ENDED. In that case the user avatar will be shown like before.
Resolves: #1852
See: #1773, commit 86f20dc, [1]
[1] https://docs.google.com/document/d/1PPHWV6108znP1tk_rkCnyagH9FK205hHeE9k5mhUzOg/edit#heading=h.9dcmkavg608r
Signed-off-by: Tim Krüger <t@timkrueger.me>
