# niom-webrtc Voice Channel Module Docs

Diese Dokumentationssammlung beschreibt das MVP-Modul "Voice Channel" im Projekt `niom-webrtc`. Die Struktur spiegelt die wichtigsten Programmkomponenten wider und soll als Einstieg für neue Sessions dienen.

- [`architecture/signaling_flow.md`](architecture/signaling_flow.md) – High-Level-Ablauf von Signaling, WebRTC und TURN.
- [`config/config_management.md`](config/config_management.md) – Konfigurationen und Defaults (STUN/TURN, Appsettings).
- [`components/`](components/) – UI-Komponenten (Discord-Voice-Channel UI) inkl. Zustandsfluss.
	- [`voice_channel_layout.md`](components/voice_channel_layout.md)
- [`utils/media_manager.md`](utils/media_manager.md) – Medien- und Peer-Connection-Helfer.

## Aktueller Fokus
- Discord-Voice-Channel UI als reines Modul ohne restliche App-Shell.
- Saubere Trennung von Initiator/Responder-Logik.
- Testbarkeit im Browser (WASM) und auf CLI-Ebene.

## Offene ToDos (Stand 02.11.2025)
1. WebRTC-/Signaling-Logik aus Komponenten in dedizierte Hooks/Services auslagern (z. B. `use_signaling`, `use_peer_connection`) und globalen State für Teilnehmer & Sessions einführen.
	- Ziel: UI-Komponenten konsumieren nur noch lesende Signale & Events, Logik wird separat testbar.
2. TURN-Infrastruktur produktionsreif aufsetzen (Zertifikate, Auth, Monitoring) und E2E-Tests (Peer↔Peer via TURN) ergänzen.
3. UI modularisieren: Geräte-Setup, Fehlerbanner, Status-Badges, Vorbereitung auf Video-/Screen-Sharing-Tiles.
4. Signaling-Server erweitern (Raum-/Teilnehmermodell, AuthZ, robustes Error-Handling) und Schnittstellen dokumentieren.
5. CI-Pipeline mit `fmt`/`clippy`/Tests, Smoke-Tests (Web + CLI) und Playwright-Szenarien für Browserflows anlegen.