The SDP constraints for publisher connections when the MCU is used were
set for all connections. Those constraints set "OfferToReceiveAudio" and
"OfferToReceiveVideo" to false, which disables receiving audio and video
when the local participant is the one sending the offer. Therefore,
audio and video was not received when the MCU was not used and the local
participant was the one initiating the connection.
The "OfferToReceiveXXX" configurations have no effect when set on an
answer (and thus are not even set, an empty MediaConstraints is used in
that case). However, when "OfferToReceiveVideo = false" is set the video
transceiver is explicitly stopped (which is used to avoid receiving
video when joining a call with audio only). Therefore, as
"OfferToReceiveVideo = false" was always set, video was never received
in subscriber connections when the MCU is used, or connections initiated
by the other peer when the MCU is not used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The SDP constraints should be set when the MCU is used, but only for
publisher connections; receiver connections should use the general SDP
constraints.
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>
"IN_CONVERSATION" was set when the activity was created and "state" in
the intent extras had the value "resume". However, there is no "state"
extra set by default in Android intents, it should be explicitly set,
but as it is not set anywhere in Talk Android code that would make it
dead code and safe to remove.
Moreover, the connection to the call should be initialized again in any
case rather than resumed when "onCreate" is called, as it is likely that
any previous connection would have been ended if the previous activity
instance was destroyed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This test respects different API versions and checks if default values are set as expected.
- remove deprecated+unused methods
- remove comments
- remove unnecessary double-bang operator
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
With server version 23.0.12 it happened that the chat did not load because values were null. Now default values in json model are set (because that's easier than changing the entity).
Additionally a check was added in CallActivity that a callStartTime of 0 would not be used (but it should not be used anyway if it would be 0 because then capability should also not be available).
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Starting with Talk 20 the signaling messages that provide updates to the
participants ("participants->update" in the external signaling server,
"usersInRoom" in the internal signaling server) now include "actorType"
and "actorId" properties for each participant.
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>
Starting with Talk 20 the signaling settings include a "federation"
property that provide the values needed to join a federated room in the
external signaling settings. The "federation" property is specific to
each conversation, and it will be returned although empty for
non-federated conversations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
With this change, all links that target files in the same nextcloud instance will be opened in the files app, no matter on which screen the link was.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
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>
When declining recording consent, 404 might be returned when leaving the call (because the call was not joined before).
It might not be the best option to handle this via onError, but for the moment (18.0.0 release) it's the most robust/lowest-risk solution without to change some state handling to check if the call was joined).
finish was added which makes sense anyway, but for declining recording consent the error snackbar was removed.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
