# Grundlegende Konzepte

### Plug-in-Optimierungsmodi

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

Im Kontext der Zoom Workplace VDI-App bezieht sich die Verarbeitung von Echtzeitmedien auf das Weiterleiten und Rendern 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, bietet die Zoom Workplace VDI-App drei unterschiedliche Betriebsmodi für die Medienverarbeitung und -optimierung: Direkt-optimierter Modus, Kanal-optimierter Modus und Fallback-Modus. Diese werden in den folgenden Abschnitten erläutert.

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

Der Direkt-optimierte Modus ist der standardmäßig verwendete Optimierungsmodus für die Zoom Workplace VDI-App und das Plug-in. In diesem Modus hält die Zoom Cloud zwei separate Datenströme für einen optimierten VDI-Benutzer vor: 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 die Übertragung von Echtzeitmediendaten zu kommunizieren, wodurch die meisten Echtzeitmedien-Traffic nicht mehr über den virtuellen Desktop oder den virtuellen Kanal geleitet werden müssen.

Beim Betrieb im Direkt-optimierten Modus tritt Folgendes auf:

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 Teilnehmerinformationen, Chat-Nachrichten oder AI Companion-Funktionen, und zeigt sie innerhalb des Workplace-App-Platzhalters an, während sie außerdem das eingehende Bildschirmfreigabe-Streaming verwaltet, indem sie es an das Plug-in weiterleitet und lokale Bildschirmfreigabeinhalte vom virtuellen Desktop hochlädt, wenn diese aktiv ist.
3. Das Plug-in und der VDI-Desktop verwenden die virtuelle Verbindung des VDI-Anbieters, um zu kommunizieren und die Platzierung sowie das Rendering 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, das veranschaulicht, wie die Zoom Cloud Daten an zwei separate Ziele überträgt, wenn der direkt optimierte Modus verwendet wird.</p></figcaption></figure>

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

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

1. Alle Meeting-Medien werden zunächst vom Zoom Cloud an den VDI-Server geliefert.
2. Der VDI-Server überträgt Medien entweder über eine UDP-Verbindung außerhalb des Bandes oder über den vorhandenen VDI-virtuellen Kanal an das Plug-In, wenn 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) Aktivieren, oder die Daten lieber über ihr Netzwerk weiterleiten, aber sie kann *potenziell* bei suboptimalen Netzwerk-Weiterleitungsbedingungen zu einer schlechteren Erfahrung als die Direct Optimization führen. Die folgende Abbildung zeigt den Datenfluss der UDP-/Kanaloptimierung.

<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 Hairpin-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 weitergeleitet und dort direkt verarbeitet werden</mark>

Der Fallback-Modus steht für eine vollständig unoptimierte VDI-Erfahrung. In diesem Modus gibt es keine Medienoptimierung und kein Plug-In im Einsatz, 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 stellt eine erhebliche Verarbeitungsbelastung für die Ressourcen des VDI-Servers dar und führt häufig zu schlechter Leistung, einschließlich Langsamkeit, ruckeligem Video und verzerrtem Audio. Daher ist der Fallback-Modus die am wenigsten bevorzugte Option und sollte nur als letzter Ausweg 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:blau;">Zusammenfassung der Verbindungsmodi</mark>

Die Zoom Workplace VDI App unterstützt drei unterschiedliche Verbindungsmodi, die jeweils auf verschiedene betriebliche und Sicherheitsanforderungen zugeschnitten sind. Der standardmäßig eingestellte 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 des Kanal-optimierten Modus und des Fallback-Modus. Diese Modi können dabei helfen, bestimmte Workflow- oder Netzwerkeinschränkungen zu berücksichtigen, 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-Medienauslagerung

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

Zoom bietet einen browserbasierten 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 Desktop-Umgebung ausgeführt wird. Dies funktioniert, ohne dass irgendwelche Zoom-spezifischen 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 dazu finden Sie im Support-Center von Zoom [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 im virtuellen Desktop versucht, WebRTC-Audio zu initialisieren, werden ihre Anfragen abgefangen, bevor der virtuelle Desktop versucht, Ton zu erfassen oder zu verarbeiten. Statt den integrierten WebRTC-Medien-Stack des Browsers in der gehosteten Sitzung zu aktivieren, übersetzt die VDI-Plattform die audiobezogenen Signale in leichte Steuerungsnachrichten. Diese Nachrichten werden über den virtuellen Kanal des VDI-Anbieters an den lokalen Rechner des Benutzers gesendet, wodurch der Echtzeit-Audioverkehr aus der Zoom Cloud direkt an den lokalen Rechner des Benutzers umgeleitet wird.

Auf dem lokalen Rechner empfängt die native WebRTC-Engine, die im VDI-Client enthalten ist (z. B. Citrix, Omnissa Horizon), diese Nachrichten und ist für die gesamte Audioaufnahme, Kodierung, Dekodierung und Wiedergabe verantwortlich. Die Engine verwendet das Mikrofon, die Lautsprecher und die Verarbeitungsressourcen des lokalen Systems und trägt dazu bei, dass Audio nicht über den virtuellen Desktop-Server läuft.

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

<div data-with-frame="true"><figure><img src="/files/651b28e0d4ade9b6c973658641766a1daabf650b" 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:blau;">Interaktion zwischen der Zoom Web App und dem lokalen Rechner</mark>

Aus der Perspektive der Zoom Web App betrachtet ähnelt die Erfahrung weiterhin einer Standard-WebRTC-Sitzung. Das Signaling 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 vom lokalen Rechner erzeugt und verarbeitet wird.

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

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

Der entscheidende Enabler 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 ihre zugrunde liegende WebRTC-Implementierung erscheinen lässt, muss Zoom kein separates Plug-in bereitstellen und warten. Die Umleitungslogik bildet WebRTC-API-Aufrufe, Gerätezugriff und Sitzungsnegotiation vom Browser innerhalb des virtuellen Desktops auf die native Engine auf dem lokalen Rechner ab.

#### <mark style="color:blau;">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 das Echtzeit-Audio wird lokal erfasst und verarbeitet, sodass Benutzer eine reaktionsschnelle und skalierbare Konferenzerfahrung erhalten, ohne dass zusätzliche Zoom-Software auf dem lokalen Rechner erforderlich ist oder der Server des virtuellen Desktops belastet wird.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://library.zoom.com/technical-library/de/erweiterte-enterprise-services/virtual-desktop-infrastructure/vdi-explainer/core-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
