Revert "feat(streams): add phase-2 SFU transport handshake and produce/consume APIs"
This reverts commit 498a7f838b7747470b220701505c4bfbd3ea8cff.
This commit is contained in:
@@ -34,12 +34,9 @@ Required env vars:
|
||||
| `BETTER_AUTH_BASE_URL` | Public base URL for the backend (e.g., `http://localhost:3000`) |
|
||||
| `BETTER_AUTH_TRUSTED_ORIGINS` | Comma-separated list of allowed frontend origins |
|
||||
| `PORT` | HTTP port (default `3000`) |
|
||||
| `MEDIA_MODE` | Media runtime mode (`legacy` default, `single_server_sfu` for in-process SFU path) |
|
||||
| `MEDIA_SFU_ENGINE` | SFU engine for `single_server_sfu` mode (`mediasoup` default, `noop` fallback) |
|
||||
| `MEDIA_MODE` | Media runtime mode (`legacy` default, `single_server_sfu` scaffold mode) |
|
||||
| `MEDIA_PROVIDER` | Media backend provider (`mock` by default) |
|
||||
| `TURN_URLS` / `TURN_USERNAME` / `TURN_CREDENTIAL` | TURN/STUN configuration used by single-server SFU mode |
|
||||
| `MEDIA_WEBRTC_LISTEN_IP` / `MEDIA_WEBRTC_ANNOUNCED_IP` | WebRTC transport bind/announce IPs for mediasoup SFU. Do not leave bind IP as `0.0.0.0` without an announced IP in non-local environments. |
|
||||
| `MEDIA_RTC_MIN_PORT` / `MEDIA_RTC_MAX_PORT` | UDP/TCP RTP port range for mediasoup worker |
|
||||
| `MEDIA_RECORDINGS_DIR` | Local output directory for server-side recording workers (planned in SFU mode) |
|
||||
| `MEDIA_MAX_PUBLISHERS` / `MEDIA_MAX_SUBSCRIBERS_PER_ROOM` | Soft concurrency limits for single-server media mode (planned) |
|
||||
| `MINIO_*` | Connection settings for the MinIO/S3 endpoint |
|
||||
@@ -148,16 +145,10 @@ Stream realtime events:
|
||||
- Client receives `stream:started` when camera accepts.
|
||||
- Both devices receive `stream:ended` when session is closed.
|
||||
|
||||
Experimental SFU endpoints (`MEDIA_MODE=single_server_sfu`):
|
||||
Experimental SFU scaffolding endpoints (`MEDIA_MODE=single_server_sfu`):
|
||||
- `GET /streams/:streamSessionId/sfu/session` – fetch in-memory SFU session state for participant devices
|
||||
- `GET /streams/:streamSessionId/sfu/router-rtp-capabilities` – fetch router RTP capabilities used by mediasoup-client `Device.load()`
|
||||
- `POST /streams/:streamSessionId/sfu/publish-transport` – camera creates publish transport descriptor
|
||||
- `POST /streams/:streamSessionId/sfu/subscribe-transport` – participant creates subscribe transport descriptor
|
||||
- `POST /streams/:streamSessionId/sfu/publish-transport/connect` – camera marks publish transport as connected
|
||||
- `POST /streams/:streamSessionId/sfu/subscribe-transport/connect` – participant marks subscribe transport as connected
|
||||
- `POST /streams/:streamSessionId/sfu/produce` – camera registers media producer on connected publish transport
|
||||
- `POST /streams/:streamSessionId/sfu/consume` – participant creates consumer from available producer
|
||||
- `public/mobile-sim.js` now uses mediasoup-client handshakes in SFU mode and attaches consumed tracks to `#clientStreamVideo`; legacy mode keeps direct WebRTC + frame relay fallback behavior.
|
||||
|
||||
#### Streaming Scale Tradeoffs (Current Prototype)
|
||||
- The current implementation is **not production-grade at scale**.
|
||||
@@ -166,7 +157,7 @@ Experimental SFU endpoints (`MEDIA_MODE=single_server_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`.
|
||||
- `MEDIA_MODE=single_server_sfu` requires a functional SFU engine (`MEDIA_SFU_ENGINE`, default `mediasoup`) and proper network/port exposure for WebRTC.
|
||||
- `MEDIA_MODE=single_server_sfu` currently enables scaffolding only (interfaces/config/health visibility), not full SFU media routing yet.
|
||||
|
||||
### API Docs
|
||||
OpenAPI docs are generated from Zod/OpenAPI definitions:
|
||||
|
||||
Reference in New Issue
Block a user