WebRTC 1:1 calls were silently broken behind symmetric NAT (corporate
firewalls, mobile CGNAT, Incus default networking) because no TURN
relay was deployed. The /api/v1/config/webrtc endpoint and the
useWebRTC frontend hook were both wired correctly from v1.0.9 Day 1,
but with no TURN box on the network the handler returned STUN-only
and the SPA's `nat.hasTurn` flag stayed false.
Added :
* docker-compose.prod.yml: new `coturn` service using the official
coturn/coturn:4.6.2 image, network_mode: host (UDP relay range
49152-65535 doesn't survive Docker NAT), config passed entirely
via CLI args so no template render is needed. TLS cert volume
points at /etc/letsencrypt/live/turn.veza.fr by default; override
with TURN_CERT_DIR for non-LE setups. Healthcheck uses nc -uz to
catch crashed/unbound listeners.
* Both backend services (blue + green): WEBRTC_STUN_URLS,
WEBRTC_TURN_URLS, WEBRTC_TURN_USERNAME, WEBRTC_TURN_CREDENTIAL
pulled from env with `:?` strict-fail markers so a misconfigured
deploy crashes loudly instead of degrading silently to STUN-only.
* docker-compose.staging.yml: same 4 env vars but with safe fallback
defaults (Google STUN, no TURN) so staging boots without a coturn
box. Operators can flip to relay by setting the envs externally.
Operator must set the following secrets at deploy time :
WEBRTC_TURN_PUBLIC_IP the host's public IP (used both by coturn
--external-ip and by the backend STUN/TURN
URLs the SPA receives)
WEBRTC_TURN_USERNAME static long-term credential username
WEBRTC_TURN_CREDENTIAL static long-term credential password
WEBRTC_TURN_REALM optional, defaults to turn.veza.fr
Smoke test : turnutils_uclient -u $USER -w $CRED -p 3478 $PUBLIC_IP
should return a relay allocation within ~1s. From the SPA, watch
chrome://webrtc-internals during a call and confirm the selected
candidate pair is `relay` when both peers are on symmetric NAT.
The Ansible role under infra/coturn/ is the canonical Incus-native
deploy path documented in infra/coturn/README.md; this compose
service is the simpler single-host option that unblocks calls today.
v1.1 will switch from static to ephemeral REST-shared-secret
credentials per ORIGIN_SECURITY_FRAMEWORK.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The prod and staging compose files were passing AWS_S3_ENDPOINT,
AWS_S3_BUCKET, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY but NOT
the two flags that actually activate the routing:
- AWS_S3_ENABLED (default false in code → S3 stack skipped)
- TRACK_STORAGE_BACKEND (default "local" in code → uploads to disk)
So both prod and staging deploys were silently writing track uploads
to local disk despite the apparent S3 wiring. With blue/green
active/active behind HAProxy, that's an HA bug — uploads on the blue
pod aren't visible to green and vice-versa.
Set both flags in:
- docker-compose.staging.yml backend service (1 instance)
- docker-compose.prod.yml backend_blue + backend_green (2 instances,
same env block via replace_all)
The code already validates on startup that TRACK_STORAGE_BACKEND=s3
requires AWS_S3_ENABLED=true (config.go:1040-1042) so a partial
config now fails-loud instead of falling back to local.
The S3StorageService is already implemented (services/s3_storage_service.go)
and wired into TrackService.UploadTrack via the storageBackend dispatcher
(core/track/service.go:432). HLS segment output remains on the
hls_*_data volume — that's a separate concern (stream server local
write), out of scope for this compose-only fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
MinIO images were pinned to `:latest` in 4 compose files — supply-
chain risk (auto-updates on every `docker compose pull`, bit-rot if
upstream changes behavior). Pin to dated RELEASE.* tags documented
by MinIO (conservative Sep 2025 release).
Changed:
docker-compose.yml ×2 (minio + mc)
docker-compose.dev.yml ×2
docker-compose.prod.yml ×2
docker-compose.staging.yml ×2
Tags:
minio/minio:RELEASE.2025-09-07T16-13-09Z
minio/mc:RELEASE.2025-09-07T05-25-40Z
Operator should bump to latest verified release when they next
revisit infra. Tag chosen conservatively — if it does not exist in
local Docker cache, `docker compose pull` will surface the error
immediately (safer than silent drift).
Refs: AUDIT_REPORT.md §6.1 Dette 1 (MinIO :latest 4 occurrences).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add HLSEnabled and HLSStorageDir to backend config (HLS_STREAMING env)
- Register HLS serving routes (master.m3u8, quality playlist, segments)
behind HLSEnabled feature flag on existing track routes
- Add GetHLSStatus and TriggerHLSTranscode methods to StreamService
for stream server communication
- Update docker-compose (dev, staging, prod) with HLS env vars and
shared hls-data volume between backend and stream-server
- Stream callback already correctly updates stream_manifest_url
Production (docker-compose.prod.yml):
- Change sslmode=disable to sslmode=require on all 3 DATABASE_URLs
- Replace JWT_SECRET fallback defaults with :? syntax (fails if unset)
- Replace DB_PASS default 'password' with :? syntax (fails if unset)
- Separate RABBITMQ_PASS from DB_PASS, require explicit setting
Staging (docker-compose.staging.yml):
- Add sslmode=require to DATABASE_URL
- Replace all default passwords with :? syntax (fails if unset)
docker-compose up with these files will now FAIL if required secrets
are not explicitly provided via environment variables.
Addresses audit findings: A02 (Cryptographic Failures), section 7 (Infra).
Co-authored-by: Cursor <cursoragent@cursor.com>
