The compose stack referenced livekit/livekit-server without a tag,
which resolved to :latest. Docker doesn't re-resolve a mutable tag it
already holds locally, so images earlier than v1.12.0 crashed
on startup:
could not parse config: yaml: unmarshal errors:
line 20: field allow_restricted_peer_cidrs not found in
type config.TURNConfig
LiveKit parses its config in strict mode, and allow_restricted_peer_cidrs
only exists since v1.12.0. The TURN block added in bd81c994 therefore
carried an minimum version which was not reflected.
The Tilt/Helm stack builds its own image from docker/livekit/Dockerfile
to inject the mkcert root CA, and that was still based on v1.9.4. Bump
it to the same version so both dev stacks run the same server.
Wire a TURN server into the local LiveKit server used by the dev
stack, so ICE negotiation has more candidate types available during
local testing.
Makes it easier to reproduce connectivity scenarios that would
otherwise only show up on stricter networks in production.
Without this configuration, LiveKit does not notify the backend when a recording
starts, leaving it stuck in a “starting recording” state.
Thanks to @leobouloc for spotting the issue.
Update development environment LiveKit server from previous version
to 1.9.0 for latest features and bug fixes.
Ensures development environment stays current
with LiveKit production version.
Override LiveKit Docker image to include nip.io Certificate Authority for
development environment. Addresses issue where LiveKit webhook calls fail in
dev mode due to unknown CA. Custom image places certificate in appropriate
location since LiveKit chart lacks volume mounting options for CA certs or
webhook SSL disabling capabilities.
Discussed with @rouja.
LiveKit offers Universal Egress, designed to provide universal exports
of LiveKit sessions or tracks to a file or stream data.
Egress is kept outside of the server to keep the load off the SFU and avoid
impacting real-time audio or video performance/quality.
Followed the "Running Locally" steps from the https://github.com/livekit/egress
repository, but I adapted them to docker-compose.
By default, I chose to run both the LiveKit server and the Egress when you
up the stack. If we see any performance issue, we could only run the LiveKit
server, which is the barebone of the product.
Egress will be usefull only when dealing with recording/exporting data.
Egress service will output file recordings to "./docker/livekit/out"
Note: the Egress service doesn't run as root. You need to update the "/out"
permissions, so all user could write to it.
LiveKit server configuration was the default ones. These configurations
were not connecting to any Redis instance. When running a standalone
LiveKit server, Redis is not needed.
However, when adding other LiveKit ecosystem service, e.g. Egress,
LiveKit server publish jobs to a Redis queue, that are handled by
the Egress workers.
(Precisely, they use Redis Pub/Sub to communicate but I am no expert)
The LiveKit server and the Egress need to be connected to the same
Redis instance. This commit configure the LiveKit server before
adding the Egress service to the compose stack.
leo