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>
