Architecture réseau WebRTC - la Vitre.

✨ Architecture de communication WebRTC
Ce document détaille l'architecture WebRTC de la Vitre, les mécanismes d'établissement de connexion peer-to-peer et les flux de données entre clients. Destiné aux équipes techniques pour comprendre les communications directes entre Vitres.

Rapprochez-vous, ça change tout..

Architecture générale WebRTC

Vue d'ensemble des zones réseau

graph TB
    subgraph LAN1 ["🏢 LAN 1"]
        V1["📺 Vitre V1"]
        V2["📺 Vitre V2"]
        R1["🌐 ROUTER/PROXY"]
        V1 -.-> R1
        V2 -.-> R1
    end

    subgraph LAN2 ["🏢 LAN 2"]
        V3["📺 Vitre V3"]
        R2["🌐 ROUTER/PROXY"]
        V3 -.-> R2
    end

    subgraph CLOUD ["☁️ LA VITRE CLOUD"]
        API["🔌 API"]
        STUN["🎯 STUN/TURN"]
    end

    %% Connexions HTTPS/WebSocket (Vert)
    R1 -.->|"🟢 HTTPS-WebSocket<br/>TCP 443"| API
    R2 -.->|"🟢 HTTPS-WebSocket<br/>TCP 443"| API

    %% Connexions STUN/TURN (Bleu)
    R1 -.->|"🔵 STUN/TURN<br/>TCP/UDP 443"| STUN
    R2 -.->|"🔵 STUN/TURN<br/>TCP/UDP 443"| STUN

    %% Connexions WebRTC directes (Magenta)
    R1 <-.->|"🟣 WebRTC P2P<br/>Video/Audio/Data<br/>Encrypted UDP/TCP"| R2
    V1 <-.->|"🟣 WebRTC Local"| V2

---

---

Flux de communication détaillés

Flux A : HTTPS - WebSocket (Signalisation)

Protocole : HTTPS - WebSocket - TCP 443

Rôle : Signalisation et gestion des événements.

sequenceDiagram
    participant V1 as 📺 Vitre V1
    participant V2 as 📺 Vitre V2
    participant V3 as 📺 Vitre V3
    participant API as 🔌 API Cloud

    Note over V1,API: Établissement des connexions WebSocket
    V1->>API: HTTPS WebSocket Connection
    V2->>API: HTTPS WebSocket Connection
    V3->>API: HTTPS WebSocket Connection

    Note over V1,API: Signalisation et événements
    API->>V1: Licensing validation
    API->>V2: Event notifications
    API->>V3: Guest join, Settings changed, Space change

    Note over V1,API: Échange des métadonnées de session
    V1->>API: Session metadata
    API->>V2: Forward session data
    API->>V3: Forward session data

Événements gérés :

• Licensing : Validation des licences utilisateur
• Event notifications : Notifications temps réel
• Guest join : Arrivée de nouveaux participants
• Settings changed : Modification des paramètres
• Space change : Changement d'espace virtuel

---

Flux B : STUN/TURN (Découverte réseau)

Protocole : STUN/TURN - TCP/UDP 443

Rôle : Découverte d'adresse IP publique et relais si nécessaire.

sequenceDiagram
    participant V1 as 📺 Vitre V1
    participant V2 as 📺 Vitre V2
    participant V3 as 📺 Vitre V3
    participant STUN as 🎯 STUN/TURN

    Note over V1,STUN: Phase de découverte ICE
    V1->>STUN: STUN Request (Local IPs)
    STUN->>V1: STUN Response (Public IP, NAT type)

    V2->>STUN: STUN Request (Local IPs)
    STUN->>V2: STUN Response (Public IP, NAT type)

    V3->>STUN: STUN Request (Local IPs)
    STUN->>V3: STUN Response (Public IP, NAT type)

    Note over V1,STUN: Activation TURN si nécessaire
    alt NAT Traversal impossible
        V1->>STUN: TURN Allocation Request
        STUN->>V1: TURN Relay IP allocated
    end

Informations découvertes :

• Local IPs : Adresses IP locales des Vitres
• Router IPs : Adresses IP publiques (si traversée NAT possible)
• Relay IPs : Adresses IP de relais (si traversée NAT impossible)

---

Flux C : WebRTC Media (Données multimédia)

Protocole : VIDEO/AUDIO/DATA - WebRTC Encrypted - Dynamic UDP/TCP

Rôle : Transport chiffré des flux audio/vidéo en peer-to-peer.

sequenceDiagram
    participant V1 as 📺 Vitre V1
    participant V2 as 📺 Vitre V2
    participant V3 as 📺 Vitre V3

    Note over V1,V3: Communications WebRTC chiffrées

    rect rgb(255, 240, 245)
        Note over V1,V2: Connexion locale LAN 1
        V1<<->>V2: 🟣 Video Stream (SRTP)
        V1<<->>V2: 🟣 Audio Stream (SRTP) 
        V1<<->>V2: 🟣 Data Channel (SCTP over DTLS)
    end

    rect rgb(240, 248, 255)
        Note over V1,V3: Connexion inter-LAN
        V1<<->>V3: 🟣 Video Stream (SRTP)
        V1<<->>V3: 🟣 Audio Stream (SRTP)
        V1<<->>V3: 🟣 Data Channel (SCTP over DTLS)
    end

    rect rgb(248, 255, 240)
        Note over V2,V3: Connexion inter-LAN
        V2<<->>V3: 🟣 Video Stream (SRTP)
        V2<<->>V3: 🟣 Audio Stream (SRTP)
        V2<<->>V3: 🟣 Data Channel (SCTP over DTLS)
    end

---

---

Processus d'établissement de connexion

Séquence complète ICE (Interactive Connectivity Establishment)

sequenceDiagram
    participant V1 as 📺 V1 (Initiateur)
    participant API as 🔌 API
    participant STUN as 🎯 STUN/TURN
    participant V2 as 📺 V2 (Récepteur)

    Note over V1,V2: 1. Connexion à l'API WebSocket
    V1->>API: WebSocket Connect + Licensing
    V2->>API: WebSocket Connect + Licensing
    API->>V1: License validated
    API->>V2: License validated

    Note over V1,V2: 2. Découverte ICE - Local IPs
    V1->>V1: Collect Local IP addresses
    V2->>V2: Collect Local IP addresses

    Note over V1,V2: 3. Découverte ICE - STUN/TURN
    V1->>STUN: STUN Request
    STUN->>V1: Public IP + NAT type
    V2->>STUN: STUN Request  
    STUN->>V2: Public IP + NAT type

    opt TURN nécessaire
        V1->>STUN: TURN Allocation
        STUN->>V1: Relay IP allocated
        V2->>STUN: TURN Allocation
        STUN->>V2: Relay IP allocated
    end

    Note over V1,V2: 4. Échange des endpoints via API
    V1->>API: ICE Candidates (Local + Public + Relay)
    API->>V2: Forward ICE Candidates from V1
    V2->>API: ICE Candidates (Local + Public + Relay)
    API->>V1: Forward ICE Candidates from V2

    Note over V1,V2: 5. Établissement connexion P2P (ordre de priorité)

    rect rgb(240, 255, 240)
        Note over V1,V2: Tentative 1: IPs Locales
        V1->>V2: Connectivity Check (Local IP)
        V2->>V1: Connectivity Response
    end

    rect rgb(255, 248, 220)
        Note over V1,V2: Tentative 2: IPs Publiques (NAT)
        alt Échec Local IP
            V1->>V2: Connectivity Check (Public IP)
            V2->>V1: Connectivity Response
        end
    end

    rect rgb(255, 240, 240)
        Note over V1,V2: Tentative 3: Relay TURN
        alt Échec Public IP
            V1->>STUN: Relay via TURN
            STUN->>V2: Forward via TURN
            V2->>STUN: Response via TURN
            STUN->>V1: Forward response
        end
    end

    Note over V1,V2: 6. Connexion établie - Flux média
    V1<<->>V2: 🟣 Video/Audio/Data streams (SRTP/SCTP)

---

---

Types de connexions WebRTC

Scénario 1 : Connexion locale (même LAN)

graph LR
    subgraph LAN ["🏢 LAN Local"]
        V1["📺 V1"] <-.->|"🟣 Direct P2P<br/>Local IP<br/>Minimal latency"| V2["📺 V2"]
    end

    style V1 fill:#e1f5fe,color:black
    style V2 fill:#e1f5fe,color:black

Caractéristiques :

• Latence : < 1ms
• Bande passante : Maximale (limitée par switch local)
• Chiffrement : DTLS-SRTP
• Traversée : Aucune (communication directe)

---

Scénario 2 : Connexion publique (NAT traversal)

graph LR
    subgraph LAN1 ["🏢 LAN 1"]
        V1["📺 V1"]
        R1["🌐 Router"]
        V1 <-.-> R1
    end

    subgraph LAN2 ["🏢 LAN 2"]
        R2["🌐 Router"]
        V3["📺 V3"]
        R2 <-.-> V3  
    end

    R1 <-.->|"🟣 WebRTC P2P<br/>Public IPs<br/>NAT Traversal"| R2

    style R1 fill:#fff3e0,color:black
    style R2 fill:#fff3e0,color:black

Caractéristiques :

• Latence : 10-50ms (selon distance)
• Bande passante : Limitée par connexion Internet
• Chiffrement : DTLS-SRTP bout en bout
• Traversée : NAT automatique via ICE

---

Scénario 3 : Connexion relayée (TURN)

graph TB
    V1["📺 V1"] -.->|"🔵 Vers TURN"| TURN["🎯 TURN Relay"]
    TURN -.->|"🔵 Relay vers V3"| V3["📺 V3"]

    V1 <-.->|"🟣 Media via TURN<br/>Higher latency<br/>Reliable"| V3

    style TURN fill:#ffebee,color:black

Caractéristiques :

• Latence : 50-100ms (via serveur relay)
• Bande passante : Limitée par serveur TURN
• Chiffrement : DTLS-SRTP via relay
• Traversée : Forcée via serveur cloud

---

---

Configuration et ports réseau

Ports utilisés par protocole

Flux	Protocole	Port	Direction	Usage
Signalisation	HTTPS/WebSocket	TCP 443	Sortant	API, événements
STUN	STUN	UDP 443	Sortant	Découverte IP
TURN	TURN	TCP/UDP 443	Sortant	Serveur relay
WebRTC Media	SRTP	UDP Dynamique	Sortant/Entrant	Audio/Vidéo
WebRTC Data	SCTP	UDP Dynamique	Sortant/Entrant	Annotations

*Ports dynamiques : (configurable)

---

Algorithmiques de chiffrement

API Cyphers:

• TLS_AES_256_GCM_SHA384 (TLS 1.3 only)
• TLS_AES_128_GCM_SHA256 (TLS 1.3 only)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

WebRTC Cyphers:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

---

---

Qualité de service (QoS)

Priorités de trafic

Classe	Trafic	DSCP	Latence max	Gigue max
Temps réel	Audio	EF (46)	20ms	5ms
Vidéo	Vidéo	AF41 (34)	50ms	10ms
Interactif	Signalisation	AF31 (26)	100ms	20ms
Données	Partage écran	AF21 (18)	200ms	50ms

Configuration QoS recommandée

# Exemple configuration Cisco
class-map match-any VITRE-VOICE
  match dscp ef
  match protocol rtp audio

class-map match-any VITRE-VIDEO  
  match dscp af41
  match protocol rtp video

policy-map VITRE-QOS
  class VITRE-VOICE
    priority percent 20
  class VITRE-VIDEO
    bandwidth percent 60
  class class-default
    fair-queue

---

---

Monitoring et diagnostics

Métriques à surveiller

Réseau :

• Latence : < 50ms recommandé
• Gigue : < 10ms pour audio/vidéo
• Perte de paquets : < 0.1%
• Bande passante disponible : > 5 Mbps

Application :

• Qualité vidéo : Résolution, frame rate
• Qualité audio : Clarté, synchronisation
• Temps de connexion : < 5 secondes

Outils de diagnostic

• Tests intégrés : Disponibles dans l'interface admin
• Logs détaillés : Accessibles via le portail admin
• Métriques temps réel : Monitoring de session

✨ Une information manque ?
Ce centre d’aide évolue avec vos besoins.

Signalez-nous les termes, fonctionnalités ou usages à expliciter ou contactez le support pour un accompagnement personnalisé.

Vous rapprocher de ce qui compte. Nous enrichissons cette ressource ensemble.