feat(backend): add SIMPLE_STREAMING WebRTC control-path streaming

This commit is contained in:
2026-03-05 13:30:00 +00:00
parent c458857f0a
commit 19baf76169
14 changed files with 448 additions and 189 deletions

View File

@@ -130,21 +130,23 @@ Motion realtime events:
- Linked clients receive `motion:detected` as soon as camera starts event.
- Linked clients receive `motion:ended` when camera ends event.
### On-Demand Streams + Media Credentials (Phase 4 + 5)
### On-Demand Streams + WebRTC Control Plane
| Endpoint | Purpose |
| --- | --- |
| `POST /streams/request` | Client device requests a linked camera to start a live stream |
| `POST /streams/:streamSessionId/accept` | Camera device accepts and transitions stream session to `streaming` |
| `GET /streams/:streamSessionId/publish-credentials` | Camera fetches media ingest credentials for the active stream session |
| `GET /streams/:streamSessionId/subscribe-credentials` | Viewer fetches media subscribe credentials for the active stream session |
| `POST /streams/:streamSessionId/end` | Requester/camera ends an existing stream session |
| `GET /streams/:streamSessionId/playback-token` | Obtain short-lived playback token for active stream |
| `GET /streams/me/list` | List stream sessions for the current device |
Stream realtime events:
- Client receives `stream:requested` after request creation.
- Camera receives `stream:requested` when `SIMPLE_STREAMING=true`.
- Client receives `stream:started` when camera accepts.
- Both devices receive `stream:ended` when session is closed.
- Both participants exchange `webrtc:signal` payloads through Socket.IO for offer/answer/candidate/hangup relay.
Legacy compatibility when `SIMPLE_STREAMING=false`:
- `start_stream` device commands remain active for camera wake-up.
- Media-provider credential endpoints (`publish-credentials`, `subscribe-credentials`, `playback-token`) remain available for older simulator/mobile flows.
Experimental SFU scaffolding endpoints (`MEDIA_MODE=single_server_sfu`):
- `GET /streams/:streamSessionId/sfu/session` fetch in-memory SFU session state for participant devices
@@ -153,8 +155,9 @@ Experimental SFU scaffolding endpoints (`MEDIA_MODE=single_server_sfu`):
#### Streaming Scale Tradeoffs (Current Prototype)
- The current implementation is **not production-grade at scale**.
- Video quality and reliability currently depend on direct browser-to-browser WebRTC success, with a low-fps frame relay fallback in the simulator.
- This backend currently acts as a control plane (commands, session state, credentials, events), not a full media plane/SFU.
- The preferred path is direct browser-to-browser WebRTC, with the backend acting as auth/session/signaling control plane.
- Native mobile is not yet on the WebRTC path; `SIMPLE_STREAMING` defaults to `false` until a supported RN WebRTC stack is added.
- This backend currently acts as a control plane (commands, session state, signaling, events), not a full media plane/SFU.
- Running live transport + fan-out + recording on the same web server is possible for small loads but introduces significant CPU, RAM, and network egress pressure under concurrency.
- For larger deployments, use a dedicated media plane (managed or self-hosted SFU + recorder) and keep this service focused on auth/session/control APIs.
- For a pragmatic prototype path that keeps media on the current server, see `docs/streaming-on-web-server-plan.md`.
@@ -185,8 +188,8 @@ Architecture reference page:
All simulator pages support the same flow:
- Register as `camera` or `client`
- Connect Socket.IO with bearer device token
- Camera: process incoming `start_stream` commands, fetch publish credentials, start/end motion events
- Client: create links, request streams, fetch subscribe credentials, and fetch playback tokens
- Camera: process incoming stream requests, negotiate WebRTC, start/end motion events
- Client: create links, request streams, and negotiate WebRTC viewing
### Admin Dashboard
Access `/admin` with Basic auth to: