2.0 KiB
2.0 KiB
📄 signaling.md — Mesh WebRTC Signaling & ICE Strategy (v2)
1. Objectif
Décrire la signalisation WebRTC (média) et la stratégie de connexions pour Mesh.
Mesh utilise :
- WebRTC pour audio/vidéo/partage écran entre navigateurs
- QUIC P2P pour transferts data (fichiers/dossiers/terminal) via Agent Rust
2. Rappels d’architecture
- Control plane : Mesh Server (WS)
- Media plane : WebRTC (clients web)
- Data plane : QUIC (agents Rust)
Le serveur ne transporte pas de média.
3. WebRTC (média) — ICE
STUN (obligatoire)
Découverte IP publique.
TURN (fallback)
Relais en cas d’échec P2P direct.
Politique candidats :
- host
- srflx
- relay
Recommandations :
- Ne jamais forcer TURN
- Logguer si relay utilisé
4. WebRTC — séquence standard
- Client A demande action (call/screen) au serveur
- serveur valide ACL + émet
cap_token - échange SDP/ICE via WS (
rtc.offer/answer/ice) - flux média direct A↔B
5. QUIC P2P (data) — stratégie
- QUIC = TLS 1.3 natif, multiplexing streams, perf élevée
- Démarrage : création de session via
p2p.session.request - Le serveur fournit
session_token+ endpoints - Les pairs se connectent directement (UDP)
NAT / connectivité
- QUIC peut nécessiter :
- UDP sortant autorisé
- parfois des contraintes NAT/CGNAT
Recommandations :
- privilégier LAN direct
- sur Internet : documenter ouverture/autorisation UDP
- fallback HTTP temporaire (exception)
6. Optimisations data
- chunking 64–256 KB
- backpressure
- reprise par offset
- hash par chunk + hash final (blake3 recommandé)
7. Sécurité
- actions gated by capability token TTL court
- QUIC TLS 1.3
- terminal : preview-only par défaut, contrôle arbitré via serveur
8. Diagnostics
Exposer :
- WebRTC : host/srflx/relay
- QUIC : latence, débit, retries
- erreurs : sessions refusées, tokens expirés
9. Changelog
0.1.0 – WebRTC signaling + ICE
0.2.0 – QUIC data-plane sessions (agent Rust)