# Grundlegende Konzepte

### Plug-in-Optimierungsmodi

#### <mark style="color:blue;">Die Zoom Workplace VDI App unterstützt drei Betriebsmodi für die Echtzeit-Medienverarbeitung: Direkt optimiert, Kanal-optimiert und Fallback-Modus</mark>

Im Kontext der Zoom Workplace VDI App bezieht sich die Echtzeit-Medienverarbeitung auf die Weiterleitung und Darstellung von Echtzeitmedien zwischen der Zoom Cloud, der Zoom Workplace VDI App und/oder dem Plug-in. Um eine Reihe von VDI-Anwendungsfällen zu unterstützen, unterstützt die Zoom Workplace VDI App drei unterschiedliche Betriebsmodi für die Medienverarbeitung und -optimierung: den Modus Direkt optimiert, den Modus Kanal-optimiert und den Fallback-Modus. Diese werden in den folgenden Abschnitten erläutert.

#### <mark style="color:blue;">Modus Direkt optimiert: Wenn die Zoom Workplace VDI App und das Plug-in unabhängige Datenströme von der Zoom Cloud empfangen</mark>

Der Modus Direkt optimiert ist der standardmäßig Optimierungsmodus für die Zoom Workplace VDI App und das Plug-in. In diesem Modus verwaltet die Zoom Cloud zwei separate Datenströme für einen optimierten VDI-Benutzer: einen für die Zoom Workplace VDI App und einen weiteren für das Plug-in. Diese Konfiguration ermöglicht es dem Remote-Client des Benutzers (ausgestattet mit dem VDI-Plug-in), für Echtzeit-Mediendatenübertragungen direkt mit der Zoom Cloud zu kommunizieren, wodurch die Notwendigkeit entfällt, den Großteil des Echtzeit-Medienverkehrs über den virtuellen Desktop oder über den virtuellen Kanal zu leiten.

Beim Betrieb im Modus Direkt optimiert geschieht Folgendes:

1. Das Plug-in empfängt Datenströme für Video und Audio direkt aus der Cloud.
2. Die Zoom Workplace VDI App verarbeitet allgemeine Meeting-Daten, wie z. B. Teilnehmerinformationen, Chat-Nachricht oder AI Companion-Funktionen, und zeigt sie innerhalb des Workplace-App-Platzhalters an, während sie außerdem Eingehend Bildschirmfreigabe verwaltet, indem sie diese an das Plug-in weiterleitet und lokale Bildschirmfreigabe-Inhalte vom virtuellen Desktop hochlädt, wenn aktiv.
3. Das Plug-in und der VDI-Desktop verwenden die virtuelle Verbindung des VDI-Anbieters, um zu kommunizieren und die Platzierung sowie die Darstellung von Medien auf dem Bildschirm zwischen den beiden Ebenen zu bestimmen.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdMkBI5zRMicu977C-QSvtu06Kuvb1YyPZMOqh3Tnzd37uapLNkWLZxLNXxEgmg8e8RxX8btLPjVg8EnW0kRRe-UAjKQAIQEeKpsuR0SrEapbZSH5EO1GPtECfHz5G9uN8ptVbegA?key=Y8FtDbpjXDezi-KeGzQVkA" alt=""><figcaption><p>Diagramm zur Veranschaulichung, wie die Zoom Cloud Daten an zwei separate Ziele überträgt, wenn der Modus Direkt optimiert verwendet wird.</p></figcaption></figure>

#### <mark style="color:blue;">Kanal-optimierter Modus: Wenn das Plug-In Daten empfängt, die über den virtuellen Desktop per Hairpinning geleitet wurden</mark>

Die Kanaloptimierung ähnelt der Erfahrung der Direktoptimierung, bei der das Plug-In weiterhin die Meeting-Medien rendert (wie im obigen Bild zu sehen), jedoch über einen anderen Netzwerkpfad. In diesem Modus geschieht Folgendes:

1. Alle Meeting-Medien werden zunächst von der Zoom Cloud an den VDI-Server übertragen.
2. Der VDI-Server überträgt Medien entweder über eine Out-of-Band-UDP-Verbindung oder, falls die UDP-Verbindung nicht hergestellt werden kann, über den vorhandenen VDI-virtuellen Kanal an das Plug-In.

Diese Methode kann von Organisationen bevorzugt werden, die keinen direkten Internetzugang für Thin Clients (oder andere Remotegeräte) aktivieren, oder die es vorziehen, Daten über ihr Netzwerk weiterzuleiten, aber kann *möglicherweise* zu einer schlechteren Erfahrung als bei der Direktoptimierung führen, wenn die Netzwerk-Weiterleitungsbedingungen suboptimal sind. Die folgende Abbildung zeigt den UDP/Kanal-Optimierungs-Datenfluss.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdDt_WwrMDVVWLYDgtsXxsqsQNcflrpzhxtQSV2cnlYTx4IKRPRT49o-VLNfImUru407_vp7LJkRdaF4SdvIO405fZaD4LCcEvTjlUgE54NwfafocBGGKNk2NmRX1dRpcbg5V7U-w?key=Y8FtDbpjXDezi-KeGzQVkA" alt=""><figcaption><p>Diagramm, das veranschaulicht, wie Daten über eine per Hairpinning hergestellte Verbindung an den VDI-Desktop und den Remoten-Client übertragen werden.</p></figcaption></figure>

#### <mark style="color:blue;">Fallback-Modus: Wenn alle Meeting-Medien an den virtuellen Desktop weitergeleitet und dort direkt verarbeitet werden</mark>

Der Fallback-Modus steht für eine vollständig unoptimierte VDI-Erfahrung. In diesem Modus werden keine Medienoptimierung und kein Plug-In verwendet, und die gesamte Kommunikation erfolgt direkt zwischen dem VDI-Server und der Zoom Cloud, wobei die gesamte Verarbeitung ausschließlich auf dem VDI-Server stattfindet.

Diese Methode belastet die Verarbeitungsressourcen des VDI-Servers erheblich und führt häufig zu einer schlechten Leistung, einschließlich Langsamkeit, ruckelndem Video und verzerrtem Audio. Daher ist der Fallback-Modus die am wenigsten bevorzugte Option und sollte nur als letztes Mittel oder verwendet werden, wenn Plug-Ins nicht verfügbar sind.

{% hint style="danger" %}
**Warnung**

Der Fallback-Modus sollte nach Möglichkeit vermieden werden, um die Serverleistung aufrechtzuerhalten.
{% endhint %}

#### <mark style="color:blue;">Zusammenfassung der Verbindungsmodi</mark>

Die Zoom Workplace VDI App unterstützt drei unterschiedliche Verbindungsmodi, die jeweils auf verschiedene betriebliche und sicherheitsbezogene Anforderungen zugeschnitten sind. Der standardmäßig und effizienteste Modus ist der direkt optimierte Modus, bei dem die Zoom Workplace VDI App und das Plug-In separate Verbindungen zur Zoom Cloud herstellen und ihre jeweiligen Teile eines Zoom Meetings unabhängig voneinander verarbeiten, um ein nahtloses, optimiertes Erlebnis zu bieten.

Zusätzlich zum direkt optimierten Modus kann die Zoom Workplace VDI App in alternativen Konfigurationen betrieben werden, einschließlich kanaloptimiertem Modus und Fallback-Modus. Diese Modi können dabei helfen, spezifische Workflow- oder Netzwerkeinschränkungen zu bewältigen, wie z. B. eingeschränkten Internetzugang für Remote-Geräte, Daten-Weiterleitung bei Datenschutzbedenken oder das Fehlen von Plug-Ins.

Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen diesen Modi zusammen.

|                      | **Medienauslagerung** | **Direkter Cloud-Zugriff vom Plug-In** |
| -------------------- | --------------------- | -------------------------------------- |
| **Direkt optimiert** | ✔                     | ✔                                      |
| **Kanal optimiert**  | ✔                     |                                        |
| **Fallback-Modus**   |                       |                                        |

### WebRTC-Medien-Offloading

#### <mark style="color:blue;">Überblick</mark>

Zoom bietet einen Browser-basierten WebRTC-Client über den [Zoom Web App](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064261) das die Audioverarbeitung auf das lokale Gerät des Benutzers auslagern kann, wenn es in einer virtuellen Desktopumgebung ausgeführt wird. Dies funktioniert, ohne dass Zoom-spezifische Plug-ins erforderlich sind, da die VDI-Plattform ihre eigene lokale WebRTC-Engine und ein Umleitungs-Framework bereitstellt, das die Zoom Web App mit dieser Engine verbindet.

{% hint style="danger" %}
**Warnung**

WebRTC Media Offloading ist derzeit auf Audio beschränkt und unterstützt keine Videooptimierung.
{% endhint %}

Diese Funktion unterstützt die folgenden Produkte und Kanäle aus der Zoom Web App:

* Zoom Phone
* Zoom Contact Center
* Zoom Contact Center CTI Connector

Diese Funktion wird derzeit von den folgenden virtuellen Desktop-Plattformen unterstützt:

* Citrix
* Omnissa Horizon

Weitere Informationen finden Sie im Support-Center von Zoom zu [Zoom VDI konfigurieren, um Support für WebRTC-Umleitung für die Zoom Web App bereitzustellen](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0083142).

#### <mark style="color:blue;">Die Zoom Web App verlagert VDI-WebRTC-Audio auf das lokale Gerät</mark>

Wenn die Zoom App im Web innerhalb des virtuellen Desktops versucht, WebRTC Audio zu initialisieren, werden ihre Anfragen abgefangen, bevor der virtuelle Desktop versucht, Ton zu erfassen oder zu verarbeiten. Anstatt den integrierten WebRTC-Medien-Stack des Browsers in der gehosteten Sitzung zu aktivieren, übersetzt die Plattform die audiobezogene Signalisierung in leichtgewichtige Steuerungsnachrichten. Diese Nachrichten werden über den virtuellen Kanal des VDI-Anbieters an den lokalen Rechner des Benutzers gesendet und leiten den Echtzeit-Audiotraffic aus der Zoom Cloud direkt an den lokalen Rechner des Benutzers weiter.

Auf dem lokalen Rechner empfängt die mit dem VDI-Client (z. B. Citrix, Omnissa Horizon) enthaltene native WebRTC-Engine diese Nachrichten und übernimmt die Verantwortung für die gesamte Audioerfassung, Kodierung, Dekodierung und Wiedergabe. Die Engine nutzt das lokale System-Mikrofon, die Lautsprecher und die Verarbeitungsressourcen und trägt dazu bei, dass das Audio nicht über den virtuellen Desktop-Server geleitet wird.

Das folgende Diagramm veranschaulicht, wie Daten weitergeleitet werden, wenn WebRTC Media Offloading mit der Zoom Web App und einem unterstützten virtuellen Agenten verwendet wird.<br>

<div data-with-frame="true"><figure><img src="https://590569539-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FMziMpXttOigLu71P5cJb%2FCA2AE7FE-CEB8-4890-87AD-77E31161C3CC.png?alt=media&#x26;token=1e3b3f99-cb95-4ac4-82f0-c717f33b0f3f" alt="Diagram illustrating the Zoom cloud connecting to two different components, with audio going to the Remote Client and Presence, Meeting Data, Video, and Screen Sharing routing to the VDI Desktop"><figcaption><p>Diagramm, das veranschaulicht, wie Medien zwischen dem virtuellen Desktop und dem Remote-Client-Gerät aufgeteilt werden.</p></figcaption></figure></div>

#### <mark style="color:blue;">Interaktion zwischen der Zoom Web App und dem lokalen Gerät</mark>

Aus Sicht der Zoom Web App ähnelt die Erfahrung weiterhin einer Standard-WebRTC-Sitzung. Die Signalisierung zwischen der Zoom Web App und dem Backend von Zoom wird über den virtuellen Desktop weitergeleitet, und die lokale WebRTC-Engine spiegelt die ausgehandelten Sitzungsparameter wider. Die Anwendung auf dem virtuellen Desktop präsentiert weiterhin die Zoom-Oberfläche – Steuerelemente, Meeting-Status und Anzeigen –, während das eigentliche Echtzeit-Audio auf dem lokalen Gerät erzeugt und verarbeitet wird.

Da nur Signalisierungsnachrichten den virtuellen Kanal durchlaufen, ist der Bandbreiten-Overhead gering und konsistent, selbst in Umgebungen mit mehreren Benutzern.

#### <mark style="color:blue;">Warum kein Plug-in erforderlich ist</mark>

Der entscheidende Vorteil besteht darin, dass der VDI-Client (z. B. Citrix, Omnissa Horizon) bereits eine vollständige WebRTC-Media-Engine enthält, die in der Lage ist, Echtzeit-Audio zu verarbeiten. Da die Umleitungsschicht diese Engine der Zoom Web App als zugrunde liegende WebRTC-Implementierung erscheinen lässt, muss Zoom kein separates Plug-in bereitstellen und warten. Die Umleitungslogik ordnet WebRTC-API-Aufrufe, Gerätezugriff und Sitzungsaushandlung vom Browser innerhalb des virtuellen Desktops der nativen Engine auf dem lokalen Gerät zu.

#### <mark style="color:blue;">Ergebnis</mark>

Dieser Ansatz ermöglicht es der browserbasierten WebRTC-Erfahrung von Zoom, in VDI-Umgebungen mit vollständiger Audio-Optimierung effizient zu arbeiten. Die Oberfläche läuft innerhalb des virtuellen Desktops, aber Echtzeit-Audio wird lokal erfasst und verarbeitet, sodass Benutzer eine reaktionsschnelle und skalierbare Konferenzerfahrung erhalten, ohne dass zusätzliche Zoom-Software auf dem lokalen Gerät oder Verarbeitungsanforderungen durch den Server des virtuellen Desktops erforderlich sind.