25 lines
1.8 KiB
Markdown
25 lines
1.8 KiB
Markdown
# 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 & Reconnect**: `ConnectionPanel` verbindet sich zu `ws://localhost:3478/ws` und nutzt den `SignalingProvider`, der bei Fehlern mit exponentiellem Backoff erneut verbindet.
|
|
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.
|