diff --git a/docs/architecture/signaling_flow.md b/docs/architecture/signaling_flow.md new file mode 100644 index 0000000..8071438 --- /dev/null +++ b/docs/architecture/signaling_flow.md @@ -0,0 +1,24 @@ +# 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 `