From 1ab8cd717634766203cf53a76e3e398a3f216f92 Mon Sep 17 00:00:00 2001 From: Randy Hammond Date: Sat, 25 Apr 2026 20:30:31 +0000 Subject: [PATCH] docs: clarify deployment notes after audio HTTP migration Update three lines in deployment-guide.md so the WS-vs-HTTP split is accurate: WebSockets carry CAL metadata (and admin events); audio is fetched separately from /api/calls/:id/audio and only requires ordinary HTTPS forwarding. --- docs/deployment-guide.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/deployment-guide.md b/docs/deployment-guide.md index 8c59bfd..a485ee2 100644 --- a/docs/deployment-guide.md +++ b/docs/deployment-guide.md @@ -117,7 +117,7 @@ Most people already have a web server (Caddy, nginx, Traefik) on their home serv Two rules to remember when proxying: -- **Forward WebSocket upgrades** on `/api/ws`, `/ws`, and `/api/admin/ws` — the live audio stream and admin events use them. `/api/ws` is the canonical listener endpoint; `/ws` is a compatibility alias kept for legacy clients and should also be proxied. +- **Forward WebSocket upgrades** on `/api/ws`, `/ws`, and `/api/admin/ws` — the live call feed and admin events use them. `/api/ws` is the canonical listener endpoint; `/ws` is a compatibility alias kept for legacy clients and should also be proxied. (Audio is delivered separately as a regular HTTP response from `/api/calls/:id/audio` and does not require WebSocket forwarding.) - **Send `X-Forwarded-Proto`** so OpenScanner knows whether to mark cookies as secure. If the proxy is on the same machine, it's also a good idea to bind OpenScanner to localhost only so nothing bypasses the proxy. In your compose file: @@ -181,7 +181,7 @@ server { } ``` -After starting the proxy, open the public URL in a browser and confirm the live scanner still plays audio — that's the quickest way to verify the WebSocket forwarding is working. +After starting the proxy, open the public URL in a browser and confirm the live scanner shows new calls and plays audio. New calls arriving prove the WebSocket forwarding is working; audio playing proves the standard HTTPS forwarding (and cookies) are working. > **Tip:** Make sure your server's clock is accurate (NTP is usually on by default). Login tokens have expiry times, and a clock that's off by several minutes will cause confusing login failures. @@ -340,7 +340,7 @@ After deploying, check these to confirm everything works: - [ ] The browser URL shows the scanner interface (or the setup page on first run) - [ ] Admin login works and the dashboard loads - [ ] A test upload from your recorder appears in OpenScanner -- [ ] The live scanner feed plays audio (this proves WebSockets are working) +- [ ] The live scanner feed shows new calls in real time (this proves WebSockets are working) and plays them back (this proves audio HTTP fetches and cookies are working) ---