> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/de/erweiterte-enterprise-services/zoom-mesh/zoom-mesh-functionality.md). # Funktionalität Dieser Abschnitt enthält zusätzliche Informationen zur Zoom Mesh-Funktionalität. ### Parent-Child-Funktionalität Die folgenden Abschnitte enthalten zusätzliche Informationen zu Parent- und Child-Beziehungen innerhalb eines Mesh-Netzwerks. #### Zoom Mesh erstellt standardmäßig ein Netzwerk ausschließlich für Benutzer innerhalb desselben Kontos Standardmäßig erstellt Zoom Mesh ein Netzwerk ausschließlich für Benutzer, die demselben Konto angehören. Ein Konto kann jedoch optional authentifizierten externen Benutzern innerhalb desselben lokalen Netzwerks die Teilnahme am Mesh zulassen, vorausgesetzt, das Konto des externen Benutzers *auch* ermöglicht ihnen, [eine Verbindung zum Mesh-Netzwerk eines anderen Kontos herzustellen](https://support.zoom.us/hc/en-us/articles/14925064423693-How-to-enable-Zoom-Mesh-Guest-Access). #### Parent- und Child-Rollen werden vom Zoom Mesh Cloud Orchestration Service bestimmt Der Zoom Mesh Cloud Orchestration Service (COS) ist ein Cloud-Dienst, der für die Definition von Parent- und Child-Client-Rollen innerhalb eines Netzwerks verantwortlich ist. Der Cloud Orchestration Service berücksichtigt zahlreiche Datensätze, um geeignete Parent-Clients zu bestimmen, darunter: {% columns %} {% column %} * CPU-Auslastung * CPU-Typ * RAM-Auslastung * Historische Mesh-Performance {% endcolumn %} {% column %} * Geräteverfügbarkeit (Ein/Aus) * Geräte-Opt-in/Opt-out * Betriebssystem {% endcolumn %} {% endcolumns %} Mithilfe dieser Datensätze bewertet der COS die Ergebnisse eines Benutzers anhand eines Bewertungsschemas: Je höher die Punktzahl eines Benutzers, desto wahrscheinlicher wird der Client als Parent ausgewählt; je niedriger die Punktzahl, desto unwahrscheinlicher. #### Die Zuordnung von Parent- und Child-Clients ist dynamisch und kann sich im Verlauf eines Events ändern Im Verlauf eines Meetings oder Webinars kann sich die Client-Zuordnung eines Benutzers je nach Leistung oder Bedarf ändern. Bei einem Event mit 100 Teilnehmern könnten beispielsweise nur 10 Parent-Clients erforderlich sein, um den Umverteilungsbedarf zu decken, während die übrigen 90 Benutzer umverteilte Streams als Child-Clients erhalten. Steigt die Teilnehmerzahl des Events jedoch auf 200, können Clients, die zuvor Child-Clients waren, zu Parent-Clients befördert werden, um dem höheren Bedarf gerecht zu werden. Wenn ein Parent-Client alternativ eine verschlechterte Leistung aufweist, kann der Client auf den Status eines Child-Clients herabgestuft werden, und es wird ein neuer Parent-Client zugewiesen. #### Das Verhältnis von Parent- zu Child-Clients wird dynamisch durch die Hardware- und Netzwerkleistung jedes Geräts bestimmt Während eines Events wird das Parent-Child-Verhältnis zwischen Clients dynamisch auf Grundlage der fortlaufenden Netzwerk- und Hardwareleistung des Geräts aktualisiert. Wenn ein Gerät eine geringe Hardware-(CPU/RAM)-Auslastung bei hoher Uplink-Bandbreiten-Kapazität aufweist, ist das Gerät ideal für eine Parent-Client-Rolle und kann eine Parent-Child-Beziehung mit mehreren anderen Geräten aufbauen. In diesem Szenario kann der Parent-Client versuchen, Medien auf andere Geräte zu verteilen, solange das Gerät nicht überlastet ist oder seine Leistung sich zu verschlechtern beginnt. Wenn jedoch die Netzwerk- oder Hardwareleistung des Geräts nachlässt, kann es seine Parent-Client-Zuordnung aufgeben und wieder in eine Child-Client-Rolle wechseln. #### Jedem Child werden zwei Parents zugewiesen Child-Clients, die mit einem Mesh-Netzwerk verbunden sind, werden *zwei* Parent-Clients für Ausfallsicherheit zugewiesen. Fällt ein Parent-Client aus, wechselt der Benutzer sofort auf den zweiten Parent-Client um. Anschließend wird ein neuer sekundärer Parent-Client eingerichtet, um die Ausfallsicherheit wiederherzustellen. #### Benutzer werden nicht informiert, wenn sie mit einem Mesh-Netzwerk verbunden sind Event-Hosts und Teilnehmer erhalten keine In-Client-Benachrichtigungen, wenn sie mit einem Mesh-Netzwerk verbunden sind. Verbindungen zum Mesh-Netzwerk können nur von einem Administrator oder autorisierten Benutzer über das [Zoom Mesh Dashboard](/technical-library/de/erweiterte-enterprise-services/zoom-mesh/zoom-mesh-dashboard.md). #### VDI-Clients können eine Mesh-Verbindung nur mit anderen VDI-Clients herstellen Wenn Zoom Mesh mit virtueller Desktop-Infrastruktur (VDI) verwendet wird, können Client-Geräte Zoom Mesh-Verbindungen nur mit anderen VDI-Clients herstellen, solange beide Benutzer ein unterstütztes VDI-Plug-In verwenden. Dies ist auf technische Einschränkungen der virtuellen Infrastruktur und der Weiterleitung von Medien zwischen Geräten zurückzuführen. **VDI-Clients verteilen den Kanal für die Bildschirmfreigabe in einem Mesh-Netzwerk nicht** Aufgrund des Designs des VDI-Clients von Zoom muss Inhalt der Bildschirmfreigabe über die virtuelle Maschine geleitet werden. Folglich können VDI-Clients die Bildschirmfreigabe nicht über ein Mesh-Netzwerk verteilen und müssen weiterhin innerhalb der virtuellen Infrastruktur verteilt werden. ### Funktionalität von Zoom Mesh for Meetings Die folgenden Abschnitte beschreiben Details der Funktionalität von Zoom Mesh for Meetings. #### Mesh for Meetings verteilt das Video des aktiven Sprechers neu Mit Zoom Mesh for Meetings wird die Bandbreitenoptimierung durch die Neuverteilung des *nachgelagerten* **aktiven Sprechers** Videos zwischen den Teilnehmern erreicht, wenn sich vier oder mehr Benutzer in einem Meeting befinden. Diese Funktion **gilt nicht** für das Hochladen von Medien, und alle Benutzer werden ihr Audio, Video und ihre Bildschirmfreigabe-Medien weiterhin einzeln an die Zoom Cloud hochladen. {% hint style="success" %} **Beispiel** Wenn in einem Meeting mit aktiviertem Zoom Mesh 10 Benutzer anwesend sind, können zwei Parent-Clients mit sieben oder acht Child-Clients ausgewählt werden. Wenn der aktuelle aktive Sprecher spricht, wird der *Videostream* von der Zoom Cloud an die Parent-Clients übertragen und dann an die Child-Clients innerhalb des Netzwerks neu verteilt. In diesem Szenario erhalten die Child-Clients **tun nicht** den Videostream des aktiven Sprechers aus der Zoom Cloud, wodurch bei der Verwendung von 1080p-Video potenziell bis zu 3+ Megabit Daten pro Benutzer eingespart werden können. {% endhint %} Die folgende Abbildung zeigt ein Beispiel dafür, wie nachgelagerte Videoinhalte des aktiven Sprechers innerhalb eines Mesh-Netzwerks neu verteilt werden.
Image map showing how Zoom Mesh Orchestrater works at a high level.
#### Änderungen des aktiven Sprechers bei Mesh for Meetings ändern weder Parent-Child-Beziehungen noch die Bandbreitenersparnis der Videoverteilung Während der Schwerpunkt von Zoom Mesh for Meetings auf der Neuverteilung des Videostreams des aktiven Sprechers liegt, wirken sich Änderungen des aktiven Sprechers nicht auf die Beziehungen zwischen Parent- und Child-Clients oder auf die durch die Video-Neuverteilung erzielten Bandbreitenersparnisse aus. Wenn der aktive Sprecher wechselt, ändern die zugewiesenen Parent-Clients einfach den Videostream, den sie neu verteilen. {% hint style="success" %} **Beispiel** Wenn Maurice in einem Meeting spricht und dann Holly zu sprechen beginnt, wechselt der Neuverteilungs-Feed des Parent-Clients von Maurices Videostream zu Hollys. Diese Änderung verändert weder, welche Benutzer-Clients derzeit als Parent oder Child zugewiesen sind, noch die allgemeinen Bandbreiteneinsparungen durch die Video-Neuverteilung; nur der neu verteilte Videostream ändert sich. {% endhint %} #### Die Bandbreitenersparnisse können je nach den vom Benutzer ausgewählten Video-Layouts variieren Obwohl Zoom Mesh den Bandbreitenverbrauch durch die Neuverteilung des Videostreams des aktiven Sprechers reduziert, können die Bandbreitenersparnisse je nach den vom Benutzer gewählten Layouts beeinflusst werden. Beispielsweise unterstützt die Galerieansicht bis zu 49 Videostreams auf dem Bildschirm gleichzeitig, während die Sprecheransicht jeweils einen Videostream anzeigt. Wenn ein Benutzer ein Meeting in der Galerieansicht ansieht, profitiert er davon, dass er den einzelnen Videostream des aktiven Sprechers über das Mesh-Netzwerk erhält, verbraucht jedoch weiterhin standardmäßige Bandbreitenmengen, indem er die verbleibenden 48 Videostreams der Benutzer aus der Zoom Cloud herunterlädt. Für optimale Bandbreiteneinsparungen wird Benutzern empfohlen, Meetings möglichst in einem Webinar-ähnlichen Layout anzuzeigen, etwa in der Multi-Speaker- oder Sprecheransicht. ### Funktionalität von Zoom Mesh for Webinars Die folgenden Abschnitte beschreiben Details der Funktionalität von Zoom Mesh for Webinars. #### Mesh for Webinars verteilt *alle* Videostreams der Webinar-Hosts und Diskussionsteilnehmer innerhalb des Netzwerks Im Gegensatz zu Zoom Mesh for Meetings verteilt Zoom Mesh for Webinars alle Videostreams der Webinar-Hosts und Diskussionsteilnehmer innerhalb des lokalen Netzwerks mithilfe von Parent-Child-Beziehungen – nicht nur die der aktiven Sprecher. Durch dieses Design profitieren alle Benutzer im Mesh-Netzwerk weiterhin von einem geringeren externen Bandbreitenverbrauch und erleben gleichzeitig dieselbe Videoqualität wie die anderen.
Image map showing how Zoom Mesh Orchestrater works at a high level.
#### Die Vorteile von Mesh for Webinars ändern sich nicht mit den Video-Layouts Unabhängig davon, welche Video-Layouts Benutzer beim Anzeigen eines Webinars wählen, erhalten Benutzer weiterhin die Vorteile der Video-Neuverteilung innerhalb des Netzwerks, einschließlich Galerieansicht, Sprecheransicht oder Multi-Speaker-Ansicht. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://library.zoom.com/technical-library/de/erweiterte-enterprise-services/zoom-mesh/zoom-mesh-functionality.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.