octoturge
6fab9072d4
The player posted its SDP offer to the gateway's go2rtc directly, which cannot work from a browser on another origin: no CORS headers on any go2rtc response, a preflight required because application/sdp is not CORS-safelisted, and the password checked before CORS so that preflight gets a 401. It now hands the offer to a `signal` function the app supplies, which relays it through the backend. Pinned to iceTransportPolicy "relay" whenever ICE servers are present, so media always goes through the TURN relay and never peer-to-peer. A hosted console cannot rely on reaching a customer's gateway directly, and a camera that works from the workshop but not from home is worse than one that behaves the same everywhere. With no TURN configured it falls back to "all", which still works for a viewer on the gateway's own network. Relay-only with no relay would gather no candidates and fail every time, so the fallback is what makes an unconfigured deployment degrade rather than break - and a failed connection in that state now says so, since the browser reports nothing but "failed" and the fix is a deployment setting. It also waits for ICE gathering before signalling rather than trickling: the answer comes back through a single request/response relay hop, so there is no channel to trickle over afterwards and the offer has to carry its candidates. Bounded at 3s, because gathering can hang on a candidate that never resolves and signalling with what we have beats waiting forever. `signal` is a prop rather than a fetch in the component, like `stream` already was: @continuum/ui stays plain Vue that knows nothing of the API, which is what lets it render from a test or the desktop shell.
73 lines
3.2 KiB
TypeScript
73 lines
3.2 KiB
TypeScript
/**
|
|
* Where a printer's camera can be watched, from `GET /printers/:id/stream`.
|
|
*/
|
|
export interface PrinterStream {
|
|
/** The go2rtc stream name to negotiate for. */
|
|
cameraId: string;
|
|
/**
|
|
* ICE servers for the player's `RTCPeerConnection`, minted per request and
|
|
* short-lived. Empty when the backend has no TURN configured.
|
|
*/
|
|
iceServers: RTCIceServer[];
|
|
/**
|
|
* Whether TURN is configured at all, which is the difference between "no
|
|
* relay is needed here" and "the relay is missing". Empty `iceServers`
|
|
* with this true would mean minting silently failed.
|
|
*/
|
|
turnConfigured: boolean;
|
|
}
|
|
|
|
/**
|
|
* Asks the backend where a printer's camera can be watched, or `null` if it
|
|
* cannot.
|
|
*
|
|
* It returns no URL, and that is the point. A browser cannot reach a gateway
|
|
* directly: go2rtc sends no CORS headers and checks its API password before
|
|
* CORS, so an unauthenticated preflight gets a 401 - measured against
|
|
* 1.9.14 - and a gateway sits behind a workshop NAT anyway. This used to
|
|
* return the gateway's LAN address, which could only have worked for an
|
|
* operator standing on that same network.
|
|
*
|
|
* So what comes back is a camera name and the ICE servers to negotiate with.
|
|
* The offer goes to the backend, which relays it to the gateway over the
|
|
* socket the gateway already holds open; the media then travels
|
|
* browser-to-gateway through the TURN relay, DTLS-SRTP encrypted, so neither
|
|
* the backend nor the relay can read it.
|
|
*
|
|
* A plain function and not a `useAsyncData` wrapper despite the file it lives
|
|
* in: the caller needs one of these per printer, discovered from a list that
|
|
* itself arrives asynchronously, and Nuxt's data composables may only be
|
|
* called while a component is setting up. A loop over a resolved list is not
|
|
* that. It takes the fetcher as an argument for the same reason - the caller
|
|
* builds it in setup, where `useApiFetch` is valid.
|
|
*
|
|
* **Absence is the normal case, not an error.** Only Bambu's X1/H2 class
|
|
* publishes a camera URL a gateway can restream; a P1 or A1 reports that it
|
|
* has a camera and gives nothing to connect to. The backend answers 404 for
|
|
* those, so this answers `null` and the caller shows no player at all -
|
|
* rendering one that can never load would be worse than rendering nothing.
|
|
*
|
|
* The credentials are deliberately not cached: they are short-lived, so a
|
|
* player that reconnects should ask again rather than retry a session with a
|
|
* credential that has since expired.
|
|
*/
|
|
export async function fetchPrinterStream(
|
|
apiFetch: ReturnType<typeof useApiFetch>,
|
|
printerId: string,
|
|
): Promise<PrinterStream | null> {
|
|
try {
|
|
return await apiFetch<PrinterStream>(`/printers/${printerId}/stream`);
|
|
} catch (err: unknown) {
|
|
// A 404 means "this printer has no watchable camera", which is expected
|
|
// often enough that treating it as a failure would put an error state on
|
|
// most cards in a mixed fleet. Anything else is a real problem: logged
|
|
// and then treated as "no stream", because a broken camera lookup should
|
|
// not take the fleet overview down with it.
|
|
const status = (err as { statusCode?: number }).statusCode;
|
|
if (status !== 404) {
|
|
console.warn(`could not look up the camera stream for printer ${printerId}`, err);
|
|
}
|
|
return null;
|
|
}
|
|
}
|