Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Visioconférence sécurisée : les options françaises ou open source

WebRTC : quelles différences entre les architectures Mesh, MCU et SFU ?

Un bon nombre de services de visioconférence se sont attachés à un standard de communication en temps réel : WebRTC. Pour le déployer, les éditeurs et les entreprises peuvent se reposer sur trois architectures : Mesh, MCU et SFU. Découvrez leurs spécificités.

Gaétan Raoul
par
Publié le: 05 mai 2020

Comme n’importe quel logiciel ou application cloud, le fonctionnement des outils de visioconférence est conditionné par une architecture logicielle et de communication particulière. La plupart des éditeurs utilisent la technologie WebRTC (Web Real-time Communication). Il s’agit d’un framework composé de plusieurs API JavaScript, développé au sein du W3C et de l’IETF et particulièrement soutenu par les éditeurs de navigateurs Web comme Google ou Mozilla.

En effet, WebRTC est directement intégré dans différents navigateurs Web (Google, Opera, Firefox, Safari, etc.). Dans l’idée, WebRTC permet une communication en temps réel sans la nécessité de télécharger un client (plugins ou logiciels). Microsoft Teams et Google Meet utilisent tous deux cette technologie.

De manière générale, la technologie WebRTC établit une connexion pair à pair entre deux navigateurs Web distants via un service de signalement dépendant du protocole UDP. Ces deux clients doivent être connectés simultanément à une même page HTML 5 dont ils téléchargent le contenu.
Une API JavaScript doit maintenir la connexion ouverte par HTTPS ou Websocket. Le client 1 demande une connexion au service de signalement (signaling) avec le client 2 qui doit accepter cette demande, le service reroute la requête qui sera acceptée ou non par le client 1. Cette couche de signalement n’est pas spécifiée dans le framework WebRTC.
Pour cela, il faut utiliser des protocoles de message comme XMPP, MQTT ou SIP, ainsi qu’un canal de communication duplex, par exemple WebSocket ou XMLHttpRequest.

Pour gérer cette connexion, WebRTC instancie l’objet PeerConnection qui établit les flux de médias et de données. L’objet PeerConnection « demande » sur le navigateur d’où provient l’appel, attend un retour qui crée un objet « réponse » sur le navigateur auquel il s’adresse. Avant la connexion, cette API RTCPeerConnection génère le Session Description Protocol (SDP). Il s’agit d’une description des paramètres de la session. SDP s’occupe de la négociation du protocole RTP (Real Time Transport Protocol) dédié au transport des médias, et de SCTCP (Stream Control Transmission Protocol), chargé du transport des données. Les objets SDP sont transmis aux autres pairs à travers le canal de signalement. Une fois la demande acceptée, c’est à ce moment-là que sont partagées les informations de connexion, dont l’adresse IP des appareils participants.

L’architecture Peer to peer ou Mesh à l’origine de WebRTC

Pour cela, WebRTC emploie le cadre ICE (Interactive Connectivity Establishment). Si les routeurs des participants n’utilisent pas de mécanisme NAT (translation d’adresse réseau), la connexion est directe à l’aide du protocole STUN ( Simple Traversal of UDP through NATs ou traversée simple de UDP à travers les NAT) via UDP. Si cette requête échoue, ICE essaye le protocole TCP en HTTP et HTTPS, via le serveur relais TURN (Traversing Using Relay NAT) qui prend le rôle de proxy pour l’échange de flux entre les pairs. Celui-ci demande au serveur STUN d’informer de l’existence du NAT et de relayer chaque paquet de données. 

L’interface de programmation MediaStream, elle, demande l’accès aux ressources médias des utilisateurs (microphone et caméra) en appelant la fonction getUserMedia(). Les objets MediaStream encapsulent des objets MediaStreamTrack. Ils gèrent les différents canaux audio et vidéo des différents utilisateurs.

Ensuite, l’API DATA Channels correspond à un moyen d’échange de données bidirectionnel depuis RTCPeerConnection. Celle-ci ne gère pas les flux médias (audio et vidéo), mais les messages et le partage de documents. Data Channels utilise le protocole SCTP encapsulé dans le protocole DTLS (Datagram Transport Layer Security). Cela permet deux choses : lier les messages ou les données partagées au paquet qui contient les flux média et chiffrer les données avec le couple SRTP-DTLS.

Cette architecture Peer to peer ou Mesh qui est à la base du standard WebRTC a des avantages certains. Simple à déployer, peu coûteuse, elle garantit une sécurité de bout en bout entre les participants d’une visioconférence. Seulement, l’envoi des différents flux média chiffrés demande une bande passante montante et descendante particulièrement robuste. De plus l’encodage simultané des flux pèse fortement sur le CPU des terminaux utilisé par les utilisateurs. Cette méthode Mesh est donc idéale avec un faible nombre de participants. Selon les experts, le maximum de membres serait de trois.

Or, les fournisseurs de solutions CPaaS qui utilisent WebRTC veulent répondre aux demandes des grands groupes. Ceux-ci comptent davantage sur les deux autres architectures de communication du standard.

MultiPoint Conferencing Unit (MCU)

C’est l’architecture utilisée par un bon nombre de systèmes de visioconférences dit « legacy ». Elle est également disponible avec WebRTC. Dans ce cas de figure, les terminaux envoient les flux médias à une unité centrale, un serveur, qui les décompose et les recompose, mixe les médias dans un seul flux audio-vidéo. Ce flux est retourné aux participants. L’approche MCU peut reposer sur l’envoi d’un même flux recomposé vers tous les participants ou sur un encodeur par utilisateur. Ici la consommation de bande passante descendante est forte, les CPU des clients et du serveur sont particulièrement sollicités.

En termes de sécurité, cela demande de déchiffrer, puis chiffrer les données avant de les renvoyer aux utilisateurs.

Selective Forward Unit (SFU)

Avec le mécanisme SFU, les terminaux connectés à une conférence envoient leurs données à un routeur. Ce routeur serveur redirige les flux médias à chacun des participants. Chacun d’entre eux envoie une seule liaison montante et reçoit autant de liaisons descendantes qu’il y a de membres dans la visioconférence. Cette fois-ci, le processeur du routeur serveur ne subit plus autant la charge induite par la phase d’encodage et de décodage. De ce fait, cette architecture est la plus adaptée pour le passage à l’échelle de service de visioconférence. SFU demande tout de même une bande passante descendante de qualité.

Si les flux médias envoyés et reçus par les utilisateurs sont chiffrés par le couple SRTP/DTLS, les architectures MCU et SFU impliquent un potentiel point clair sur le serveur-routeur utilisé pour le multiplexage des flux médias.

Pour approfondir sur ToIP - VoIP