The speaking state is still sent only through data channels, as it is
not currently handled by other clients when sent through signaling
messages.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that this implicitly send the current state to remote participants
when the local participant joins, as in that case all the remote
participants already in the call join from the point of view of the
local participant
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is not possible when Janus is used, as Janus only allows
broadcasting data channel messages to all the subscribers of the
publisher connection.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The LocalStateBroadcaster observes changes in the
LocalCallParticipantModel and notifies other participants in the call as
needed. Although it is created right before joining the call there is a
slim chance of the state changing before the local participant is
actually in the call, but even in that case other participants would not
be notified about the state due to the MessageSender depending on the
list of call participants / peer connections passed to it, which should
not be initialized before the local participant is actually in the call.
There is, however, a race condition that could cause participants to not
be added to the participant list if they join at the same time as the
local participant and a signaling message listing them but not the local
participant as in the call is received once the CallParticipantList was
created, but that is unrelated to the broadcaster and will be fixed
in another commit.
Currently only changes in the audio, speaking and video state are
notified, although in the future it should also notify about the nick,
the raised hand or any other state (but not one-time events, like
reactions). The notifications right now are sent only through data
channels, but at a later point they will be sent also through signaling
messages as needed.
Similarly, although right now it only notifies of changes in the state
it will also take care of notifying other participants about the current
state when they join the call (or the local participant joins).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is the counterpart of CallParticipantModel for the local
participant. For now it just stores whether audio and video are enabled
or not, and whether the local participant is speaking or not, but it
will be eventually extended with further properties.
It is also expected that the views, like the button with the microphone
state, will update themselves based on the model. Similarly the model
should be moved from the CallActivity to a class similar to
CallParticipant but for the local participant. In any case, all that is
something for the future; the immediate use of the model will be to know
when the local state changes to notify other participants.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Data channel messages are expected to be sent only to peer connections
with "video" type, which provide the audio and video tracks of the
participant (and, in fact, peer connections for screen shares do not
even have data channels enabled in the WebUI).
Note that this could change if at some point several audio/video tracks
are sent in the same peer connection, or if "speaking" messages are
added to screen shares, but that will be addressed if/when that happens.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now it just provides support for sending a data channel message to
all participants, so notifying all participants when the media is
toggled or the speaking status change can be directly refactored to use
it.
While it would have been fine to use a single class for both MCU and no
MCU they were split for easier and cleaner unit testing in future
stages.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Starting with Talk 20 the signaling messages that provide updates to the
participants ("participants->update" in the external signaling server,
"usersInRoom" in the internal signaling server) now include "actorType"
and "actorId" properties for each participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The CallParticipantModel observer now also emits one-time events that
are not reflected in the model state.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note the slight difference in naming between the signaling message
("raiseHand", the action) and the stored data ("RaisedHand", the record
of the action).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only the same signaling messages that were already handled are
still handled; in the future it could be extended to handle other
messages, like the one sent by the external signaling server when a
participant leaves the room (in some cases no participants update
message is sent if the participant leaves the call and room at the same
time, which causes the participants to still be seen as in call until a
new update is received).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
CallParticipant provides a read-only CallParticipantModel and internally
handles the data channel and peer connection events that modify the
model. Nevertheless, the CallParticipant requires certain properties to
be externally set, like the userId or the peer connections.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Clients that modify the model would define the variables using the
mutable subclass, while clients that only need to access the model are
expected to use the read-only base class.
The read-only class provides an observer; as it is expected that the
model will be modified from background threads but observed from the
main thread the observer can be registered along a handler to be
notified on its thread, independently of on which thread the values were
set.
Currently there does not seem to be a need to observe each value on its
own, so the observer is notified in a coarse way when any value changes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
