WebRTC Network Architecture - la Vitre¶

✨ WebRTC Communication Architecture
This document details la Vitre's WebRTC architecture, peer-to-peer connection establishment mechanisms, and data flows between clients. Intended for technical teams to understand direct communications between Vitres.

Get closer, it changes everything.

General WebRTC Architecture¶

Network Zones Overview¶

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

Detailed Communication Flows¶

Flow A: HTTPS - WebSocket (Signaling)¶

Protocol: HTTPS - WebSocket - TCP 443

Role: Signaling and event management

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: WebSocket Connection Establishment
    V1->>API: HTTPS WebSocket Connection
    V2->>API: HTTPS WebSocket Connection
    V3->>API: HTTPS WebSocket Connection

    Note over V1,API: Signaling and Events
    API->>V1: Licensing validation
    API->>V2: Event notifications
    API->>V3: Guest join, Settings changed, Space change

    Note over V1,API: Session Metadata Exchange
    V1->>API: Session metadata
    API->>V2: Forward session data
    API->>V3: Forward session data

Managed Events:

Licensing: User license validation
Event notifications: Real-time notifications
Guest join: New participant arrival
Settings changed: Settings modification
Space change: Virtual space change

Flow B: STUN/TURN (Network Discovery)¶

Protocol: STUN/TURN - TCP/UDP 443

Role: Public IP address discovery and relay if necessary

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: ICE Discovery Phase
    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: TURN Activation if Necessary
    alt NAT Traversal Impossible
        V1->>STUN: TURN Allocation Request
        STUN->>V1: TURN Relay IP allocated
    end

Discovered Information:

Local IPs: Local IP addresses of Vitres
Router IPs: Public IP addresses (if NAT traversal possible)
Relay IPs: Relay IP addresses (if NAT traversal impossible)

Flow C: WebRTC Media (Multimedia Data)¶

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

Role: Encrypted transport of audio/video streams in peer-to-peer

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

    Note over V1,V3: Encrypted WebRTC Communications

    rect rgb(255, 240, 245)
        Note over V1,V2: Local LAN 1 Connection
        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: Inter-LAN Connection
        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: Inter-LAN Connection
        V2<<->>V3: 🟣 Video Stream (SRTP)
        V2<<->>V3: 🟣 Audio Stream (SRTP)
        V2<<->>V3: 🟣 Data Channel (SCTP over DTLS)
    end

Connection Establishment Process¶

Complete ICE Sequence (Interactive Connectivity Establishment)¶

sequenceDiagram
    participant V1 as 📺 V1 (Initiator)
    participant API as 🔌 API
    participant STUN as 🎯 STUN/TURN
    participant V2 as 📺 V2 (Receiver)

    Note over V1,V2: 1. WebSocket API Connection
    V1->>API: WebSocket Connect + Licensing
    V2->>API: WebSocket Connect + Licensing
    API->>V1: License validated
    API->>V2: License validated

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

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

    opt TURN Required
        V1->>STUN: TURN Allocation
        STUN->>V1: Relay IP allocated
        V2->>STUN: TURN Allocation
        STUN->>V2: Relay IP allocated
    end

    Note over V1,V2: 4. Endpoint Exchange 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. P2P Connection Establishment (Priority Order)

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

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

    rect rgb(255, 240, 240)
        Note over V1,V2: Attempt 3: TURN Relay
        alt Public IP Failed
            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. Connection Established - Media Flow
    V1<<->>V2: 🟣 Video/Audio/Data streams (SRTP/SCTP)

WebRTC Connection Types¶

Scenario 1: Local Connection (Same LAN)¶

graph LR
    subgraph LAN ["🏢 Local LAN"]
        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

Characteristics:

Latency: < 1ms
Bandwidth: Maximum (limited by local switch)
Encryption: DTLS-SRTP
Traversal: None (direct communication)

Scenario 2: Public Connection (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

Characteristics:

Latency: 10-50ms (depending on distance)
Bandwidth: Limited by Internet connection
Encryption: End-to-end DTLS-SRTP
Traversal: Automatic NAT via ICE

Scenario 3: Relayed Connection (TURN)¶

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

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

    style TURN fill:#ffebee,color:black

Characteristics:

Latency: 50-100ms (via relay server)
Bandwidth: Limited by TURN server
Encryption: DTLS-SRTP via relay
Traversal: Forced via cloud server

Network Configuration and Ports¶

Ports Used by Protocol¶

Flow	Protocol	Port	Direction	Usage
Signaling	HTTPS/WebSocket	TCP 443	Outbound	API, events
STUN	STUN	UDP 443	Outbound	IP discovery
TURN	TURN	TCP/UDP 443	Outbound	Relay server
WebRTC Media	SRTP	Dynamic UDP	Outbound/Inbound	Audio/Video
WebRTC Data	SCTP	Dynamic UDP	Outbound/Inbound	Annotations

*Dynamic ports: (configurable)

Encryption Algorithms¶

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

Quality of Service (QoS)¶

Traffic Priorities¶

Class	Traffic	DSCP	Max Latency	Max Jitter
Real-time	Audio	EF (46)	20ms	5ms
Video	Video	AF41 (34)	50ms	10ms
Interactive	Signaling	AF31 (26)	100ms	20ms
Data	Screen sharing	AF21 (18)	200ms	50ms

Recommended QoS Configuration¶

# Cisco configuration example
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 and Diagnostics¶

Metrics to Monitor¶

Network:

Latency: < 50ms recommended
Jitter: < 10ms for audio/video
Packet loss: < 0.1%
Available bandwidth: > 5 Mbps

Application:

Video quality: Resolution, frame rate
Audio quality: Clarity, synchronization
Connection time: < 5 seconds

Diagnostic Tools¶

Built-in tests: Available in admin interface
Detailed logs: Accessible via admin portal
Real-time metrics: Session monitoring

✨ Missing information?
This Help Center evolves with your needs.

Let us know which terms, features, or use cases should be clarified, or contact support for personalized assistance.

Bringing you closer to what matters. We are enriching this resource together.