/** * ICE servers for a browser about to watch a printer camera. * * ## Why the browser needs these at all * * A viewer's browser cannot reach a gateway directly. The gateway is behind a * workshop NAT, and go2rtc will not talk to a browser cross-origin anyway - * measured against 1.9.14, it sends no CORS headers and checks its API * password before CORS, so a browser's unauthenticated preflight gets a 401. * The SDP exchange is therefore relayed through this backend, and the media * itself goes over a TURN relay. * * ## Why only the browser gets credentials * * The browser is pinned to `iceTransportPolicy: "relay"`, so it gathers a * relay candidate and go2rtc simply sends to it from its own candidate. Only * one side of a WebRTC session has to hold a relay for media to traverse one. * * That asymmetry is load-bearing rather than tidy: go2rtc reads its config * exactly once at startup, so TURN credentials on the gateway would have to * be rotated by restarting go2rtc and dropping every viewer on a timer. * Browser-side, rotation lands on a request that is already per-viewer. * * ## What this buys over proxying the video * * WebRTC media is DTLS-SRTP encrypted between the browser and the gateway, so * the relay forwards packets it cannot decrypt. The alternative considered - * tunnelling fMP4 up the gateway's uplink and streaming it from this process - * would have put plaintext video through the API, and `