# Signaling & Media Flow

Dieses Dokument beschreibt, wie das Voice-Channel-Modul mit Signaling-Server (`niom-signaling`) und TURN-Server (`niom-turn`) interagiert.

## Beteiligte Dienste
- **Client (`niom-webrtc`)**: Dioxus-Frontend im Browser. Baut PeerConnections, verwaltet UI-Zustand und kommuniziert mit Signaling per WebSocket.
- **Signaling (`niom-signaling`)**: Actix-Web-Server, der Nachrichten zwischen Peers austauscht. Derzeit Broadcast, später rooms.
- **TURN (`niom-turn`)**: UDP/TLS TURN-Server mit STUN-Fallback. Sorgt für NAT-Traversal, sobald ICE-Candidates verwendet werden.

## Flow (MVP Heutiger Stand)
1. **WebSocket-Aufbau**: `ConnectionPanel` verbindet sich zu `ws://localhost:3478/ws`.
2. **Peer-ID**: Clients generieren lokale IDs; Remote-ID wird manuell eingetragen.
3. **Offer/Answer**:
   - Initiator (`CallControls`) baut `RtcPeerConnection`, hängt lokale Audio-Tracks an und erzeugt ein Offer (SDP).
   - Offer wird via Signaling an Remote gesendet.
   - Responder (`ConnectionPanel` Coroutine) erstellt eigene PeerConnection und generiert eine Answer.
4. **ICE-Kandidaten**: Beide PeerConnections senden `candidate`-Messages an Signaling. Kandidaten werden dynamisch hinzugefügt.
5. **Medien**: `ontrack`-Handler erzeugt `<audio>`-Elemente und spielt Remote-Audio automatisch ab.

## Geplante Erweiterungen
- **Room-/Channel-IDs** statt manueller Remote-ID.
- **Persistentes State-Management**: Gemeinsame Signals/Store für Teilnehmerliste, Sprecherstatus, Device-Einstellungen.
- **TURN-Integration**: Konfigurierbare ICE-Server aus `appsettings.json` (STUN/TURN). UI-Feedback bei Verbindungspfaden.
- **Video-Support**: Erweiterung der MediaStreams für Video, Layout-Anpassungen.