v1.1.0
Pushing the wrong audio layout at the guest endpoint got you a dropped SRT connection and nothing else. The gateway knew exactly what was wrong, logged "unusable audio: 1 track(s) x 2 ch; expected 4x4 or 1x4", and that string never left the container. A tester worked through three ffmpeg invocations and OBS against a bare I/O error before writing in to ask.
SRT cannot carry the answer. A rejection reason exists in the handshake, but the audio layout is not known until media has been buffered and probed, and an established connection can only be dropped, never explained. The missing link was not the transport but the sequence: the gateway probes BEFORE it claims a slot, so a refused push never becomes a session telemetry knows about, and there is no session id for the existing done call to reference. /gw/session/reject accepts one without a session and records it while the slot is free.
The panel that displays it had existed since the RTMP path needed it, and had never once appeared for an SRT refusal: it was gated on the reason containing "playable output", the RTMP stall wording. It now shows whatever reason arrives, translated where the shape is known, with the ambisonic channel guidance attached only to the reasons that guidance explains. A stream that simply ran to its end is no longer told what channel counts are required.
Found while testing that, and worse: the player crashed and blamed telemetry. renderGuestNotice guarded the optional brand.json payload on one line and dereferenced it unguarded on the next, so a guest going live on a deployment without branding threw inside the /api/live handler. The throw landed in that fetch's .catch, which told the visitor "the server status service is not responding" while telemetry answered 200 throughout, leaving the player unusable for the whole session it exists to show. Note that a .catch cannot tell a failed request from a handler that threw, so any future render bug will be reported the same way.
Safari can play this stream, which it could not before: it decodes multichannel Opus through no native route, so the player now fetches the DASH audio segments itself and decodes them with libopus compiled to WebAssembly in a worker, scheduled against the video element's clock. Read it as progress rather than support. Moving Safari to another Space still stops the audio after about two seconds, because the fix needs a silent audio track in the manifest that earshot does not emit yet, and iPhone remains blocked behind a separate gate in videojs-contrib-dash. docs/IOS-SAFARI.md carries the measurements and what each route costs.
The status badge now names the source. It read LIVE for the demo loop, a guest and an owner alike, so when the loop resumed after a guest session the picture changed while the page said the same thing.
rtmp-ingest picks up Alpine's patched OpenSSL (CVE-2026-14456). It shipped 3.5.7-r0 because apk add resolves what is MISSING and leaves what the base image already carries, which no amount of rebuilding changes. A comment in another image asserted the opposite and is corrected.
GUEST-ENDPOINT.md now states the four-channel requirement next to the connection URL rather than in a failure-mode bullet further down, and no longer claims a wrong layout takes ~45 s to be refused: that is the RTMP path, and SRT rejects at about 15.
No change to the streaming path, the DASH shape, or the codecs.