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>
The avatar of guests is based on their display name/nick.
When the HPB is not used the nick is provided in the offer/answer
signaling messages, and later updated through data channel messages when
it changes. When the HPB is used the nick is periodically sent through
data channel messages. Therefore the avatar is based on the nick set in
the peer connection and reloaded when the nick changes (although it is
currently a bit hacky and brittle, as it is based on whether the nick
shown in the text view changed rather than whether the nick itself
changed, but it works nevertheless).
Note that currently it is required that the guest has a peer connection
to know its nick and, therefore, its avatar; some changes would be
needed in the clients to also send the nick when there is no peer
connection.
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>
