If the call is a voice only call there will be no received video tracks
(they would have been stopped when each connection is established), so
changing the enabled state has no effect (as the adapter only tries to
show the received video if it is available).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
PeerConnectionWrappers should not be concerned with the nick of
participants. Moreover, the nick is included in offers and answers due
to legacy reasons and only when the internal signaling server is used.
Due to that the nick was moved out of PeerConnectionWrapper; although
the handling is now different the end result should be the same (there
might be some differences in very specific sequences of events, but in
any case all this is just a temporary step and any leftover issue should
be addressed once call participants and peer connections are split).
As the PeerConnectionWrapper does not keep track of the nick now the
nick changed event is always emitted when a nick changed data channel
message is received, even if the nick did not actually change.
Nevertheless, before it was anyway always emitted if it was for a user
and only when it was for a guest it was emitted only on real changes. In
any case this is not expected to cause any issue (other than some
unneeded view updates, but that will be addressed at a later point by
updating the views only when the model actually changed).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the nick is not known whether "Guest" or something else needs to be
shown is a responsability of the UI, so now the PeerConnectionWrapper
just returns an empty string and the UI shows the default guest nick if
needed.
Moreover, the nick stored in the PeerConnectionWrapper was not always
correct, as if no nick was received it was returned as "Guest" even
if the connection belonged to a user. Now "Guest" is used only for
actual guests.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The generic data channel message works fine for receiving, but it could
not be used for sending, because the serialization of the payload failed
(the generated JsonMapper did not call 'writeFieldName("payload")',
apparently because the payload was defined as "Any", so there was no
field name set when serializing the payload contents).
It is very likely that the nick data channel message, which has an
explicit payload type and was used only for sending but not for
receiving, was added back in the day just to work around that
limitation. However, due to how the JsonMappers are generated if several
properties with the same name are defined only the first one will be
parsed, and only those with a value will be serialized. This makes
possible to define first a generic payload property and then a payload
property with an explicit type to have a single data channel message
class that can be used both for sending and receiving.
As the nick data channel message is now no longer needed it was removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the thread used to send the message does not change; the
EventBus subscriber mode was "BACKGROUND", but as the messages were
posted from a WebSocket handler (when requesting offers to the HPB) and
peer connection observers (when sending offers/answers and candidates,
both with and without HPB), which run in worker threads rather than in
the main thread, the subscriber was executed in the same thread as
the poster.
For legacy reasons, when the internal signaling server is used the
offers and answers are expected to also provide the nick of the local
participant. When the external signaling server is used the field can be
included, but it is just ignored and not sent to the other clients. As
the local participant nick is a value unrelated to the peer connection
and is only needed with one type of signaling server the messages are
adjusted as needed before being sent rather than handling this inside
the PeerConnectionWrapper.
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>
"requestoffer" messages are compatible with the generic messages, so for
simplicity the generic message is used now instead of having specific
classes just for it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Messages sent to the internal signaling server need to be serialized
twice, first the signaling message and then the wrapper as a whole. Due
to this the NCMessageWrapper was not actually used.
For simplicity the manual serialization was kept rather than adding
something like "NCMessageWrapperToSend" where a serialized signaling
message could be set before serializing it.
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>
For now only the same participant list messages that were already
handled are taken into account, but at a later point further messages,
like participants joining or leaving the conversation, could be added
too.
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>
This will no longer log an error if the room type of the received
message is neither "video" nor "screen". However, that should never
happen, and it would be useful only while debugging, so it is fine to
lose that.
Note that the check is not added to SignalingMessageReceiver itself to
keep it as generic as possible (and due to the low value of adding it as
explained above). Nevertheless, if needed in the future it would be
possible to add a special listener that receives raw messages in order
to validate them and log the errors, if any.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Although "unshareScreen" is technically bound to a specific peer
connection it is instead treated as a general message on the call
participant.
Nevertheless, call participant messages will make possible (at a later
point) to listen to events like "raise hand" or "mute" (which, again,
could be technically bound to a specific peer connection, but at least
for now are treated as a general message on the call participant).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Unlike the WebRtcMessageListener, which is bound to a specific peer
connection, an OfferMessageListener listens to all offer messages, no
matter which peer connection they are bound to. This can be used, for
example, to create a new peer connection when a remote offer for which
there is no previous connection is received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Eventually all signaling related code should be moved to a Signaling
class that abstracts the differences between the internal and external
signaling servers, including how messages are sent and listened to. In
the meantime a temporary SignalingMessageReceiver implementation is
added to CallActivity to be able to start using it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only WebRTC messages can be listened to, although it will be
extended with other kinds later.
This commit only introduces the base class, although it is not used yet
anywhere; a concrete implementation will be added in a following commit.
The test class is named "SignalingMessageReceiverWebRtcTest" rather than
just "SignalingMessageReceiverTest" to have smaller, more manageable
test classes for each listener kind rather than one large test class for
all of them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Although the rest of the methods are no longer needed since the handling
of WebRTC messages was moved to PeerConnectionWrapper "setSessionId()"
was not needed even before that.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"peerConnectionWrapper" needs to be defined to enter the if and execute
the switch, so just return before the switch if "peerConnectionWrapper"
is null.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The message type is set for all signaling messages. On the other hand,
the payload type is only set for offers and answers (and, if the message
was sent by the Android app, also for candidates). However, in all those
cases the payload type just duplicates the message type, so the message
type can be assigned directly rather than falling back to it if there is
no payload type.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
