> 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-explainer/zoom-mesh-functionality.md).

# Zoom Mesh-Funktionalität

Dieser Abschnitt enthält zusätzliche Informationen zur Zoom Mesh-Funktionalität.

### Übergeordnete-Untergeordnete-Funktionalität

Die folgenden Abschnitte bieten zusätzliche Informationen zu übergeordneten und untergeordneten Beziehungen innerhalb eines Mesh-Netzwerks.

#### <mark style="color:blau;">Zoom Mesh erstellt standardmäßig ein Netzwerk ausschließlich für Benutzer innerhalb desselben Kontos</mark>

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 erlauben, sofern das Konto des externen Benutzers *ebenfalls* es ihnen [ermöglicht, sich mit dem Mesh-Netzwerk eines anderen Kontos zu verbinden](https://support.zoom.us/hc/en-us/articles/14925064423693-How-to-enable-Zoom-Mesh-Guest-Access).

#### <mark style="color:blau;">Übergeordnete und untergeordnete Rollen werden vom Zoom Mesh Cloud Orchestration Service bestimmt</mark>

Der Zoom Mesh Cloud Orchestration Service (COS) ist ein Clouddienst, der für die Definition übergeordneter und untergeordneter Client-Rollen innerhalb eines Netzwerks verantwortlich ist. Der Cloud Orchestration Service berücksichtigt zahlreiche Datensätze, um geeignete übergeordnete Clients zu bestimmen, darunter:

{% columns %}
{% column %}

* CPU-Auslastung
* CPU-Typ
* RAM-Auslastung
* Historische Mesh-Leistung
  {% endcolumn %}

{% column %}

* Geräteverfügbarkeit (Ein/Aus)
* Geräte-Opt-in/Opt-out
* Betriebssystem
  {% endcolumn %}
  {% endcolumns %}

Anhand dieser Datensätze bewertet der COS die Ergebnisse eines Benutzers nach einem Bewertungsschema: Je höher die Punktzahl eines Benutzers, desto wahrscheinlicher wird der Client als übergeordneter Client ausgewählt; je niedriger die Punktzahl, desto unwahrscheinlicher.

#### <mark style="color:blau;">Die Zuordnung von übergeordneten und untergeordneten Clients ist dynamisch und kann sich im Verlauf eines Events ändern</mark>

Im Verlauf eines Meetings oder Webinars kann sich die Client-Zuordnung eines Benutzers je nach Leistung oder Nachfrage ändern.

Wenn beispielsweise bei einem Event 100 Teilnehmer anwesend sind, werden möglicherweise nur 10 übergeordnete Clients benötigt, um die Verteilungsanforderung zu erfüllen, während die verbleibenden 90 Benutzer als untergeordnete Clients umverteilte Streams erhalten. Steigt die Teilnehmerzahl des Events jedoch auf 200, können Clients, die zuvor untergeordnete Clients waren, zu übergeordneten Clients hochgestuft werden, um der gestiegenen Nachfrage gerecht zu werden.

Wenn ein übergeordneter Client hingegen eine verschlechterte Leistung aufweist, kann der Client auf den Status eines untergeordneten Clients herabgestuft werden, und ein neuer übergeordneter Client wird zugewiesen.

#### <mark style="color:blau;">Das Verhältnis von übergeordneten zu untergeordneten Clients wird dynamisch durch die Hardware- und Netzwerkleistung jedes Geräts bestimmt</mark>

Während eines Events wird das Verhältnis zwischen übergeordneten und untergeordneten Clients dynamisch auf Grundlage der laufenden Netzwerk- und Hardwareleistung des Geräts aktualisiert.

Wenn ein Gerät beispielsweise eine geringe Hardwareauslastung (CPU/RAM) bei einer hohen Uplink-Kapazität der Bandbreite aufweist, ist das Gerät ideal für die Rolle eines übergeordneten Clients und kann mit mehreren anderen Geräten eine übergeordnete-untergeordnete Beziehung herstellen. In diesem Szenario kann der übergeordnete Client versuchen, Medien an andere Geräte umzuverteilen, solange das Gerät nicht überlastet ist oder seine Leistung sich nicht verschlechtert. Wenn jedoch die Netzwerk- oder Hardwareleistung des Geräts nachlässt, kann es seine Zuordnung als übergeordneter Client aufgeben und wieder in die Rolle eines untergeordneten Clients wechseln.

#### <mark style="color:blau;">Jedem untergeordneten Client werden zwei übergeordnete Clients zugewiesen</mark>

Untergeordnete Clients, die mit einem Mesh-Netzwerk verbunden sind, werden *zwei* übergeordneten Clients zugewiesen, um Ausfallsicherheit zu gewährleisten. Wenn ein übergeordneter Client ausfällt, erfolgt sofort ein Failover zum zweiten übergeordneten Client. Anschließend wird ein neuer sekundärer übergeordneter Client eingerichtet, um die Ausfallsicherheit wiederherzustellen.

#### <mark style="color:blau;">Benutzer werden nicht informiert, wenn sie mit einem Mesh-Netzwerk verbunden sind</mark>

Event-Hosts und Teilnehmer erhalten keine Benachrichtigungen in der Anwendung, wenn sie mit einem Mesh-Netzwerk verbunden sind. Mesh-Netzwerkverbindungen sind nur für einen Administrator oder autorisierten Benutzer über das [Zoom Mesh Dashboard](/technical-library/de/erweiterte-enterprise-services/zoom-mesh/zoom-mesh-explainer/zoom-mesh-dashboard.md).

#### <mark style="color:blau;">VDI-Clients können nur eine Mesh-Verbindung mit anderen VDI-Clients herstellen</mark>

Wenn Zoom Mesh mit Virtual Desktop Infrastructure (VDI) verwendet wird, können Client-Geräte nur Zoom Mesh-Verbindungen mit anderen VDI-Clients herstellen, sofern beide Benutzer ein unterstütztes VDI-Plugin verwenden. Dies ist auf technische Einschränkungen der virtuellen Infrastruktur und des Weiterleitens von Medien zwischen Geräten zurückzuführen.

<mark style="color:blau;">**VDI-Clients verteilen den Inhalt der Bildschirmfreigabe nicht in einem Mesh-Netzwerk**</mark>

Aufgrund des Designs des VDI-Clients von Zoom muss der 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.

### Zoom Mesh für Meetings-Funktionalität

Die folgenden Abschnitte beschreiben Details der Zoom Mesh für Meetings-Funktionalität.

#### <mark style="color:blau;">Mesh für Meetings verteilt das Video des aktiven Sprechers neu</mark>

Mit Zoom Mesh für Meetings wird die Bandbreitenoptimierung durch die Neuverteilung des *ausgehenden* **Videos des aktiven Sprechers** zwischen den Teilnehmern bereitgestellt, wenn sich vier oder mehr Benutzer in einem Meeting befinden. Diese Funktion **gilt nicht** für das Hochladen von Medien, und alle Benutzer laden ihre Audio-, Video- und Bildschirmfreigabe-Medien weiterhin individuell in die Zoom Cloud hoch.

{% hint style="success" %}
**Beispiel**

Wenn sich 10 Benutzer in einem Meeting mit aktiviertem Zoom Mesh befinden, können zwei übergeordnete Clients mit sieben oder acht untergeordneten Clients ausgewählt werden. Wenn der aktuelle aktive Sprecher spricht, wird der *Videostream* von der Zoom Cloud an die übergeordneten Clients übertragen und anschließend an die untergeordneten Clients innerhalb des Netzwerks neu verteilt.

In diesem Szenario **erhalten die untergeordneten Clients** den Videofeed des aktiven Sprechers nicht von der Zoom Cloud, wodurch bei Verwendung von 1080p-Video potenziell bis zu 3+ Megabit Daten pro Benutzer eingespart werden.
{% endhint %}

Das folgende Bild zeigt ein Beispiel dafür, wie ausgehende Videoinhalte des aktiven Sprechers innerhalb eines Mesh-Netzwerks neu verteilt werden.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdkHVwobxFkXOQnBfbUpeqm9an_UKIAx5aqpAORRNOrRA_B1hzqr2q4KPxQZWCd_rzYUNw5axzcgqbZz77izNTIN7eiBN_X8gkZL07N-QoKEcfXfARRGkxn4vZbiTqFsBPCdCl-?key=oAHeQx46Zvia3lTyQKLPPA" alt="Image map showing how Zoom Mesh Orchestrater works at a high level."><figcaption></figcaption></figure>

#### <mark style="color:blau;">Änderungen des aktiven Sprechers in Mesh für Meetings beeinflussen weder die übergeordneten-untergeordneten Beziehungen noch die Bandbreiteneinsparungen durch die Videoverteilung</mark>

Während der Schwerpunkt von Zoom Mesh für Meetings auf der Neuverteilung des Videofeeds des aktiven Sprechers liegt, wirken sich Änderungen des aktiven Sprechers nicht auf die Beziehungen zwischen übergeordneten und untergeordneten Clients oder auf die durch die Videoverteilung erzielten Bandbreiteneinsparungen aus. Wenn der aktive Sprecher wechselt, ändern die zugewiesenen übergeordneten Clients einfach den Videofeed, den sie neu verteilen.

{% hint style="success" %}
**Beispiel**

Wenn Maurice in einem Meeting spricht und dann Holly zu sprechen beginnt, ändert sich der Verteilungsfeed des übergeordneten Clients von Maurices Videofeed zu Hollys.

Diese Änderung beeinflusst weder, welche Benutzer-Clients derzeit als übergeordnet oder untergeordnet zugewiesen sind, noch die allgemeinen Bandbreiteneinsparungen durch die Videoverteilung; nur der neu verteilte Videofeed ändert sich.
{% endhint %}

#### <mark style="color:blau;">Die Bandbreiteneinsparungen können je nach den vom Benutzer ausgewählten Video-Layouts variieren</mark>

Obwohl Zoom Mesh die Bandbreitennutzung durch die Neuverteilung des Videofeeds des aktiven Sprechers reduziert, können die Bandbreiteneinsparungen je nach den vom Benutzer gewählten Layouts beeinflusst werden. Beispielsweise unterstützt Galerieansicht bis zu 49 Video-Feeds gleichzeitig auf dem Bildschirm, während Sprecheransicht jeweils nur einen Videofeed anzeigt. Wenn ein Benutzer ein Meeting in der Galerieansicht ansieht, profitiert er davon, dass er den einzelnen Videofeed des aktiven Sprechers über das Mesh-Netzwerk erhält, verbraucht jedoch weiterhin die üblichen Bandbreitenmengen, indem er die verbleibenden 48 Videostreams der Benutzer aus der Zoom Cloud herunterlädt.

Für optimale Bandbreiteneinsparungen wird Benutzern empfohlen, Meetings in einem möglichst webinarähnlichen Layout anzuzeigen, beispielsweise in der Multi-Speaker- oder Sprecheransicht.

### Zoom Mesh für Webinare-Funktionalität

Die folgenden Abschnitte beschreiben Details der Zoom Mesh für Webinare-Funktionalität.

#### <mark style="color:blau;">Mesh für Webinare verteilt</mark> *<mark style="color:blau;">alle</mark>* <mark style="color:blau;">Videostreams der Webinar-Hosts und Panelisten innerhalb des Netzwerks neu</mark>

Im Gegensatz zu Zoom Mesh für Meetings verteilt Zoom Mesh für Webinare alle Videostreams der Webinar-Hosts und Panelisten innerhalb des lokalen Netzwerks mithilfe von übergeordneten-untergeordneten Beziehungen neu – nicht nur die der aktiven Sprecher. Durch dieses Design profitieren alle Benutzer im Mesh-Netzwerk weiterhin von geringerem externen Bandbreitenverbrauch und erleben gleichzeitig dieselbe Videoqualität wie die anderen.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXe_yqjYBRb-GGzzQKDQo70ftoFRdV67aDmwMcRNv03kv2oP_Tk4TKwEKJBiaPX4Nz7o34p9GwxwvtP-hph3VNvZw-xg_aZDuxLmGaMpW5HQkiyuvzM5iAo-8TFMK8F8EKm73k4OnA?key=oAHeQx46Zvia3lTyQKLPPA" alt="Image map showing how Zoom Mesh Orchestrater works at a high level."><figcaption></figcaption></figure>

#### <mark style="color:blau;">Die Vorteile von Mesh für Webinare ändern sich nicht mit den Video-Layouts</mark>

Unabhängig davon, welche Video-Layouts Benutzer bei der Anzeige eines Webinars wählen, erhalten sie weiterhin die Vorteile der Videoverteilung 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 dynamically by asking a question.

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

```
GET https://library.zoom.com/technical-library/de/erweiterte-enterprise-services/zoom-mesh/zoom-mesh-explainer/zoom-mesh-functionality.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
