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>
When the HPB is used the signaling messages can be received even when
the local participant is not currently in the call (for example, when
starting the call timed out without other participant joining, or when
reconnecting due to the publisher connection failing). Therefore if the
local participant is not in the call it should not try to establish a
connection with the other participants and disconnect them instead.
Moreover, if the connection is tried to be established when not
in the call the HPB will prevent that, and the PeerConnectionWrapper
will stay in a limbo state waiting for an offer to be sent. If the local
participant then joins the call the PeerConnectionWrapper will already
exist for the other participants, so no new connections will be created,
but those previous connections will never be finally established.
Additionally, as the signaling messages can be received before the join
call response the participant list could be received while the call
state is "RECONNECTING" or "PUBLISHER_FAILED". In those cases, as long
as the local participant is already in the call, the participant list
should be processed as if the call state was already "JOINED" (otherwise
the connections were not established either).
For simplicity the participant list is now ignored only when the call
state is "LEAVING"; this means that the participant list would be also
processed in the "CONNECTION_TIMEOUT" state, but the signaling message
should not be received anyway in that case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the call is hung up with a view shutdown (which finishes the
activity) there is no need to do any further processing on the
participant list.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a call is joined the call flags of the local participant change, so
this causes a signaling message to be sent by the server. When the HPB
is used the signaling message is sent through a WebSocket, which is
already connected before joining the call. Therefore, in some cases the
signaling message can be received through the WebSocket even before the
response to the HTTP "joinCall" request.
If there are other participants in the call the call state is changed to
"IN_CONVERSATION" when the signaling message is processed. However, in
the case described above the call state was then set to "JOINED", which
automatically traverses to "CONNECTION_TIMEOUT" if no other call state
was set in 45 seconds. Due to all this the call was joined and the
connections with the other participants were established, but they were
not visible in the UI (although they could be heard) and after 45
seconds the call was left.
To prevent that now the call state is changed to "JOINED" if it was not
already changed to "IN_CONVERSATION" in the meantime.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
