The external signaling server expects to receive a "participants"
message from the backend notifier when the participants in a room
change. This message is in turn sent as a participants update signaling
message to the clients, and the WebUI updates the list of participants
whenever that message is received.
However, when the type of a participant changes the backend notifier
sent an "update" message instead, which is in turn sent as a room list
update signaling message to the clients, but it does not trigger any
update in the participants list of the WebUI.
Now a "participants" message is sent too by the backend notifier when
the participants in a room change, so the WebUI updates the list of
participants when handling the participants update signaling message;
the WebUI could have been modified to rely on the room list update
signaling message instead, but using the other message seemed more
appropriate.
Note that the already existing "update" message sent by the backend
notifier is kept for now, as removing it may break the clients in
unexpected ways (although it should go away in the future).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
SimpleWebRTC automatically created an audio and video elements when a
peer stream was added. Those elements were ignored by the Talk code
(which creates its own elements as needed), so they were not needed but
active nevertheless.
In the case of the audio element this caused its audio to always be
played, which would keep the audio from the other participant active
even if the audio element handled by Talk was removed or muted.
For consistency with the rest of its code now SimpleWebRTC creates the
audio and video elements for a peer only if a container for them is
provided.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Passing in the "body" request option as an array to send
a POST request has been deprecated. Please use the "form_params"
request option to send a application/x-www-form-urlencoded
request, or the "multipart" request option to send a
multipart/form-data request. (InvalidArgumentException)
Signed-off-by: Joas Schilling <coding@schilljs.com>
If a Video view is removed its audio element no longer plays the audio.
This can happen, for example, when closing the sidebar in the Files app,
which removes the call view and with it its Video views. But in that
case, even if there is no call view, the call is still active. To ensure
that the audio for another participant is played even if there is no
view for it the audio element must be part of the model instead.
Note that when closing the sidebar the audio was still heard, but that
is caused by a duplicated audio element created in the SimpleWebRTC
code (which will be fixed in a following commit).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Joas Schilling
Joas Schilling
Marco Ambrosini
Nextcloud bot
dependabot-preview[bot]
Joachim Bauch