If the display name is not known whether "Guest" or something else needs
to be shown is not a responsibility of the web socket, so now an empty
string is returned instead.
In practice this should not make any difference, though, as the display
name of users is always known as soon as the user joined, and if the
nick of a guest is not known the UI will set it to "Guest".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Like done with SignalingMessageReceiver, an implementation specific to
each signaling server type (internal or external) is added.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As the "requestoffer" message is just a signaling message the generic
method can be used instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
NCMessageWrapper is used only for messages sent and received by the
internal signaling server. However, it is unused by the external
signaling server, except for getting the NCSignalingMessage, which is
the common message for both signaling servers.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the thread used to handle the participant list messages from
the external signaling server does not change; the EventBus subscriber
mode was "BACKGROUND", but as the message was posted from a WebSocket
handler, which runs in a worker thread rather than in the main thread,
the subscriber was executed in the same thread as the poster.
Also note that the removed "userId" remark was not fully accurate;
although some external signaling messages do actually use "userid" those
currently handled to process the users do not, they always use "userId"
(as documented in the SignalingMessageReceiver).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the thread used to handle and notify messages from the
external signaling server does not change; the EventBus subscriber mode
was "BACKGROUND", but as the message was posted from a WebSocket
handler, which runs in a worker thread rather than in the main thread,
the subscriber was executed in the same thread as the poster.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
During the migration from Java to Kotlin this was not done and resulted
in
BundleKeys.INSTANCE.getKEY_CALL_VOICE_ONLY()
instead of
BundleKeys.KEY_CALL_VOICE_ONLY
Signed-off-by: Tim Krüger <t@timkrueger.me>
In case a moderator of a restricted room ends the call for all
participants a update participants event with the field 'all=true' will
be thrown by the HPB.
{
"type": "event"
"event": {
"target": "participants",
"type": "update",
"update": [
"roomid": "the-room-id",
"incall": new-incall-state,
"all": true
]
}
}
In that case the call can be ended directly without handling every
single participant.
Resolves: #1881
Signed-off-by: Tim Krüger <t@timkrueger.me>
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>
