The element-calling feature only advertised the LiveKit focus via the
well-known org.matrix.msc4143.rtc_foci file, and relied on STUN
auto-detection for the public IP. Element X queries the MatrixRTC
transports registry endpoint and fails with MISSING_MATRIX_RTC_TRANSPORT
when it is absent, and blocked STUN egress silently left LiveKit
advertising a private IP (call connects but no video across servers).
- synapse: enable msc4143_enabled and advertise matrix_rtc.transports
(MSC4519) with the site's element-calling URL, so Element X can
discover the LiveKit focus instead of erroring out
- livekit: determine the public IP to advertise at runtime —
explicit pin, then HTTPS egress detection (api.ipify.org /
checkip.amazonaws.com / ifconfig.me), then STUN fallback with a
warning; reject non-routable results (private/loopback/CGNAT)
- lk-jwt-service: append optional extra homeservers to
LIVEKIT_FULL_ACCESS_HOMESERVERS via the new
sovran_systemsOS.elementCalling.fullAccessHomeservers option
- add sovran_systemsOS.elementCalling.externalIP option to pin the
advertised public IP for multi-WAN/VPN setups
- add element-calling-public-check.service: boot-time diagnostics for
public DNS (via 1.1.1.1, bypassing local loopback overrides), JWT
healthz through Caddy and via the public IP, and the transports
endpoint — turns the silent -no media- failure into a visible error
- add restartTriggers so livekit/lk-jwt-service pick up regenerated
runtime configs on rebuild
livekit-turn-setup.service detects the primary interface from the IPv4
default route, but had no ordering against network-online.target. With
NetworkManager+DHCP the default route is applied late at boot, so the
oneshot could run before it existed, exit 1, and — being a hard
dependency of livekit.service — take livekit down with it. The Hub then
showed a 'failed' red dot until livekit was restarted manually.
Order both livekit.service and livekit-turn-setup.service after
network-online.target. Also add a bounded retry when copying Caddy's ACME
cert so we never write an empty turn.crt/turn.key on a fresh boot.
LiveKit was exiting cleanly with "TURN domain required" because turn.enabled
was set in the build-time config but turn.domain was never provided to the
process (the old livekit-runtime-config.service wrote a YAML that nothing
read). A clean exit (status 0) meant Restart=on-failure never restarted it,
so the Hub reported the service as Inactive.
This replaces the dead runtime-config oneshot with livekit-turn-setup.service,
which at runtime:
- reads the matrix domain from /var/lib/domains/matrix (no hardcoding)
- copies Caddy's already-issued matrix cert/key into /var/lib/livekit
- generates a complete LiveKit config (incl. turn.domain + TLS cert/key)
at /run/livekit/livekit.yaml
The livekit.service ExecStart is overridden to load that runtime config
(mirroring the existing Caddy ExecStart override pattern in
modules/core/caddy.nix), since turn.domain is only known at runtime. The cert
is delivered via LoadCredential so it is readable under DynamicUser=true
without weakening the sandbox.
Also aligns the RTC media port range (rtc.port_range_start/end = 30000-40000)
so it matches the forwarded ports, and drops the now-redundant manual
30000-40000 firewall ranges (covered by services.livekit settings/openFirewall).
naturallaw777
copilot-swe-agent[bot]
Sovran Systems