Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
AV-Chaos-Monkey — Chaos Monkey mais pour les tests audio vidéo (webRTC et UDP) | Kitploit
Outils/GitHubGitHub/mdsadiqmd/av-chaos-monkey
Sécurité WebSécurité RéseauTests d'IntrusionSécurité CloudDevSecOpsIngénierie du Chaos
GitHubmdsadiqmd/av-chaos-monkey

AV-Chaos-Monkey

Chaos Monkey mais pour les tests audio vidéo (webRTC et UDP)

Voir le dépôt
526il y a 6 moisVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

AV Chaos Monkey

Plateforme d'ingénierie du chaos distribuée pour les tests de charge des systèmes de visioconférence. Simule plus de 1500 participants WebRTC avec des flux H.264/Opus et injecte des pics de chaos réseau pour valider la résilience du système dans des conditions dégradées.

Architecture

image
  1. Pipeline de traitement média :

    • FFmpeg convertit la vidéo d'entrée en H.264 Annex-B et Ogg/Opus au démarrage
    • NAL Reader analyse le flux H.264 (SPS/PPS/IDR/Slices)
    • Opus Reader extrait des trames audio de 20 ms du conteneur Ogg
    • Les trames sont mises en cache en mémoire, partagées entre tous les participants (zero-copy)
    • Réduit l'utilisation du processeur d'environ 90 % par rapport au codage par participant
  2. Plan de contrôle :

    • Serveur HTTP (:8080) gère le cycle de vie des tests via l'API REST
    • Spike Scheduler distribue les événements de chaos (pair/aléatoire/avant/arrière/héritage)
    • Network Degrader applique le chaos : perte de paquets (1-25 %), gigue (10-50 ms), réduction de débit (30-80 %), chute de trames (10-60 %)
    • La configuration de chaos chargée est appliquée au pool de participants
  3. Pool de participants :

    • Partitionnement automatique entre les pods en utilisant : participant_id % total_partitions = partition_id
    • Chaque participant génère des flux RTP (PT=96 vidéo, PT=111 audio)
    • L'identifiant du participant est intégré dans l'en-tête d'extension RTP (ID=1)
  • Taille du pool : 1-100 (local), 100-500 (Docker), 500-1500 (Kubernetes)
  • Auto-configuration Kubernetes :

    • Les pods détectent automatiquement l'ID de partition à partir du nom du pod : orchestrator-3 → PARTITION_ID=3
    • Allocation de ports : base_port + (partition_id × 10000) + participant_index
    • Exemple : Partition 0 utilise 5000-14999, Partition 1 utilise 15000-24999
    • StatefulSet avec 10 réplicas, chacun gère environ 150 participants
    • Ressources : 1-4 CPU, 2-4 Go de mémoire par pod
    • Configuration automatique en fonction des spécifications de la machine hôte
  • Chaîne de relais UDP (Kubernetes uniquement) :

    root@kitploit:~
    Pods Orchestrator (10×) → UDP :5000 → pod udp-relay (Python)
    → TCP avec préfixe de longueur :5001 → kubectl port-forward 15001:5001
    → tools/udp-relay (Go) → UDP :5002 → Votre récepteur
    
    • Pourquoi : kubectl port-forward ne supporte que TCP, pas UDP
    • Relais dans le cluster : script Python qui agrège l'UDP de tous les pods et le diffuse en TCP avec un préfixe de longueur de 2 octets
    • Relais local : outil Go qui convertit le flux TCP en paquets UDP
    • Agrège les flux de 1500 participants en une seule connexion
  • Infrastructure WebRTC :

    • Coturn StatefulSet : 3 réplicas initiaux, HPA échelle de 1 à 10 en fonction de la charge (~500 participants/réplica)
    • Service coturn-lb : Répartit la charge du trafic TURN entre les réplicas
    • webrtc-connector : Couche proxy optionnelle (Deployment + HPA 2-10 réplicas), gère la signalisation SDP
    • Mode Docker : Conteneur Coturn unique pour les tests locaux
    • Ports : 3478 (TURN), 49152-65535 (plage de relais)
    • Identifiants : webrtc/webrtc123
  • Intégration client :

    • Récepteur UDP : Reçoit le flux RTP agrégé de tous les participants via la chaîne de relais
    • Récepteur WebRTC : Établit des connexions WebRTC 1:1 via l'échange SDP par les serveurs TURN
    • Les deux transmettent à votre système d'appel vidéo testé (SFU/MCU/Mesh)
  • Pile d'observabilité (optionnelle) :

    • Prometheus : Interroge le point de terminaison /metrics de tous les pods orchestrator toutes les 5 secondes
    • Grafana : Visualise les métriques via un tableau de bord préconfiguré (admin/admin)
    • Métriques exposées : nombre de participants, paquets envoyés, octets envoyés, pics actifs, % de perte de paquets, gigue en ms, score MOS
    • Accès : Prometheus sur :30090, Grafana sur :30030 (NodePort)
    • Les pods Orchestrator sont annotés pour l'auto-découverte : prometheus.io/scrape: "true"
  • Concepts fondamentaux

    Simulation de participant

    Chaque participant virtuel génère des flux média réels :

    • Vidéo : Unités NAL H.264 provenant de fichiers vidéo réels, packetisées selon la RFC 6184
    • Audio : Trames Opus provenant de conteneurs Ogg, packetisées selon la RFC 7587
    • RTP : En-têtes conformes aux normes avec extensions d'identifiant de participant
    • Temporisation : Temporisation précise à la trame (30 ips vidéo, paquets audio de 20 ms)

    Injection de chaos

    Cinq types de pics simulent des conditions réseau réelles :

    • Perte de paquets : Supprime les paquets RTP au niveau applicatif (1-100 %)
    • Gigue réseau : Ajoute une variation de latence (latence de base + gigue gaussienne)
    • Réduction de débit : Limite le codage vidéo (30-80 % de réduction)
    • Chute de trames : Saute des trames vidéo (10-60 % de taux de chute)
    • Limitation de bande passante : Plafonne le débit total

    Stratégies de distribution

    Les pics sont répartis sur la durée du test selon des stratégies configurables :

    • Uniforme : Espacement uniforme avec gigue (charge prévisible)
    • Aléatoire : Temporisation imprévisible (chaos réaliste)
    • Anticipée : Pics denses au début (test de rétablissement)
    • Retardée : Ligne de base puis chaos (test comparatif)
    • Héritage : Tic à intervalle fixe (injection en cours d'exécution)

    Partitionnement

    Les déploiements Kubernetes utilisent le partitionnement des participants pour la mise à l'échelle horizontale :

    • Chaque pod gère participant_id % total_partitions == partition_id
    • Allocation de ports : base_port + (partition_id * 10000) + participant_index
    • Répartition automatique de la charge sur 1 à 10 pods
    • Évolue jusqu'à 1500+ participants (150 par pod)

    Exécution du système

    1. Développement local (Go natif)

    Idéal pour : Développement, débogage, tests à petite échelle (1-100 participants)

    root@kitploit:~
    # Démarrer l'orchestrateur
    go run cmd/main.go
    
    # Dans un autre terminal : Démarrer le récepteur UDP
    go run examples/go/udp_receiver.go 5002
    
    # Modifier config/config.json pour définir num_participants: 10
    # Lancer le test de chaos
    go run tools/chaos-test/main.go -config config/config.json
    

    Ce qui se passe :

    • Processus d'orchestrateur unique sur :8080
    • Les participants envoient UDP vers 127.0.0.1:5002
    • Les pics de chaos sont injectés via l'API HTTP
    • Métriques en temps réel affichées toutes les 2 secondes

    Configuration (config/config.json) :

    root@kitploit:~
    {
      "base_url": "http://localhost:8080",
      "media_path": "public/rick-roll.mp4",
      "num_participants": 10,
      "duration_seconds": 300,
      "spikes": {
        "count": 20,
        "interval_seconds": 5,
        "types": { "rtp_packet_loss": {...}, "network_jitter": {...} }
      },
      "spike_distribution": {
        "strategy": "random",
        "min_spacing_seconds": 5,
        "jitter_percent": 15
      }
    }
    

    2. Docker Compose (conteneurisé)

    Idéal pour : Tests isolés, CI/CD, tests à moyenne échelle (100-500 participants)

    Prérequis :

    • Docker Desktop avec allocation mémoire de 8 à 16 Go
    • docker-compose installé
    root@kitploit:~
    # Construire et démarrer le conteneur orchestrateur
    ./scripts/start_everything.sh build
    
    # Dans un autre terminal : Démarrer le récepteur UDP
    go run examples/go/udp_receiver.go 5002
    
    # Modifier config/config.json pour définir num_participants: 100
    # Lancer le test de chaos (cible le conteneur)
    go run tools/chaos-test/main.go -config config/config.json
    

    Limites de ressources (modifier docker-compose.yaml) :

    root@kitploit:~
    services:
      orchestrator:
        deploy:
          resources:
            limits:
              cpus: "14.0"
              memory: 6G  # Augmenter pour plus de participants
    

    Guide de mise à l'échelle :

    Mémoire DockerParticipants maxCœurs CPU
    8 Go~1004
    16 Go~2508
    24 Go~40012
    32 Go~50014

    3. Kubernetes avec Nix (échelle de production)

    Idéal pour : Tests à grande échelle (500-1500 participants), mise à l'échelle horizontale, validation de production

    Prérequis :

    • Nix avec les flakes activées
    • Docker Desktop ou cluster kind
    • kubectl configuré

    Étape 1 : Entrer dans l'environnement Nix

    root@kitploit:~
    # Nix fournit : Go, Docker, kubectl, kind, ffmpeg
    nix develop
    
    # Ou utiliser direnv pour l'activation automatique
    echo "use flake" > .envrc
    direnv allow
    

    Étape 2 : Déployer sur Kubernetes

    root@kitploit:~
    # Déploiement automatique avec des paramètres optimaux (détecte les ressources système)
    ./scripts/start_everything.sh run -config config/config.json
    
    # Ou spécifier des fichiers média personnalisés
    ./scripts/start_everything.sh run --media=path/to/video.mp4 -config config/config.json
    

    Ce qui se passe :

    1. Construit l'image Docker avec la chaîne d'outils Go fournie par Nix
    2. Crée/utilise un cluster kind
    3. Déploie un StatefulSet avec 10 pods orchestrator
    4. Déploie le pod de relais UDP
    5. Configure kubectl port-forward pour le relais UDP
    6. Démarre le relais local TCP→UDP
    7. Exécute le test de chaos sur tous les pods

    Étape 3 : Recevoir le flux UDP agrégé

    Option A : Récepteur UDP (recommandé pour Kubernetes)

    root@kitploit:~
    # Reçoit le flux agrégé des 1500 participants
    go run ./examples/go/udp_receiver.go 5002
    

    Option B : Récepteur WebRTC (plusieurs participants)

    root@kitploit:~
    # Se connecte à jusqu'à 150 participants via WebRTC
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150
    

    Flux de l'architecture :

    root@kitploit:~
    1500 Participants répartis sur 10 pods
      → Chaque pod : 150 participants
      → Partitionnement par participant_id % 10
      → Tous envoient UDP vers udp-relay:5000
      → Relais UDP agrège → TCP :5001
      → kubectl port-forward 15001:5001
      → Relais local convertit TCP → UDP :5002
      → Votre récepteur reçoit les 1500 flux
    

    Remarque : Le script start_everything.sh configure automatiquement :

    • kubectl port-forward (udp-relay 15001:5001)
    • Relais local TCP→UDP (tools/udp-relay)
    • Vous n'avez besoin que d'exécuter le récepteur

    Configuration manuelle de Kubernetes

    root@kitploit:~
    # Construire et charger l'image
    docker build -t chaos-monkey-orchestrator:latest .
    kind load docker-image chaos-monkey-orchestrator:latest
    
    # Déployer
    kubectl apply -f k8s/orchestrator/orchestrator.yaml
    kubectl apply -f k8s/udp-relay/udp-relay.yaml
    
    # Attendre les pods
    kubectl wait --for=condition=ready pod -l app=orchestrator --timeout=300s
    
    # Port-forward pour le relais UDP
    kubectl port-forward udp-relay 15001:5001 &
    
    # Démarrer le relais local TCP→UDP
    go run tools/udp-relay/main.go &
    
    # Dans un autre terminal : Démarrer le récepteur
    go run ./examples/go/udp_receiver.go 5002
    
    # Dans un autre terminal : Lancer le test de chaos
    go run tools/chaos-test/main.go -config config/config.json
    

    Nettoyage

    root@kitploit:~
    # Supprimer les ressources Kubernetes
    ./scripts/cleanup.sh
    
    # Ou supprimer tout le cluster
    kind delete cluster --name av-chaos-monkey
    

    Compilations multi-plateformes avec Nix

    root@kitploit:~
    # Compiler pour Linux x86_64 (le plus courant)
    nix build .#packages.x86_64-linux.av-chaos-monkey
    
    # Compiler pour ARM64 (Raspberry Pi, AWS Graviton)
    nix build .#packages.aarch64-linux.av-chaos-monkey
    
    # Compiler pour macOS Intel
    nix build .#packages.x86_64-darwin.av-chaos-monkey
    
    # Compiler pour macOS Apple Silicon
    nix build .#packages.aarch64-darwin.av-chaos-monkey
    
    # Emplacement du binaire
    ./result/bin/main
    

    Référence de l'API

    Cycle de vie du test

    root@kitploit:~
    # Créer un test
    POST /api/v1/test/create
    {
      "test_id": "optional_id",
      "num_participants": 100,
      "video": {...},
      "audio": {...},
      "duration_seconds": 600,
      "spikes": [...],
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15
      }
    }
    
    # Démarrer le test
    POST /api/v1/test/{test_id}/start
    
    # Obtenir les métriques
    GET /api/v1/test/{test_id}/metrics
    
    # Arrêter le test
    POST /api/v1/test/{test_id}/stop
    

    Signalisation WebRTC

    root@kitploit:~
    # Obtenir l'offre SDP
    GET /api/v1/test/{test_id}/sdp/{participant_id}
    
    # Définir la réponse SDP
    POST /api/v1/test/{test_id}/sdp/{participant_id}
    {"sdp_answer": "v=0..."}
    

    Injection de chaos

    root@kitploit:~
    # Injecter un pic
    POST /api/v1/test/{test_id}/spike
    {
      "spike_id": "unique_id",
      "type": "rtp_packet_loss",
      "duration_seconds": 30,
      "participant_ids": [1001, 1002],
      "params": {"loss_percentage": "15"}
    }
    

    Configuration

    Types de pics

    TypeParamètresEffet
    rtp_packet_lossloss_percentage (0-100)Supprime les paquets au niveau RTP
    network_jitterbase_latency_ms, jitter_std_dev_msAjoute une variation de latence
    bitrate_reducenew_bitrate_kbpsLimite le codage vidéo
    frame_dropdrop_percentage (0-100)Saute des trames vidéo
    bandwidth_limitbandwidth_kbpsPlafonne le débit total

    Configuration de distribution

    root@kitploit:~
    {
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15,
        "respect_min_offset": true
      }
    }
    

    Intégration client

    Récepteur UDP (Go)

    root@kitploit:~
    # Récepteur fourni avec analyse RTP
    go run examples/go/udp_receiver.go 5002
    

    Sortie :

    root@kitploit:~
    Listening for RTP packets on UDP port 0.0.0.0:5002
    Packet #100 from 127.0.0.1:xxxxx:
      Participant ID: 1001
      Payload Type: 96 (H.264 video)
      Sequence: 1234
      Timestamp: 90000
      SSRC: 1001000
      Payload Size: 1200 bytes
    
    ═══════════════════════════════════════════════════════════
                        STATISTIQUES DES PAQUETS                   
    ═══════════════════════════════════════════════════════════
    Durée : 60s
    Paquets totaux : 180000 (3000 pkt/s)
    Octets totaux : 450 Mo (60 Mb/s)
    
    Répartition par type de média :
      Vidéo (H.264) : 120000 paquets (66,7 %)
      Audio (Opus)  :  60000 paquets (33,3 %)
    
    Flux uniques (SSRC) : 1500
    Participants uniques : 1500
    

    Récepteur WebRTC (Go)

    root@kitploit:~
    # Participant unique
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id>
    
    # Participants multiples (jusqu'à 150)
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150
    
    # Exemple avec un ID de test réel
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 chaos_test_1770831684 150
    

    Remarque : WebRTC nécessite des connexions 1:1. Pour Kubernetes, utilisez le récepteur UDP qui agrège automatiquement tous les participants.

    Intégration personnalisée

    Format du paquet RTP :

    root@kitploit:~
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           timestamp                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           synchronization source (SSRC) identifier            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Extension ID=1 | Length=4    |    Participant ID (uint32)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         H.264/Opus Payload                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    Types de charge utile :

    • 96 : Vidéo H.264 (RFC 6184)
    • 111 : Audio Opus (RFC 7587)

    Extraction de l'identifiant participant :

    root@kitploit:~
    // Bit d'extension défini ?
    if (packet[0] & 0x10) != 0 {
        offset := 12 + int(packet[0]&0x0F)*4  // Ignorer CSRC
        extID := binary.BigEndian.Uint16(packet[offset:])
        if extID == 1 {
            participantID := binary.LittleEndian.Uint32(packet[offset+4:])
        }
    }
    

    Performances

    Besoins en ressources

    ParticipantsMémoireCPUBande passante
    1002 Go2 cœurs250 Mb/s
    5006 Go8 cœurs1,2 Gb/s
    100012 Go16 cœurs2,5 Gb/s
    150018 Go24 cœurs3,7 Gb/s

    Mise à l'échelle Kubernetes

    • Auto-scaling : Calcule le nombre optimal de pods en fonction du nombre de participants
    • Capacité d'un pod : 150 participants par pod (configurable)
    • Nombre maximum de pods : 10 (limite du StatefulSet)
    • Plage de ports : 10 000 ports par partition

    Débit

    Par participant (1280x720@30 ips + Opus) :

    • Vidéo : ~2,5 Mb/s (H.264)
    • Audio : ~128 Kb/s (Opus)
    • Total : ~2,6 Mb/s
    • Paquets : ~90 vidéo + 50 audio = 140 pkt/s

    Surveillance

    Métriques Prometheus

    root@kitploit:~
    # Exposées sur le point de terminaison /metrics
    av_chaos_monkey_participants_total
    av_chaos_monkey_packets_sent_total
    av_chaos_monkey_bytes_sent_total
    av_chaos_monkey_spikes_active
    av_chaos_monkey_packet_loss_percent
    av_chaos_monkey_jitter_ms
    

    Tableau de bord Grafana

    root@kitploit:~
    # Mode Docker : Démarrer la pile de surveillance
    docker-compose --profile monitoring up
    
    # Mode Kubernetes : Déployer la surveillance
    kubectl apply -f k8s/monitoring/prometheus-rbac.yaml
    kubectl apply -f k8s/monitoring/prometheus.yaml
    kubectl apply -f k8s/monitoring/grafana.yaml
    
    # Accéder à Grafana
    # Docker : http://localhost:3000
    # Kubernetes : http://localhost:30030 (NodePort)
    # Identifiants par défaut : admin/admin
    
    # Accéder à Prometheus
    # Docker : http://localhost:9091
    # Kubernetes : http://localhost:30090 (NodePort)
    

    Auto-découverte Kubernetes :

    • Les pods Orchestrator sont annotés avec prometheus.io/scrape: "true"
    • Prometheus interroge /metrics de tous les pods toutes les 5 secondes
    • Grafana préconfiguré avec la source de données Prometheus
    • Tableau de bord provisionné automatiquement au démarrage

    Statistiques en temps réel

    root@kitploit:~
    # Obtenir les métriques du test
    curl http://localhost:8080/api/v1/test/{test_id}/metrics | jq
    
    # Sortie
    {
      "aggregate": {
        "total_frames_sent": 45000,
        "total_packets_sent": 180000,
        "total_bitrate_kbps": 250000,
        "avg_jitter_ms": 12.5,
        "avg_packet_loss": 2.3,
        "avg_mos_score": 4.1
      }
    }
    

    Dépannage

    Aucun paquet UDP reçu

    root@kitploit:~
    # Vérifier la configuration de la cible UDP
    kubectl logs orchestrator-0 | grep "UDP transmission enabled"
    
    # Vérifier que le relais UDP est en cours d'exécution
    kubectl get pod udp-relay
    
    # Vérifier le port-forward
    ps aux | grep "kubectl port-forward"
    
    # Tester la connectivité UDP
    nc -u -z localhost 5002
    

    Échec de connexion WebRTC

    root@kitploit:~
    # Vérifier le serveur TURN
    kubectl get svc coturn-lb
    
    # Vérifier les candidats ICE
    kubectl logs orchestrator-0 | grep "ICE"
    
    # Tester la connectivité TURN
    turnutils_uclient -v -u webrtc -w webrtc123 <turn-server>:3478
    

    Utilisation mémoire élevée

    root@kitploit:~
    # Vérifier le nombre de participants par pod
    kubectl exec orchestrator-0 -- curl -s http://localhost:8080/api/v1/test/{test_id}/metrics | jq '.participants | length'
    
    # Réduire les participants ou augmenter le nombre de pods
    go run tools/k8s-start/main.go -replicas 10 -participants 1000
    
    # Augmenter la mémoire Docker (Docker Desktop)
    # Paramètres → Ressources → Mémoire → 16 Go
    

    Perte de paquets dans le récepteur UDP

    Un seul socket UDP ne peut pas gérer plus de 3 000 flux simultanés sans débordement du tampon du noyau. Solutions :

    • Utiliser le relais UDP (agrège avant transmission)
    • Augmenter le tampon du socket : setsockopt(SO_RCVBUF, 8 Mo)
    • Accepter la perte de base comme artefact de mesure

    Licence

    Licence BSD 3-Clause

    Contribution

    Les contributions sont les bienvenues ! Domaines clés :

    • Types de pics supplémentaires (limitation CPU, pression mémoire)
    • Stratégies de distribution supplémentaires (vague, rafale)
    • Métriques améliorées (calcul MOS, retour RTCP)
    • Bibliothèques client (Python, Rust, TypeScript)

    Références

    • RFC 3550 - RTP : Protocole de transport pour les applications en temps réel
    • RFC 6184 - Format de charge utile RTP pour la vidéo H.264
    • RFC 7587 - Format de charge utile RTP pour Opus
    • Spécification WebRTC
    Télécharger l’outil