Comment fonctionnent les appels vidéo de groupe : signalisation, mesh et serveurs multimédias SFU

Un appel vidéo entre deux personnes peut passer directement d’un appareil à l’autre. WebRTC envoie la caméra et le micro de chacun directement à l’autre, avec un relais seulement quand un pare-feu barre la route, comme l’explique notre article sur les serveurs STUN et TURN.

Ajoutez une troisième personne, et la même approche fonctionne encore. Ajoutez-en une sixième, et tout commence à se dégrader : l’image se fige, le ventilateur de l’ordinateur portable s’emballe, et la personne qui suit l’appel sur son téléphone est déconnectée. Les appels de groupe demandent une autre architecture, et presque toutes les applications qui en proposent finissent par adopter la même.

Cet article en passe en revue les éléments : le serveur de signalisation dont chaque appel a besoin, le mesh qui convient à quelques personnes, les deux types de serveurs multimédias, et ce qui change pour le chiffrement quand un serveur se trouve au milieu.

Tout appel a besoin de signalisation

Avant que le moindre son ou la moindre image ne circule, les appareils d’un appel doivent s’entendre sur la manière. Chacun décrit ce qu’il peut envoyer et recevoir, les codecs, les résolutions et les adresses où le joindre, et l’autre côté répond. Dans WebRTC, ce sont l’offre, la réponse et les candidats ICE.

WebRTC ne dit pas comment ces messages circulent. C’est à votre application de s’en charger, et ce qui les transporte, c’est le serveur de signalisation. En pratique, c’est un serveur WebSocket auquel chaque page et chaque application gardent une connexion ouverte, car un appel demande plus que ce premier échange :

• La sonnerie. La personne appelée doit être avertie de l’appel dans tous les onglets et sur tous les appareils qu’elle a ouverts, et ne plus l’être dès qu’elle a répondu sur l’un d’eux.
• Qui est dans l’appel. Chacun doit savoir quand quelqu’un arrive ou part, allume sa caméra ou partage son écran.
• Qui peut rejoindre l’appel. C’est sur le serveur de signalisation qu’un appel est accepté ou refusé, et c’est donc là que votre application décide qui peut appeler qui et qui rejoint chaque appel de groupe.

Le serveur de signalisation transporte peu de données, mais il doit être en ligne chaque fois qu’un appel peut démarrer, et il doit connaître vos utilisateurs.

Le mesh : chacun envoie à tout le monde

L’appel de groupe le plus simple est un mesh. Chaque appareil ouvre une connexion directe vers chacun des autres et envoie le flux de sa caméra à chacun d’eux.

À trois, chaque appareil envoie deux copies de son image et en reçoit deux. Cela passe très bien. L’ennui, c’est la façon dont les chiffres augmentent :

Personnes dans l’appel	Copies envoyées par chaque appareil	Connexions dans l’appel
3	2	3
5	4	10
8	7	28
12	11	66

Une image de caméra de bonne qualité est souvent envoyée à un ou deux mégabits par seconde. Dans un appel à huit, chaque appareil en enverrait sept à la fois, plus que ce que beaucoup de connexions domestiques et mobiles peuvent envoyer de façon stable. En général, l’appareil encode aussi l’image séparément pour chaque connexion, et c’est ce qui fait s’emballer le ventilateur et vide la batterie du téléphone.

Le mesh convient bien à trois ou quatre personnes avec des connexions correctes, sans aucun serveur pour transporter les médias. Au-delà, l’appel a besoin d’un serveur au milieu.

Le MCU : une seule image mixée pour tout le monde

La réponse la plus ancienne est le MCU (multipoint control unit, ou unité de contrôle multipoint). Chaque appareil envoie son image une seule fois au serveur. Le serveur les décode toutes, les assemble en une seule image composite, la réencode et envoie cette image unique à chaque personne.

Chaque appareil envoie alors un seul flux et en reçoit un seul, ce qui ménage les téléphones et les réseaux lents. Le coût passe du côté du serveur : décoder et encoder chaque image de chaque appel demande beaucoup de calcul, le mixage ajoute de la latence, et tout le monde voit la même disposition, choisie par le serveur. On trouve encore des MCU là où une image unique est nécessaire, par exemple quand une ligne téléphonique rejoint une réunion vidéo, mais la plupart des appels de groupe utilisent aujourd’hui l’autre type de serveur.

Le SFU : envoyer une fois, transmettre à tous

Le SFU (selective forwarding unit, ou unité de transfert sélectif) est le serveur multimédia sur lequel tournent la plupart des appels de groupe. Chaque appareil envoie son image une seule fois au SFU, et le SFU la transmet à tous les autres participants de l’appel, sans la décoder.

Chaque appareil envoie un seul flux, quel que soit le nombre de personnes dans l’appel. Il reçoit un flux par personne qu’il affiche, et c’est là qu’intervient le « sélectif ». Comme le SFU se trouve entre chaque émetteur et chaque récepteur, il peut choisir ce que reçoit chacun :

• Plusieurs qualités pour chaque émetteur. Avec le simulcast, un appareil envoie son image en deux ou trois tailles à la fois, et le SFU transmet la petite à qui l’affiche en vignette ou a une connexion faible, et la grande à qui l’affiche en plein écran.
• Seulement ce qui est à l’écran. Dans un appel à trente, une page qui affiche neuf tuiles n’a pas besoin des vingt et une autres images. Le SFU cesse de les transmettre jusqu’à ce qu’elles soient affichées.
• Qui parle. Le SFU voit le niveau audio de chacun et peut indiquer à chaque page qui parle en ce moment, pour que la page l’affiche en grand.
• Intervenants et auditeurs. Dans un cours ou une table ronde, quelques personnes émettent et tous les autres ne font que recevoir. Le SFU transmet les flux des intervenants et ne reçoit rien des auditeurs, si bien qu’un appel peut réunir bien plus de personnes que celles qui sont à l’image.

Comme le SFU ne décode jamais les médias, un seul serveur peut transmettre un très grand nombre de flux. Un très grand appel peut s’étendre sur plusieurs SFU, chacun servant les personnes proches de lui et les flux passant de l’un à l’autre, si bien que des personnes sur des continents différents se connectent chacune à un serveur proche d’elles.

Quand une personne présente à tout le monde et que le public ne fait que regarder, l’architecture change encore : c’est une diffusion en direct, conçue pour un public de toute taille avec un chat à côté, que nous présentons sur la page Diffusion en direct pour votre application.

Le chiffrement avec un serveur au milieu

Toute connexion WebRTC est chiffrée, et personne sur le réseau entre un appareil et le serveur ne peut voir ni entendre l’appel. Dans un appel direct entre deux personnes, ce chiffrement est de bout en bout : seuls les deux appareils détiennent les clés.

Avec un SFU, la connexion de chaque appareil s’arrête au serveur. Le SFU déchiffre ce qui arrive et le chiffre à nouveau pour chaque récepteur, si bien que le serveur pourrait voir et entendre tout ce qu’il transmet. Pour beaucoup d’applications, c’est acceptable. Pour un médecin et son patient, un avocat et son client, ou une équipe qui discute d’un sujet confidentiel, cela ne l’est pas.

La solution consiste à chiffrer une seconde fois chaque trame audio et vidéo, dans l’appareil, avant qu’elle ne parte, avec une clé que le serveur n’a jamais. Les navigateurs actuels le permettent grâce aux encoded transforms de WebRTC. Le SFU voit toujours quel flux est lequel et les transmet comme avant, mais ce qu’il transmet est scellé. Les clés viennent de votre propre serveur, qui ne les donne qu’aux personnes autorisées dans l’appel.

La contrepartie, c’est qu’un serveur qui ne peut pas lire les médias ne peut pas non plus les mixer, les enregistrer ni changer leur format. C’est tout l’intérêt.

Faire tourner vos propres SFU

Il existe des SFU open source solides. Une équipe qui fait tourner les siens prend en charge :

• Des serveurs avec des adresses publiques et des ports UDP ouverts, dans les régions où se trouvent vos utilisateurs, avec la bande passante nécessaire pour chaque flux qu’ils transmettent.
• Des relais TURN en plus, car certaines personnes ne peuvent toujours pas joindre le SFU directement, comme dans un appel entre deux personnes.
• Un serveur de signalisation qui connaît vos utilisateurs, fait sonner leurs appareils et décide qui rejoint l’appel.
• Le placement de chaque appel, pour que ses participants arrivent sur un serveur proche d’eux qui a de la place, et la répartition d’un grand appel sur plusieurs serveurs.
• Le maintien en service : mises à jour, surveillance, et appels qui passent sur un autre serveur quand l’un d’eux tombe en panne.

Rien de tout cela n’est exotique, mais c’est un service à faire tourner tant que votre application propose des appels.

Comment WordPlus Cloud fait tourner les appels de groupe

WordPlus Cloud fait tourner tout cela pour vous, de la signalisation aux serveurs multimédias :

1. La signalisation sur la connexion que vos pages ont déjà. La même connexion temps réel qui transporte vos salles et la liste des personnes en ligne fait sonner un appel dans chaque onglet et chaque application de la personne appelée, et indique à chacun, dans un appel de groupe, qui arrive, qui part et qui parle.
2. Les appels de groupe sur nos serveurs multimédias, dans plusieurs régions. Chaque appareil envoie sa caméra une seule fois, quel que soit le nombre de personnes dans l’appel, et le nombre de personnes dans un appel n’a pas de limite.
3. Votre serveur décide. Une règle sur votre serveur indique qui peut rejoindre chaque appel de groupe, qui parle et qui ne fait qu’écouter, et qui est hôte. Les hôtes coupent un micro, donnent la parole à quelqu’un et retirent quelqu’un de l’appel, et votre serveur peut faire de même sans aucune page ouverte.
4. Le chiffrement de bout en bout quand votre règle le prévoit. Chaque trame est chiffrée dans le navigateur avec une clé dérivée par votre serveur, si bien que nos serveurs multimédias transmettent ce qu’ils ne peuvent pas lire. Un appel entre deux personnes que quelqu’un d’autre rejoint devient un appel de groupe et reste chiffré de bout en bout.
5. Un écran d’appel prêt à l’emploi, ou le vôtre. Utilisez la fenêtre d’appel toute faite sur le web, iOS et Android, ou construisez votre propre interface sur le même SDK.

Cela fonctionne depuis Next.js, Laravel, Django et d’autres piles, avec nos SDK, et Better Messages fait tourner ses appels de groupe sur les mêmes serveurs multimédias sous WordPress. La page Appels vidéo et appels de groupe pour votre application montre ce que vous apportent les SDK, et la page Comment fonctionnent les appels de notre documentation montre le code.