Concepts fondamentaux

Cette section donne un aperçu des concepts fondamentaux de l'application VDI de Zoom Workplace.

Modes d’optimisation du plug-in

L’application Zoom Workplace VDI prend en charge trois modes de fonctionnement pour le traitement des médias en temps réel : Direct Optimized, Channel Optimized et Fallback Mode

Dans le contexte de l’application Zoom Workplace VDI, le traitement des médias en temps réel fait référence au relais et au rendu des médias en temps réel entre le cloud Zoom, l’application Zoom Workplace VDI et/ou le plug-in. Pour prendre en charge une gamme de cas d’utilisation VDI, l’application Zoom Workplace VDI propose trois modes de fonctionnement distincts pour le traitement et l’optimisation des médias : mode Direct Optimized, mode Channel Optimized et mode Fallback. Ceux-ci sont abordés dans les sections suivantes.

Mode Direct Optimized : lorsque l’application Zoom Workplace VDI et le plug-in reçoivent des flux de données indépendants depuis le cloud Zoom

Le mode Direct Optimized est le mode d’optimisation par défaut pour l’application Zoom Workplace VDI et le plug-in. Dans ce mode, le cloud Zoom maintient deux flux de données séparés pour un utilisateur VDI optimisé : un pour l’application Zoom Workplace VDI et un autre pour le plug-in. Cette configuration permet au client distant de l’utilisateur (équipé du plug-in VDI) de communiquer directement avec le cloud Zoom pour les transferts de médias en temps réel, évitant ainsi la nécessité de faire transiter la plupart du trafic média en temps réel via le bureau virtuel ou à travers le canal virtuel.

Lorsqu’il fonctionne en mode Direct Optimized, les éléments suivants se produisent :

1. Le plug-in reçoit directement depuis le cloud des flux de données pour la vidéo et l’audio.

2. L’application Zoom Workplace VDI gère les données générales de la réunion, telles que les informations sur les participants, les messages de chat ou les fonctionnalités d’AI Companion, les affichant dans l’espace réservé de l’application Workplace, tout en gérant également le partage d’écran entrant en le transmettant au plug-in et en téléchargeant le contenu de partage d’écran local depuis le bureau virtuel lorsqu’il est actif.

3. Le plug-in et le bureau VDI utilisent la connexion virtuelle du fournisseur VDI pour communiquer et déterminer le placement et le rendu des médias à l’écran entre les deux couches.

Schéma illustrant comment le cloud Zoom transmet des données vers deux destinations distinctes lorsqu’on utilise le mode direct optimisé.

Mode Channel Optimized : lorsque le plug-in reçoit des données réacheminées (hairpinned) via le bureau virtuel

L’optimisation par canal est similaire à l’expérience d’optimisation directe, où le plug-in continue de rendre les médias de la réunion (comme illustré dans l’image ci‑dessus), mais via un chemin réseau différent. Dans ce mode, les éléments suivants se produisent :

1. Tous les médias de la réunion sont d’abord livrés au serveur VDI depuis le cloud Zoom.

2. Le serveur VDI transfère les médias vers le plug-in soit via une connexion UDP hors bande, soit via le canal virtuel VDI existant si la connexion UDP ne peut pas être établie.

Cette méthode peut être privilégiée par les organisations qui n’autorisent pas l’accès direct à Internet pour les clients légers (ou autres appareils distants), ou qui préfèrent acheminer les données via leur réseau, mais peut potentiellement conduire à une expérience moins bonne que l’optimisation directe si les conditions de routage réseau sont sous‑optimales. L’image ci‑dessous illustre le flux de données d’optimisation UDP/canal.

Schéma illustrant comment les données sont transmises au bureau VDI et au client distant via une connexion réacheminée (hairpinned).

Mode Fallback : lorsque tous les médias de la réunion sont acheminés et traités directement sur le bureau virtuel

Le mode Fallback représente une expérience VDI entièrement non optimisée. Dans ce mode, il n’y a pas d’optimisation des médias ni d’utilisation du plug-in, et toute la communication se fait directement entre le serveur VDI et le cloud Zoom, avec tout le traitement effectué exclusivement sur le serveur VDI.

Cette méthode impose une charge de traitement importante sur les ressources du serveur VDI, entraînant souvent de mauvaises performances, notamment lenteur, vidéo saccadée et audio déformé. Ainsi, le mode Fallback est l’option la moins souhaitable et ne devrait être utilisé qu’en dernier recours ou lorsque les plug-ins ne sont pas disponibles.

Avertissement

Le mode Fallback doit être évité autant que possible pour préserver les performances du serveur.

Résumé des modes de connexion

L’application Zoom Workplace VDI prend en charge trois modes de connexion distincts, chacun adapté à des besoins opérationnels et de sécurité différents. Le mode par défaut et le plus efficace est le mode Direct Optimized, dans lequel l’application Zoom Workplace VDI et le plug-in établissent des connexions séparées au cloud Zoom, gérant indépendamment leurs parties respectives d’une réunion Zoom pour offrir une expérience fluide et optimisée.

En plus du mode Direct Optimized, l’application Zoom Workplace VDI peut fonctionner dans des configurations alternatives, notamment le mode Channel Optimized et le mode Fallback. Ces modes peuvent aider à répondre à des contraintes spécifiques de flux de travail ou de réseau, telles que l’accès Internet restreint pour les appareils distants, l’acheminement des données pour des raisons de confidentialité ou l’absence de plug-ins.

Le tableau suivant résume les principales différences entre ces modes.

	Déchargement des médias	Accès direct au cloud depuis le plug-in
Direct Optimized	✔	✔
Channel Optimized	✔
Fallback Mode

Déchargement des médias WebRTC

Aperçu

Zoom fournit un client WebRTC basé sur navigateur via le Zoom Web App qui peut décharger le traitement audio vers l’appareil local de l’utilisateur lorsqu’il fonctionne à l’intérieur d’un environnement de bureau virtuel. Cela fonctionne sans nécessiter de plug‑ins spécifiques à Zoom parce que la plateforme VDI fournit son propre moteur WebRTC local et un cadre de redirection qui relie l’application Web Zoom à ce moteur.

Avertissement

Le déchargement des médias WebRTC est actuellement limité à l’audio et ne prend pas en charge l’optimisation vidéo.

Cette fonctionnalité prend en charge les produits et canaux suivants via l’application Web Zoom :

• Zoom Phone

• Zoom Contact Center

• Connecteur CTI Zoom Contact Center

Cette fonctionnalité est actuellement prise en charge par les plateformes de bureau virtuel suivantes :

• Citrix

• Omnissa Horizon

Consultez le centre d'assistance de Zoom pour plus d'informations sur configuration de Zoom VDI pour prendre en charge la redirection WebRTC pour l’application Web Zoom.

L’application Web Zoom décharge l’audio WebRTC VDI vers l’appareil local

Lorsque l’application Web Zoom à l’intérieur du bureau virtuel tente d’initialiser l’audio WebRTC, ses requêtes sont interceptées avant que le bureau virtuel n’essaie de capturer ou de traiter le son. Plutôt que d’activer la pile média WebRTC intégrée du navigateur dans la session hébergée, la plateforme VDI traduit la signalisation liée à l’audio en messages de contrôle légers. Ces messages sont envoyés via le canal virtuel du fournisseur VDI vers la machine locale de l’utilisateur, redirigeant le trafic audio en temps réel depuis le cloud Zoom directement vers la machine locale de l’utilisateur.

Sur la machine locale, le moteur WebRTC natif inclus avec le client VDI (par ex., Citrix, Omnissa Horizon) reçoit ces messages et devient responsable de toute la capture audio, de l’encodage, du décodage et de la lecture. Le moteur utilise le microphone, les haut‑parleurs et les ressources de traitement du système local, aidant à garantir que l’audio ne transite pas par le serveur du bureau virtuel.

Le diagramme suivant illustre comment les données sont acheminées lors de l’utilisation du déchargement des médias WebRTC avec l’application Web Zoom et un agent virtuel pris en charge.

Schéma illustrant comment les médias sont répartis entre le bureau virtuel et l’appareil client distant.

Interaction entre l’application Web Zoom et la machine locale

Du point de vue de l’application Web Zoom, l’expérience ressemble toujours à une session WebRTC standard. La signalisation entre l’application Web Zoom et l’infrastructure de Zoom est relayée via le bureau virtuel, et le moteur WebRTC local reflète les paramètres de session négociés. L’application du bureau virtuel continue d’afficher l’interface Zoom — contrôles, état de la réunion et indicateurs — tandis que l’audio en temps réel est effectivement généré et consommé par la machine locale.

Parce que seules les messages de signalisation traversent le canal virtuel, la surcharge de bande passante est faible et constante, même dans des environnements multi‑utilisateurs.

Pourquoi aucun plug‑in n’est requis

L’élément clé est que le client VDI (par ex., Citrix, Omnissa Horizon) inclut déjà un moteur média WebRTC complet capable de gérer l’audio en temps réel. Étant donné que la couche de redirection fait apparaître ce moteur à l’application Web Zoom comme son implémentation WebRTC sous‑jacente, Zoom n’a pas besoin de fournir et de maintenir un plug‑in distinct. La logique de redirection mappe les appels d’API WebRTC, l’accès aux périphériques et la négociation de session depuis le navigateur à l’intérieur du bureau virtuel vers le moteur natif sur la machine locale.

Résultat

Cette approche permet à l’expérience WebRTC basée sur navigateur de Zoom de fonctionner efficacement dans les environnements VDI avec optimisation audio complète. L’interface s’exécute à l’intérieur du bureau virtuel, mais l’audio en temps réel est capturé et traité localement, offrant aux utilisateurs une expérience de conférence réactive et évolutive sans nécessiter de logiciel Zoom supplémentaire sur la machine locale ni d’exigences de traitement pour le serveur du bureau virtuel.