# Kernkonzepte

### Plug-In-Optimierungsmodi

#### <mark style="color:blau;">Die Zoom Workplace VDI-App unterstützt drei Betriebsarten für die Verarbeitung von Echtzeitmedien: Direct Optimized, Channel Optimized und Fallback-Modus</mark>

Im Zusammenhang mit der Zoom Workplace VDI-App bezeichnet die Verarbeitung von Echtzeitmedien die Weiterleitung und Wiedergabe von Echtzeitmedien zwischen der Zoom-Cloud, der Zoom Workplace VDI-App und/oder dem Plug-In. Zur Unterstützung verschiedener VDI-Anwendungsfälle bietet die Zoom Workplace VDI-App drei unterschiedliche Betriebsarten für Medienverarbeitung und -optimierung: Direct Optimized-Modus, Channel Optimized-Modus und Fallback-Modus. Diese werden in den folgenden Abschnitten erläutert.

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

Direct Optimized ist der Standard-Optimierungsmodus für die Zoom Workplace VDI-App und das Plug-In. In diesem Modus pflegt 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), direkt mit der Zoom-Cloud für Echtzeit-Mediendatenübertragungen zu kommunizieren, wodurch die Notwendigkeit entfällt, den Großteil des Echtzeit-Medienverkehrs über den virtuellen Desktop oder den virtuellen Kanal zu routen.

Beim Betrieb im Direct Optimized-Modus geschieht Folgendes:

1. Das Plug-In empfängt Videound Audiodatenströme direkt aus der Cloud.
2. Die Zoom Workplace VDI-App verarbeitet allgemeine Meetingdaten wie Teilnehmerinformationen, Chatnachrichten oder AI-Companion-Funktionen und zeigt diese im Platzhalter der Workplace-App an, während sie gleichzeitig eingehende Bildschirmfreigaben verwaltet, indem sie diese an das Plug-In weiterleitet und lokale Bildschirmfreigabeinhalte vom virtuellen Desktop hochlädt, wenn diese aktiv sind.
3. Das Plug-In und der VDI-Desktop verwenden die virtuelle Verbindung des VDI-Anbieters, um zu kommunizieren und die Platzierung sowie die Wiedergabe der On-Screen-Medien zwischen beiden Ebenen zu bestimmen.

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

#### <mark style="color:blau;">Channel Optimized-Modus: Wenn das Plug-In Daten empfängt, die über den virtuellen Desktop hairpinned werden</mark>

Channel-Optimierung ähnelt der Direct-Optimization-Erfahrung, wobei 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 zuerst von der Zoom-Cloud an den VDI-Server geliefert.
2. Der VDI-Server überträgt Medien an das Plug-In entweder über eine Out-of-Band-UDP-Verbindung oder über den bestehenden VDI-Virtual-Channel, falls die UDP-Verbindung nicht hergestellt werden kann.

Diese Methode kann von Organisationen bevorzugt werden, die keinen direkten Internetzugang für Thin Clients (oder andere Remote-Geräte) erlauben oder die es vorziehen, Daten durch ihr Netzwerk zu routen, aber *potenziell* zu einer schlechteren Erfahrung als bei der Direct Optimization führen, wenn die Netzwerk-Routing-Bedingungen suboptimal sind. Das nachstehende Bild zeigt den UDP/Channel-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 zeigt, wie Daten über eine hairpinned Verbindung an den VDI-Desktop und den Remote-Client übertragen werden.</p></figcaption></figure>

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

Fallback-Modus stellt eine vollständig nicht optimierte VDI-Erfahrung dar. In diesem Modus findet keine Medienoptimierung statt und es wird kein Plug-In verwendet. Die gesamte Kommunikation erfolgt direkt zwischen dem VDI-Server und der Zoom-Cloud, wobei sämtliche Verarbeitung ausschließlich auf dem VDI-Server stattfindet.

Diese Methode belastet die Ressourcen des VDI-Servers erheblich, was häufig zu schlechter Leistung führt, einschließlich Langsamkeit, ruckelndem Video und verzerrtem Audio. Daher ist der Fallback-Modus die am wenigsten bevorzugte Option und sollte nur als letzte Lösung oder bei Nichtverfügbarkeit von Plug-Ins verwendet werden.

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

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

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

Die Zoom Workplace VDI-App unterstützt drei verschiedene Verbindungsmodi, die jeweils auf unterschiedliche betriebliche und sicherheitsbezogene Anforderungen abgestimmt sind. Der Standard- und effizienteste Modus ist der Direct Optimized-Modus, bei dem die Zoom Workplace VDI-App und das Plug-In separate Verbindungen zur Zoom-Cloud herstellen und jeweils ihre zugehörigen Bereiche eines Zoom-Meetings unabhängig verwalten, um eine nahtlose, optimierte Erfahrung zu bieten.

Neben dem Direct Optimized-Modus kann die Zoom Workplace VDI-App auch in alternativen Konfigurationen betrieben werden, einschließlich Channel Optimized-Modus und Fallback-Modus. Diese Modi können helfen, bestimmte Arbeitsabläufe oder Netzwerkbeschränkungen zu bewältigen, wie z. B. eingeschränkten Internetzugang für Remote-Geräte, Datenrouting aus Datenschutzgründen oder das Fehlen von Plug-Ins.

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

|                       | **Medien-Auslagerung** | **Direkter Cloud-Zugriff vom Plug-In** |
| --------------------- | ---------------------- | -------------------------------------- |
| **Direct Optimized**  | ✔                      | ✔                                      |
| **Channel Optimized** | ✔                      |                                        |
| **Fallback-Modus**    |                        |                                        |

### WebRTC-Medienauslagerung

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

Zoom stellt einen browserbasierten WebRTC-Client über die [Zoom Web App](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064261) bereit, der die Audiowiedergabe auf das lokale Gerät des Benutzers auslagern kann, wenn er innerhalb einer virtuellen Desktop-Umgebung ausgeführt wird. Dies funktioniert, ohne Zoom-spezifische Plug-Ins zu erfordern, weil die VDI-Plattform ihre eigene lokale WebRTC-Engine und ein Umleitungsframework bereitstellt, das die Zoom Web App mit dieser Engine verbindet.

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

Die WebRTC-Medienauslagerung ist derzeit auf Audio beschränkt und unterstützt keine Videooptimierung.&#x20;
{% endhint %}

Dieses Feature unterstützt die folgenden Produkte und Kanäle der Zoom Web App:

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

Dieses Feature wird derzeit von den folgenden Virtual-Desktop-Plattformen unterstützt:&#x20;

* Citrix
* Omnissa Horizon

Weitere Informationen zum [Konfigurieren von Zoom VDI zur Unterstützung der WebRTC-Umleitung für die Zoom Web App](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0083142).

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

Wenn die Zoom Web App 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 eingebauten WebRTC-Media-Stack des Browsers in der gehosteten Sitzung zu aktivieren, übersetzt die VDI-Plattform die audiobezogenen Signalisierungen in leichtgewichtige Steuerungsnachrichten. Diese Nachrichten werden über den virtuellen Kanal des VDI-Anbieters an die lokale Maschine des Benutzers gesendet und leiten den Echtzeit-Audiostream von der Zoom-Cloud direkt an die lokale Maschine des Benutzers um.&#x20;

Auf der lokalen Maschine empfängt die native WebRTC-Engine, die im VDI-Client enthalten ist (z. B. Citrix, Omnissa Horizon), diese Nachrichten und übernimmt die Verantwortung für alle Audioerfassung, -kodierung, -dekodierung und -wiedergabe. Die Engine verwendet das lokale Mikrofon, die Lautsprecher und die Verarbeitungsressourcen des Systems, wodurch sichergestellt wird, dass Audio nicht über den virtuellen Desktop-Server fließt.

Das folgende Diagramm veranschaulicht, wie Daten geroutet werden, wenn WebRTC-Medienauslagerung mit der Zoom Web App und einem unterstützten VDI-Anbieter 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 zeigt, wie Medien zwischen dem virtuellen Desktop und dem Remote-Client-Gerät aufgeteilt werden.</p></figcaption></figure></div>

#### <mark style="color:blau;">Interaktion zwischen der Zoom Web App und der lokalen Maschine</mark>

Aus der Perspektive der Zoom Web App ähnelt die Erfahrung weiterhin einer Standard-WebRTC-Sitzung. Die Signalisierung zwischen der Zoom Web App und dem Zoom-Backend wird durch den virtuellen Desktop geleitet, und die lokale WebRTC-Engine spiegelt die ausgehandelten Sitzungsparameter wider. Die virtuelle Desktop-Anwendung stellt weiterhin die Zoom-Oberfläche dar—Steuerelemente, Meetingstatus und Indikatoren—während das eigentliche Echtzeit-Audio von der lokalen Maschine erzeugt und genutzt wird.

Da nur Signalisierungsnachrichten den virtuellen Kanal durchqueren, ist der Bandbreitenaufwand gering und konsistent, auch in Mehrbenutzerumgebungen.

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

Der entscheidende Faktor ist, 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 deren zugrundeliegende WebRTC-Implementierung erscheinen lässt, muss Zoom kein separates Plug-In bereitstellen und pflegen. Die Umleitungslogik bildet WebRTC-API-Aufrufe, Gerätezugriff und Sitzungsverhandlungen vom Browser im virtuellen Desktop auf die native Engine der lokalen Maschine ab.

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

Dieser Ansatz ermöglicht es der browserbasierten WebRTC-Erfahrung von Zoom, in VDI-Umgebungen effizient mit voller Audiooptimierung zu arbeiten. Die Oberfläche läuft innerhalb des virtuellen Desktops, aber das Echtzeit-Audio wird lokal erfasst und verarbeitet, wodurch Benutzer eine reaktionsschnelle und skalierbare Konferenzerfahrung erhalten, ohne zusätzliche Zoom-Software auf der lokalen Maschine oder Verarbeitungsanforderungen durch den Server des virtuellen Desktops.