The in 'MagicPeerConnectionWrapper#removePeerConnection' used method
'PeerConnection#removeStream' was not longer available in the unified
plan. So to make sure that the local stream is disposed, it will now be
done in 'CallActivity#hangup'.
Resolves: #1773
See: [1]
[1] https://webrtc.org/getting-started/unified-plan-transition-guide
Signed-off-by: Tim Krüger <t@timkrueger.me>
This reverts commit 6415f163bd.
Revert "use context compat to load resources"
This reverts commit 3742c4ed99.
Revert "Adding upload from camera action"
This reverts commit 01a6675795.
When Janus is used even if it is possible to open several data channels
with different labels and send data on them all the messages are
received in the first data channel opened.
In Talk the "status" data channel is used to send the data channel
messages, and before Janus 0.7.0 it was the first data channel opened,
so the messages were received on it.
However, since Janus 0.7.0 the data channel messages are received
instead on a data channel opened by Janus, which is named
"JanusDataChannel". It is not possible to change that behaviour on Janus
except by patching it, so for broader compatibility the messages
received in "JanusDataChannel" are treated like messages received in the
"status" data channel
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When another participant shared the screen a new offer was requested.
However, the offer was requested for the video instead of for the
screen, which caused the HPB to stop the previous video connection and
replace it with a new one. As receiving new offers for an existing
connection is not properly handled the offer was applied to the existing
peer connection, which caused the new offer to be ignored and the old
peer connection to be kept (but frozen due to the HPB not sending more
data for that connection).
Requesting offers are not needed when the peer connection is a screen,
as the HPB will automatically send the offers itself. Therefore, now
offers are requested only when the connection is of "video" type.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before the NICK_CHANGE event include either the session id or the user
id, depending on whether the participant was a guest or a user. However,
as the session id is also known for users the event can be unified to
always include the session id only.
This also fixes an exception when handling the "NICK_CHANGE" event, as
the session id was got from the user id given in the event, but if the
event already included the session id the look up failed and the session
id was replaced with an empty value. This in turn caused an exception
when trying to use the view for the now invalid session id. Now the
session id provided in the event is always directly used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "nick" attribute was set with itself instead of with the
"internalNick" variable that holds the value received in the
"nickChanged" event.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the standalone signaling server is used and a participant joins a
conversation a "join" signaling message is received. The code assumed
that the event always contains a "user" attribute, but that attribute is
empty for guests. As the "user" attribute was used unconditionally this
caused an exception, and as the exception happened when handling a
websocket message it propagated until it caused a reconnection of the
websocket.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
