The nick name below the avatar is distributed through the DataChannel of the
PeerConnection and only sent once during establishment. For the MCU case,
the sending PeerConnection is created once and then never changed when more
participants join.
For this, we periodically send the nick to all other participants through the
sending PeerConnection.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
When the peer is a registered user her name is shown when a stream is
added for that peer. However, if the peer has no microphone nor camera
then no stream is added, and thus the name was not shown. Now the name
is shown too when the connection is established to guarantee that it
will be shown even if no stream is added.
In the case of guest users the name is shown when a stream is added for
that peer, but also when a "nickChanged" message is received. That
message is sent when the peers are connected, so the name of the guest
user was already properly set even if the user has no microphone nor
camera.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
With the MCU, a newly subscribed stream might not get the "audioOn"/"videoOn"
messages as they are only sent when a user starts publishing.
Instead wait for initial data and trigger events locally.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
With an MCU, each client publishes only once (to the MCU) and viewers subscribe
the streams from the MCU. This means that for subscribing, the MCU always has
to send the "Offer" message which requires some changes in the workflow.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
This removes the long-polling against the PHP backend and instead sends an
event to all users in a room through the standalone signaling server to
notify that new chat messages exist.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Adding a participant to a room can be done only by the owner and
moderators of that room, so the "Add participant" dropdown should be
shown only to those types of participants.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before a user could disable her own video, but she had no way to disable
the videos from other participants. This could be needed, for example,
to alleviate the load on low-end systems, as in that case playing the
video from remote participants could be too much for the system. Now a
toggle is provided to manually show or hide the video of each remote
participant if needed.
The toggle is shown only when the remote participant is sending video;
if the remote participant has disabled her own video (or does not have a
camera) the toggle is hidden.
Note that the toggle just shows or hides the HTML video element; it does
not notify the remote participant to mute her video or to fully stop
sending it. It is purely a local change that does not affect the remote
clients. In the future this could be extended to involve the remote
clients too, but for now just hiding the HTML video element notably
reduces the CPU load in most systems (although unfortunately in some
cases it does not).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "hidden" CSS class is not used in the avatar container of remote
participants (only for the local one), so there is no need to remove it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the streams are initialized and there is no audio or no video the
"audio/videoNotFound" flag is set. This flag prevents the audio or video
from being enabled later, and it is also used to discard calls to
"disableAudio/Video", as there would be no need to disable them if they
were not found. However, in that last case, it is necessary to
explicitly disable them before the flag is set.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a participant is selected in the select2 dropdown the "change"
event is triggered for the "Add participants" input; this sets the value
of the input and also adds the participant to the room. However, the
event is triggered only if the selected item is different than the
current value of the "Add participant" input. Due to this, the value has
to be cleared when it is set to make possible to add the same
participant several times in a row (for example, in different rooms).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Otherwise there is a race condition of the Nextcloud server notifying the
signaling server about the user in the call before the user has joined the
room.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
No functional changes yet, but this will allow later to use the standalone
signaling backend to notify clients about new chat messages without having
to poll (see #624).
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Joas Schilling
Arthur Schiwon
Ivan Sein
Jan-Christoph Borchardt
Joachim Bauch
Daniel Calviño Sánchez
Joas Schilling