WebRTC, SFU et codecs vocaux : le guide
Comment WebRTC transporte l'audio, comment Opus compresse la voix et quand la vidéo de groupe exige un SFU. Guide développeur avec l'architecture de Voxal.
WebRTC transporte l'audio et la vidéo entre navigateurs, un codec comme Opus compresse la voix pour qu'elle passe sur le réseau, et un Selective Forwarding Unit (SFU) est un serveur qui transmet la vidéo de chaque participant à tous les autres dans les appels de plus grande taille. Ces trois briques expliquent l'essentiel de ce qui se passe entre un microphone et un haut-parleur distant.
Ce guide s'adresse aux développeurs et aux curieux qui veulent comprendre la mécanique : signalisation, ICE, STUN et TURN, RTP, Opus, et le compromis entre un maillage peer-to-peer et un SFU. Il se termine sur la façon dont Voxal les combine : la voix reste en peer-to-peer, tandis que la caméra et le partage d'écran peuvent passer par un SFU. Si vous voulez simplement comprendre le concept, commencez par qu'est-ce que le chat vocal peer-to-peer.
1. Qu'est-ce que WebRTC ?
WebRTC est un ensemble de standards et d'API de navigateur dédiés à la communication audio, vidéo et de données en temps réel.
Il permet aux applications d'établir des connexions média entre appareils compatibles sans obliger les développeurs à réimplémenter chaque mécanisme de transport et de sécurité.
WebRTC n'est pas un protocole unique. Plusieurs composants travaillent ensemble.
Signalisation
Avant que deux appareils puissent établir une connexion média, ils doivent échanger des informations sur la session et sur leurs capacités de connexion.
Ce processus s'appelle la signalisation. Chaque application choisit son propre mécanisme de signalisation ; WebRTC n'impose ni serveur ni protocole de signalisation universel.
Voxal utilise la signalisation pour coordonner l'appartenance aux salons et l'établissement des connexions. Son chemin de signalisation est distinct du chemin des médias.
ICE, STUN et TURN
Les appareils se trouvent souvent derrière des routeurs, des pare-feu ou de la traduction d'adresses réseau (NAT). Trouver un chemin de connexion praticable peut donc être plus compliqué que relier deux adresses IP publiques.
WebRTC utilise l'Interactive Connectivity Establishment (ICE) pour collecter et tester les chemins de connexion possibles.
- STUN aide un appareil à découvrir comment il apparaît depuis le réseau public.
- TURN fournit un chemin de relais lorsqu'aucune connexion directe adaptée ne peut être établie.
Un relais TURN transmet du trafic média chiffré. Ce n'est pas la même chose qu'un SFU, qui termine les connexions média et transmet sélectivement les flux.
Une connexion directe est souvent préférable, mais un relais peut être indispensable pour se connecter.
RTP et transport média sécurisé
Les médias en temps réel sont généralement transportés avec le Real-time Transport Protocol (RTP), accompagné de RTCP pour le contrôle et les statistiques.
WebRTC utilise le RTP sécurisé (SRTP) pour protéger les médias. La couche de transport aide à acheminer les paquets, tandis que le codec détermine la manière dont l'audio ou la vidéo est représenté.
Ce sont deux responsabilités distinctes : un codec n'établit pas de connexion réseau, et une connexion réseau ne détermine pas la façon dont le son est compressé.
2. Qu'est-ce qu'un codec vocal ?
Un codec encode et décode les médias. Pour la communication vocale, son rôle est de représenter la parole de façon efficace tout en préservant l'intelligibilité et une qualité audio acceptable.
Sans compression, transmettre de l'audio brut peut consommer bien plus de bande passante que ce dont une application vocale a besoin.
Un codec fait un compromis entre plusieurs facteurs :
- La qualité audio et l'intelligibilité de la parole.
- Le débit et la consommation de bande passante.
- La complexité de l'encodage et du décodage.
- Le délai et la durée des trames.
- Le comportement lorsque les conditions réseau varient.
Il n'existe pas de meilleur codec universel. La diffusion de musique, les appels téléphoniques, le chat de jeu et les conversations de groupe en temps réel n'ont pas les mêmes priorités.
Pourquoi Opus est si répandu
Opus est un codec audio interactif conçu pour des usages comme la voix sur IP, la visioconférence et le chat en jeu.
Il prend en charge une large gamme de débits, de fréquences d'échantillonnage et de durées de trame. Cette souplesse le rend adapté à la parole comme à des usages audio plus exigeants.
Opus est aussi un codec audio dont l'implémentation est obligatoire pour les terminaux WebRTC, selon les exigences WebRTC sur les codecs audio.
Cela ne signifie pas que chaque connexion WebRTC utilise toujours Opus. Le choix effectif du codec dépend des capacités négociées par les terminaux participants.
Dans Voxal, le pipeline audio WebRTC du navigateur utilise Opus par défaut dans l'architecture documentée. Le navigateur prend en charge l'essentiel du travail d'encodage, de transport et de décodage.
Pour une application vocale en temps réel, le codec n'est qu'un élément de l'expérience. La qualité du microphone, le traitement audio, la perte de paquets, la latence réseau, la mémoire tampon de gigue et la lecture sur l'appareil comptent tout autant.
3. Qu'est-ce qu'un SFU ?
SFU signifie Selective Forwarding Unit.
Un SFU est un serveur média couramment utilisé pour les appels vidéo de groupe. Au lieu d'obliger chaque participant à envoyer un flux vidéo distinct directement à chacun des autres, chaque participant peut envoyer ses médias au SFU, qui transmet les flux appropriés aux autres participants.
Imaginez un salon de six personnes, chacune envoyant un flux de caméra.
Dans un maillage peer-to-peer complet, chaque participant peut devoir envoyer sa vidéo à cinq autres participants. Dans une topologie où un serveur retransmet, chaque participant peut envoyer un seul flux au SFU, qui se charge de la distribution.
Cela peut réduire sensiblement le nombre de flux vidéo sortants distincts qu'un participant doit entretenir.
Que fait réellement un SFU ?
Un SFU reçoit généralement des flux média encodés et les retransmet de façon sélective. Selon l'implémentation et les fonctionnalités négociées, il peut choisir quels flux ou quelles couches de qualité envoyer à chaque destinataire.
Par exemple, un participant qui regarde une petite vignette n'a pas besoin de la même qualité vidéo que quelqu'un qui affiche un intervenant en plein écran.
Un SFU peut aider à gérer ces besoins différents sans que chaque émetteur ait à transmettre séparément un flux à chaque destinataire.
Cependant, un SFU n'est pas gratuit. Il introduit de l'infrastructure, de la bande passante serveur, des coûts d'exploitation et un composant supplémentaire sur le chemin des médias.
Un SFU a aussi un modèle de confidentialité différent de celui d'un relais TURN. Comme un SFU termine le transport média et retransmet les médias de façon sélective, il peut techniquement accéder aux médias qu'il reçoit. Le chiffrement entre un participant et un SFU ne garantit pas, à lui seul, une confidentialité de bout en bout vis-à-vis de ce SFU.
4. Maillage peer-to-peer ou SFU
Ces deux architectures résolvent des problèmes proches mais différents.
Maillage peer-to-peer
Chaque participant établit des connexions média avec les autres participants.
Avantages :
- Des chemins média directs sont possibles.
- Aucun serveur média central n'est nécessaire pour redistribuer les médias.
- Les petits salons peuvent fonctionner sans service de retransmission des médias.
Inconvénients :
- Chaque émetteur peut devoir envoyer un flux distinct à chacun des autres participants.
- Le nombre de connexions média augmente avec la taille du salon.
- La bande passante montante et la gestion des connexions peuvent devenir des facteurs limitants.
Distribution par SFU
Chaque participant envoie ses médias à un service central de retransmission, qui les distribue aux autres participants.
Avantages :
- Une distribution plus efficace dans de nombreux scénarios de vidéo de groupe.
- Moins besoin pour chaque émetteur d'envoyer des copies séparées à chaque destinataire.
- Plus de contrôle sur les flux vidéo et les couches de qualité que reçoivent les destinataires.
Inconvénients :
- Infrastructure serveur et coûts de bande passante supplémentaires.
- Un intermédiaire s'insère dans le chemin des médias.
- Le modèle de confidentialité et de confiance diffère de celui d'une communication peer-to-peer directe.
L'essentiel est de ne pas supposer qu'une seule topologie doit servir pour tous les types de médias. L'audio et la vidéo ont des profils de trafic et des exigences différents.
5. Pourquoi Voxal garde la voix en peer-to-peer mais peut utiliser un SFU pour la vidéo
Voxal sépare l'audio vocal de la vidéo de la caméra et du partage d'écran.
L'audio vocal reste toujours en peer-to-peer. Il ne passe jamais par le SFU vidéo optionnel.
C'est un choix d'architecture délibéré : la voix est la fonctionnalité de communication centrale, et Voxal n'utilise pas le SFU comme service central de distribution audio.
La vidéo de la caméra et du partage d'écran, c'est différent. Dans les salons plus grands, un maillage peer-to-peer complet peut obliger chaque participant à envoyer plusieurs flux vidéo. Cela devient de plus en plus exigeant à mesure que le nombre de participants augmente.
Voxal peut donc utiliser le SFU Realtime de Cloudflare pour la vidéo et le partage d'écran lorsque la préférence de routage configurée l'autorise et que le salon dépasse les limites pratiques du maillage.
La préférence de routage compte :
- Allow relay for large rooms : Voxal peut utiliser le SFU lorsque le salon dépasse une topologie vidéo peer-to-peer confortable.
- Prefer direct : Voxal essaie d'abord le peer-to-peer et demande avant d'autoriser un relais lorsque le maillage devient inadapté.
- Direct only : la vidéo et le partage d'écran n'utilisent jamais le SFU, même si un grand salon peine à établir toutes les connexions directes.
Ces réglages concernent la vidéo et le partage d'écran, pas l'audio vocal.
Pourquoi ne pas tout faire passer par le même serveur ?
Parce que la meilleure topologie dépend du trafic transporté.
Un flux vocal est généralement bien plus léger qu'un flux de caméra. Faire passer la voix par un service central de retransmission introduirait un compromis différent en matière d'infrastructure et de confidentialité, sans être nécessaire pour l'architecture vocale retenue par Voxal.
La vidéo a un profil de bande passante plus exigeant et peut tirer un grand bénéfice d'une distribution assistée par serveur à mesure que le groupe grandit.
Séparer les deux permet à Voxal de conserver son modèle vocal peer-to-peer tout en offrant une option plus évolutive pour la vidéo de groupe.
6. Ce que cela implique pour la confidentialité
Les termes réseau sont parfois utilisés comme s'ils garantissaient automatiquement un certain niveau de confidentialité. Ce n'est pas le cas.
Un audio peer-to-peer signifie que les médias vocaux ne passent pas par un serveur média central, mais les serveurs de signalisation peuvent tout de même coordonner les connexions et traiter les métadonnées associées.
Un relais TURN transmet des médias chiffrés sans les décoder. Un SFU, en revanche, termine le transport média pour retransmettre les flux de façon sélective et peut techniquement accéder à la vidéo qu'il reçoit.
C'est pourquoi la distinction faite par Voxal est importante :
- La voix reste en peer-to-peer, en utilisant éventuellement un relais TURN chiffré.
- La vidéo de la caméra et du partage d'écran peut passer par un SFU dans les salons plus grands, selon la préférence de routage.
- Le traitement local des arrière-plans virtuels a lieu sur l'appareil de l'émetteur, mais cela ne signifie pas à lui seul que chaque connexion vidéo est directe.
Comprendre le chemin réel des médias est plus utile que de simplement décrire une application comme sans serveur.
7. Mise en perspective
Une application de communication en temps réel combine plusieurs couches indépendantes :
- La signalisation coordonne les participants et la mise en place des connexions.
- ICE, STUN et TURN aident à établir un chemin réseau viable.
- WebRTC et le transport RTP sécurisé acheminent les médias en temps réel.
- Un codec comme Opus représente l'audio de façon efficace.
- La topologie réseau détermine si les médias circulent directement entre pairs ou via un service de retransmission.
La conception de Voxal applique ces choix séparément à la voix et à la vidéo. Il en résulte une architecture centrée sur la voix, où l'audio reste en peer-to-peer, tandis que la vidéo et le partage d'écran peuvent recourir à une retransmission optionnelle assistée par serveur lorsque les grands salons en ont besoin.
Ces distinctions sont importantes lors de la conception de tout système de communication en temps réel. Le but n'est pas simplement de minimiser les serveurs ou de maximiser les connexions directes ; c'est de faire des compromis délibérés entre latence, bande passante, fiabilité, évolutivité et confidentialité.
Essayer Voxal
Voxal réunit chat vocal peer-to-peer, push-to-talk (appuyer pour parler), mode mains libres, suppression du bruit, et vidéo et partage d'écran en option.
Essayez Voxal dans votre navigateur, ou explorez l'implémentation dans le dépôt open source de Voxal.
À lire aussi : Qu'est-ce que le chat vocal peer-to-peer ? · Qu'est-ce que le push-to-talk ? Un guide pratique · Documentation de Voxal sur le routage vidéo
