Any authenticated participant can now start a recording on trusted
and public rooms. This is essential, requested by many users, and
should encourage people to authenticate on public rooms. It also
means the starter may hold no role on the room, so who gets access
to the recording has to be decided explicitly.
The part open to discussion is the recording access: who should be
owner/admin on the recording. This commit picks the simplest
design:
* The starter and the room's owners and administrators all get an
`OWNER` `RecordingAccess`, so they can retrieve, download and
delete the recording, and they all receive the "recording ready"
email.
* Room roles are copied when the recording starts: later changes
to the room's accesses do not affect existing recordings.
The people responsible for a meeting should get access to its
recording and transcript, along with whoever initiated it.
One constraint is respected: the summary service creates a doc,
and the docs API can only attribute it to a single owner. The
summary therefore goes to the oldest `OWNER`, and the starter's
access is created before the room owners/admins ones, so the
starter receives it. The previous lookup took `.first()` with the
default newest-first ordering, which with several owners would
have picked a room admin.
Alternatives considered:
* A `creator` attribute on the recording row: it only adds a
migration without adding value to access control, so it was
dropped.
* Restricting access to the link owner even when someone else
starts the recording: some organizations may want this for
security reasons, but it is YAGNI until a few large clients ask
for it.
I think we should contribute to Docs' api to allow sharing the
transcription document with several users.
Add new options to query start-start recording API. A resolution
("540p", "720p", "1080p") and a profile ("talking_heads", "text", "mixed")
are resolved to provide a width, height, fps and bitrate which
are passed on to the encoder. Using profiles allows for some flexibility
on quality if necessary without changing front facing user config.
Co-authored-by: sarthakbahal <sarthakbahal.45@gmail.com>
Recordings used to be finalized by an inbound notifications sent by
S3. This tied the recording lifecycle to bucket notifications, adding
complexity and dependency to limited S3 services.
The LiveKit egress_ended webhook, added as a fallback in aee1847, does
the same job without any object-storage dependency. Make it the only
mechanism: RecordingEventsService.handle_complete is now called on
EGRESS_COMPLETE / EGRESS_LIMIT_REACHED unconditionally, instead of only
when RECORDING_STORAGE_EVENT_ENABLE is False. Remove the storage-event
path entirely.
Recording lifecycle previously relied exclusively on the MinIO storage-hook
endpoint to transition from STOPPED to SAVED, which made the system dependent
on MinIO bucket notifications and lifecycle configuration. Introduce support
for LiveKit egress_ended webhook (EGRESS_COMPLETE, EGRESS_LIMIT_REACHED) as
an alternative finalization mechanism for self-hosted deployments that do
not use MinIO / S3 hooks.
Change behavior of existing configuation RECORDING_STORAGE_EVENT_ENABLE.
When the LiveKit mechanism is enabled (RECORDING_STORAGE_EVENT_ENABLE=False),
RecordingEventsService.handle_complete is triggered from
LiveKitEventsService._handle_egress_ended.
Expose RECORDING_ENCODING_* settings to override the default LiveKit
Egress preset (H264_720P_30). When RECORDING_ENCODING_ENABLED is True,
the provided width/height/framerate/bitrate/keyframe values are passed
as advanced EncodingOptions. Lowering framerate and bitrate reduces
recording file size and egress worker CPU load.
Disabled by default, preserving current behaviour.
Add comprehensive recording documentation explaining system requirements
and component interactions to help administrators understand infrastructure
needs and troubleshoot recording functionality.
lebaudantoine