The "federation" values are used by the external signaling server to
establish a connection with the remote signaling server in a federated
room.
For now this is applied only in calls; when the room is joined in the
chat view again after a call it will still join it in the old way,
without federation properties, which will cause the connection with the
remote signaling server to be closed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
To support federated rooms, capabilities have to be checked from the room which now also has capabilities.
If room is not federated, capabilities fromuser are still checked.
This is why CapabilitiesUtil had to be refactored to accept SpreedCapabilities which can come from room or user.
Other than that, many other changes were made as a result of this change.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
android-talk-webrtc in version 121.6167.0 doesn't allow access to
WebRtcAudioManager
WebRtcAudioUtils
anymore.
These classes were used for
HARDWARE_AEC_EXCLUDE_SET
and
OPEN_SL_ES_INCLUDE_SET
lists, which were not updated for years.
For these reasons the checks for HARDWARE_AEC_EXCLUDE_SET and OPEN_SL_ES_INCLUDE_SET are removed.
If people are complaining about different behaviour of audio performance/echoes, it's worth to have a closer look at the changes again.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
# Send start/stop typing
Send "Typing" every 10 sec when there was a change
Send stop typing:
- when input is deleted
- when there was no input during the 10s timer
- when on leaving room
# Receive start/stop typing
Clear typing for participant after 15s if no start typing-message was received.
Use userId instead sessionId to manage typing participants. This ensures participants are not shown multiple times when using multiple devices with the same user (multisession). To get the userId via websocket, SignalingMessageReceiver and WebSocketInstance had to be modified to pass the CallWebSocketMessage in case the signalingMessage.type is related to typing. Not sure if this is the best solution but didn't find any other way.
Typing is not handled when the userId is of the own user (this could happen when using multiple devices)
In case userId is null (which happens for guests), their sessionId is used as key for the typingParticipants map.
# Other
Disable setting for typing indicator when no HPB is used + Avoid crash in chat when no HPB is used.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
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>
