Although recordings should not fail in some cases they could (for
example, if the configuration is wrong, the disk is full...). A new
recording status, "failed", has been added to notify that situation to
the Nextcloud server from the recording server.
Typically call participants will not be able to do anything about the
failure, so the clients can just show a notification to the moderators
and hint about asking the system administrators.
In any case, even if the recording status is "failed" further recordings
can be started, which will behave as if the recording was started from
the "none" status.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As starting the recording can take some time "starting" values were
added to signal that an audio or video recording is starting. The
status will be changed from NONE to STARTING_VIDEO/AUDIO by the
Nextcloud server when the request to start the recording succeeds, and
then the recording status will be set to VIDEO or AUDIO by the recording
server once the recording actually started.
Stopping the recording, on the other hand, should be quite fast, so no
STOPPING status were added.
The system messages were also adjusted to be sent only once the
recording really started or stopped.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The participant will be in turn forwarded again to the Nextcloud server
once notified that the recording started or stopped so it retains the
proper participant (for example, in system messages) rather than using
the recording server.
The actor is optional when stopping the recording, as the recording
could be implicitly stopped when the last participant leaves the call.
Nevertheless, this causes the system message to be assigned to a guest
(as the request comes from the recording server), which is unexpected,
so this may need to be adjusted.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before the recording status was immediately changed by the Nextcloud
server when a recording was started or stopped. However starting or
stopping (but mostly starting) can take some time due to the
initialization of the display and audio device, starting the browser,
joining the call... so the recording status did not match the actual
status.
To address that now the recording server sends a notification back to
the Nextcloud server when the recording actually started or stopped, and
only then the Nextcloud server changes the recording status.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Although the recording itself does not require a user uploading the
resulting file does, so it should be limited only to logged in
moderators.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The credentials to be used are specific to the recording server and
unrelated to the SIP bridge. The code follows the same schema used for
validation of external signaling server requests in SignalingController.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently the recording server does not support clustering, so the UI is
limited to add a single recording server, even if internally the
configuration allows more than one.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Marcel Müller
Joas Schilling
Vitor Mattos
jld3103
Daniel Calviño Sánchez