niom-webrtc/docs/architecture/signaling_flow.md

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.