Data channel messages can be sent only when the data channel is open.
Otherwise the message is simply lost. Clients of the
PeerConnectionWrapper do not need to be aware of that detail or keep
track of whether the data channel was open already or not, so now data
channel messages sent before the data channel is open are queued and
sent once the data channel is opened.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Data channel messages are expected to be sent using the "status" data
channel that is locally created. However, if another data channel was
opened by the remote peer the reference to the "status" data channel was
overwritten with the new data channel, and messages were sent instead on
the remote data channel.
In current Talk versions that was not a problem, and the change makes no
difference either, because since the support for Janus 1.x was added
data channel messages are listened on all data channels, independently
of their label or whether they were created by the local or remote peer.
However, in older Talk versions this fixes a regression introduced with
the support for Janus 1.x. In those versions only messages coming from
the "status" or "JanusDataChannel" data channels were taken into
account. When Janus is not used the WebUI opens the legacy
"simplewebrtc" data channel, so that data channel may be the one used to
send data channel messages (if it is open after the "status" data
channel), but the messages received on that data channel were ignored by
the WebUI. Nevertheless, at this point this is more an academic problem
than a real world problem, as it is unlikely that there are many
Nextcloud servers with Talk < 16 and without HPB being used.
Independently of all that, when the peer connection is removed only the
"status" data channel is disposed, but none of the remote data channels
are. This is just a variation of an already existing bug (the last open
data channel was the one disposed due to being the last saved reference,
but the rest were not) and it will be fixed in another commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The legacy name was a bit strange, so now it is renamed to just "send"
as the parameter type ("DataChannelMessage") gives enough context.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This implicitly fixes trying to send the initial state on the latest
remote data channel found (which is the one stored in the "dataChannel"
attribute of the "PeerConnectionWrapper") when any other existing data
channel changes its status to open. Nevertheless, as all this will be
reworked, no unit test was added for it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
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>
