WebRTC à grande échelle : comment Mandraki gère les appels de groupe massifs

L’appel vidéo de groupe est l’une de ces fonctionnalités qui paraissent simples pour les utilisateurs mais qui impliquent une complexité d’ingénierie considérable sous la surface. Un appel un-à-un est relativement simple — deux pairs échangent des médias directement. Mais dès que vous ajoutez un troisième participant, les décisions architecturales se multiplient, et au moment où vous atteignez cinquante participants répartis sur plusieurs sessions simultanées, vous avez affaire à un problème de systèmes distribués véritablement difficile.

Cet article explique comment l’architecture média en temps réel de Mandraki est conçue pour une échelle massive — sans compromis sur le chiffrement ou la souveraineté des données.

Pourquoi pas pair-à-pair

Dans une topologie pair-à-pair en maillage, chaque participant envoie son flux média directement à tous les autres participants. Pour un appel à N participants, chaque personne envoie N-1 flux et reçoit N-1 flux. Le nombre total de connexions est N*(N-1), et l’exigence de bande passante montante de chaque participant croît linéairement avec le nombre de participants.

Cela fonctionne convenablement pour trois ou quatre participants avec de bonnes connexions internet. Au-delà, cela s’effondre. Un participant avec un débit montant de 5 Mbps envoyant un flux vidéo de 1,5 Mbps ne peut servir que trois pairs avant de saturer sa connexion montante. L’utilisation CPU pour encoder plusieurs flux grimpe rapidement. Et les conditions réseau entre des paires arbitraires de participants sont imprévisibles.

La topologie en maillage est élégante en théorie et impraticable à grande échelle.

L’approche SFU

Un Selective Forwarding Unit (SFU) se trouve au centre de la topologie d’appel. Chaque participant envoie un seul flux montant au SFU. Le SFU transfère ensuite ce flux à tous les autres participants. La bande passante montante du participant est constante, indépendamment du nombre de participants — ils envoient toujours un seul flux. Le SFU gère la diffusion.

La partie « sélective » est importante. Le SFU ne diffuse pas simplement chaque flux à chaque participant. Il prend des décisions de transfert intelligentes en fonction des conditions réseau, de la visibilité des participants et de la bande passante disponible. Si la connexion descendante d’un participant est contrainte, le SFU peut transférer des couches de résolution inférieure. Si un participant n’est pas actuellement visible dans l’interface (par exemple, dans un grand appel où seul le locuteur actif est affiché en pleine taille), le SFU peut réduire ou interrompre le transfert de son flux.

C’est fondamentalement différent d’une Multipoint Control Unit (MCU), qui décode tous les flux entrants, les compose en un seul flux mixte, le réencode et envoie le composite à chaque participant. Les MCU sont gourmandes en CPU, ajoutent une latence d’encodage, et — élément crucial — nécessitent un accès aux médias en clair, ce qui les rend incompatibles avec le chiffrement de bout en bout.

Un SFU transfère des paquets chiffrés sans les décoder. C’est ce qui rend possible le chiffrement de bout en bout basé sur SFrame dans un appel de groupe. Le SFU achemine du texte chiffré.

L’architecture SFU de Mandraki

Mandraki utilise une bibliothèque SFU open-source intégrée directement dans notre infrastructure. Plutôt que de nous appuyer sur un serveur média tiers monolithique, nous intégrons le SFU comme une bibliothèque au sein de notre propre base de code. Cela nous donne un contrôle total sur la façon dont il s’intègre avec notre couche applicative, notre protocole de signalisation et notre système d’authentification.

Le SFU utilise une architecture multi-workers. Chaque worker est un processus natif distinct qui gère le routage média réel à une performance quasi native. La couche de coordination gère les workers, les transports et s’interface avec notre logique applicative. Cette séparation maintient le chemin média rapide tandis que le chemin de contrôle reste flexible.

Le SFU prend en charge le simulcast et SVC (Scalable Video Coding), qui sont essentiels pour le transfert adaptatif en bande passante. Les navigateurs des participants encodent leur vidéo à plusieurs niveaux de qualité simultanément. Le SFU sélectionne le niveau approprié pour chaque destinataire en fonction de sa bande passante disponible et du contexte de l’interface.

Mise à l’échelle vers des centaines de sessions

Pour les déploiements à grande échelle, l’architecture est conçue autour d’une mise à l’échelle horizontale avec un routage de session intelligent.

Déploiement SFU multi-instances. Plusieurs instances SFU s’exécutent à travers les zones de disponibilité. Chaque instance enregistre sa capacité auprès d’une couche de coordination. Lorsqu’un nouvel appel est créé, le système sélectionne l’instance SFU avec le plus de capacité disponible. Les participants au même appel sont toujours acheminés vers la même instance SFU pour un routage média optimal.

Parallélisme au niveau worker. Chaque processus SFU engendre plusieurs workers natifs — correspondant typiquement au nombre de cœurs CPU disponibles. Chaque worker peut gérer plusieurs salles d’appel indépendamment. Cela signifie qu’un seul serveur SFU avec 16 cœurs peut gérer efficacement des dizaines d’appels simultanés, chacun avec jusqu’à 50 participants.

Transfert adaptatif en bande passante. Pour les appels avec de nombreux participants, plusieurs optimisations s’activent automatiquement. La détection du locuteur actif réduit le nombre de flux haute qualité à transférer. La sélection de couche simulcast devient plus agressive, favorisant les couches inférieures pour les participants non visibles. Le repli audio uniquement est disponible pour les participants ayant une bande passante sévèrement contrainte.

Déploiement multi-zones européen. L’infrastructure de Mandraki s’exécute à travers plusieurs zones de disponibilité au sein de l’UE sur une infrastructure hyperscale européenne. Les instances SFU sont déployées à proximité des utilisateurs, réduisant la latence aller-retour pour les paquets médias. Tout le routage média reste à l’intérieur des frontières européennes — aucun média n’est jamais relayé via une infrastructure non européenne.

Traversée NAT

La plus grande force de WebRTC — la connectivité pair-à-pair directe — est aussi son plus grand défi. La plupart des appareils se trouvent derrière des pare-feu NAT (Network Address Translation) qui empêchent les connexions entrantes directes. WebRTC utilise ICE (Interactive Connectivity Establishment) pour découvrir un chemin réseau viable, en essayant successivement la connexion directe, la connexion médiée par STUN et le relais TURN.

Mandraki exploite des serveurs TURN dédiés aux côtés de l’infrastructure SFU. TURN agit comme un relais de dernier recours — lorsqu’un participant ne peut pas établir de connexion directe au SFU (en raison de pare-feu restrictifs, de NAT symétrique ou de serveurs proxy d’entreprise), les médias transitent par le serveur TURN. Cela ajoute une certaine latence mais garantit la connectivité.

Les serveurs TURN prennent en charge à la fois UDP et TCP, ainsi que TLS pour les environnements qui n’autorisent que le trafic HTTPS. Comme tout le reste dans notre pile, ils s’exécutent entièrement au sein de l’UE.

Chiffrement de bout en bout à grande échelle

L’architecture SFU est spécifiquement choisie parce qu’elle préserve la compatibilité avec le chiffrement de bout en bout. En utilisant WebRTC Encoded Transforms et le protocole SFrame (RFC 9605), les trames médias sont chiffrées sur l’appareil de l’expéditeur avant d’atteindre le SFU. Le SFU transfère les trames chiffrées aux destinataires, qui les déchiffrent localement.

Le SFU n’a jamais accès aux médias en clair. Il achemine du texte chiffré. Cela signifie que même à grande échelle — avec des dizaines de participants et plusieurs appels simultanés — les garanties de chiffrement tiennent. Aucun serveur dans notre infrastructure ne voit ou ne traite jamais d’audio ou de vidéo non chiffrés.

C’est un choix architectural fondamental. De nombreuses plateformes revendiquent un chiffrement mais utilisent des architectures basées sur MCU qui nécessitent un décodage côté serveur. L’approche SFU de Mandraki signifie que le chiffrement n’est pas qu’une fonctionnalité — c’est une garantie structurelle.

Supervision et fiabilité

Les problèmes WebRTC sont notoirement difficiles à diagnostiquer. Nous collectons une télémétrie côté client comprenant les transitions d’état de connexion ICE, les types de paires de candidats sélectionnés, les estimations de temps aller-retour, les taux de perte de paquets et les estimations de bande passante. Ces métriques sont regroupées par lots et envoyées à notre point de terminaison de télémétrie pour agrégation.

Côté serveur, le SFU journalise les événements de transport, le cycle de vie des producteurs et des consommateurs, et l’estimation de bande passante. Combiné à la télémétrie côté client, cela fournit une vue complète de la qualité d’appel qui nous permet d’identifier et de traiter les problèmes de manière systématique.

La communication en temps réel à grande échelle est un défi d’ingénierie profond. Nous continuons d’investir dans l’infrastructure média qui rend les appels de Mandraki fiables, à faible latence et chiffrés de bout en bout — le tout au sein d’une infrastructure européenne souveraine.