> 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/it/servizi-enterprise-avanzati/zoom-mesh/zoom-mesh-functionality.md).
# Funzionalità
Questa sezione descrive ulteriori informazioni sulla funzionalità Zoom Mesh.
### Funzionalità padre-figlio
Le sezioni seguenti forniscono ulteriori informazioni sulle relazioni tra padre e figlio all'interno di una rete mesh.
#### Zoom Mesh crea per impostazione predefinita una rete esclusivamente per gli utenti all'interno dello stesso account
Per impostazione predefinita, Zoom Mesh crea una rete esclusivamente per gli utenti appartenenti allo stesso account. Tuttavia, un account può opzionalmente consentire agli utenti esterni autenticati all'interno della stessa rete locale di partecipare a Mesh, a condizione che l'account dell'utente esterno *anche* consente loro di [connettersi alla rete mesh di un altro account](https://support.zoom.us/hc/en-us/articles/14925064423693-How-to-enable-Zoom-Mesh-Guest-Access).
#### I ruoli padre e figlio sono determinati dal Servizio di orchestrazione cloud di Zoom Mesh
Il Servizio di orchestrazione cloud di Zoom Mesh (COS) è un servizio cloud responsabile della definizione dei ruoli di client padre e figlio all'interno di una rete. Il Servizio di orchestrazione cloud prende in considerazione numerosi insiemi di dati per determinare i client padre idonei, tra cui:
{% columns %}
{% column %}
* Utilizzo CPU
* Tipo di CPU
* Utilizzo RAM
* Prestazioni storiche della mesh
{% endcolumn %}
{% column %}
* Disponibilità del Dispositivo (On/Off)
* Opt-in/opt-out del Dispositivo
* Sistema operativo
{% endcolumn %}
{% endcolumns %}
Utilizzando questi set di dati, il COS valuta i risultati di un utente tramite una rubrica: più alto è il punteggio di un utente, più è probabile che il client venga selezionato come padre; più basso è il punteggio, meno probabile.
#### La designazione dei client padre e figlio è dinamica e può cambiare nel corso di un Evento
Nel corso di una riunione o di un webinar, la designazione del client di un utente può cambiare in base alle prestazioni o alla domanda.
Ad esempio, in un Evento con 100 partecipanti, potrebbero essere necessari solo 10 client padre per soddisfare la domanda di ridistribuzione, mentre i restanti 90 utenti riceverebbero flussi ridistribuiti come client figlio. Tuttavia, se l'Evento aumenta a 200 partecipanti, i client che in precedenza erano client figlio possono essere promossi a client padre per far fronte alla maggiore domanda.
In alternativa, se un client padre inizia a mostrare prestazioni degradate, il client può essere declassato allo stato di client figlio e verrà assegnato un nuovo client padre.
#### Il rapporto tra client padre e figlio è determinato dinamicamente dall'hardware e dalle prestazioni di rete di ciascuna macchina
Durante un Evento, il rapporto padre-figlio tra i client viene aggiornato dinamicamente in base alle prestazioni di rete e hardware in corso del Dispositivo.
Ad esempio, se un Dispositivo mostra un basso utilizzo dell'hardware (CPU/RAM) con un'elevata capacità di uplink della larghezza di banda, il Dispositivo è ideale per un ruolo di client padre e può stabilire una relazione padre-figlio con diversi altri dispositivi. In questo scenario, il client padre può tentare di ridistribuire i media ad altri dispositivi, purché il Dispositivo non sia sovraccaricato o inizi a degradare in termini di prestazioni. Tuttavia, se le prestazioni di rete o hardware del Dispositivo iniziano a diminuire, può rinunciare alla propria designazione di client padre e tornare a un ruolo di client figlio.
#### A ogni client figlio vengono assegnati due padri
Ai client figlio connessi a una rete mesh vengono assegnati *due* client padre per la resilienza. Se un client padre si guasta, l'utente passerà immediatamente al secondo client padre. Verrà quindi stabilito un nuovo client padre secondario per ripristinare la resilienza.
#### Gli utenti non vengono informati quando sono connessi a una rete mesh
Gli host dell'Evento e i partecipanti non ricevono notifiche nel client quando sono connessi a una rete mesh. Le connessioni della rete mesh possono essere visualizzate solo da un admin o da un utente autorizzato tramite la [Dashboard di Zoom Mesh](/technical-library/it/servizi-enterprise-avanzati/zoom-mesh/zoom-mesh-dashboard.md).
#### I client VDI possono stabilire una connessione mesh solo con altri client VDI
Quando si usa Zoom Mesh con l'infrastruttura desktop virtuale (VDI), i Dispositivi client possono stabilire connessioni Zoom Mesh solo con altri client VDI, purché entrambi gli utenti utilizzino un Plug-In VDI supportato. Ciò è dovuto alle limitazioni tecniche dell'infrastruttura virtuale e al relay dei media tra i Dispositivi.
**I client VDI non distribuiscono il canale di condivisione contenuti in una rete mesh**
A causa della progettazione del client VDI di Zoom, il contenuto della condivisione schermo deve essere instradato tramite la macchina virtuale. Di conseguenza, i client VDI non possono distribuire la condivisione dei contenuti attraverso una rete mesh e devono continuare a essere distribuiti all'interno dell'infrastruttura virtuale.
### Funzionalità di Zoom Mesh per le riunioni
Le sezioni seguenti descrivono in dettaglio la funzionalità di Zoom Mesh per le riunioni.
#### Mesh for Meetings ridistribuisce il video dell'oratore attivo
Con Zoom Mesh per le riunioni, l'ottimizzazione della larghezza di banda viene ottenuta ridistribuendo il *a valle* **dell'oratore attivo** video tra i partecipanti quando quattro o più utenti sono in una riunione. Questa Funzionalità **non lo fa** si applica al caricamento dei media e tutti gli utenti continueranno a caricare individualmente il proprio audio, video e contenuti di condivisione schermo su cloud Zoom.
{% hint style="success" %}
**Esempio**
Se ci sono 10 utenti in una riunione con Zoom Mesh abilitato, possono essere scelti due client padre con sette o otto client figlio. Quando l'oratore attivo corrente sta parlando, il video di quell'utente *flusso video* verrà trasmesso da cloud Zoom ai client padre e quindi ridistribuito ai client figlio all'interno della rete.
In questo scenario, i client figlio **non** ricevono il feed video dell'oratore attivo da cloud Zoom, risparmiando potenzialmente fino a oltre 3 megabit di dati per utente quando si utilizza video a 1080p.
{% endhint %}
L'immagine seguente fornisce un esempio di come i contenuti video a valle dell'oratore attivo vengono ridistribuiti all'interno di una rete mesh.
#### Le modifiche dell'oratore attivo in Mesh for Meetings non alterano le relazioni padre-figlio né i risparmi di larghezza di banda della distribuzione video
Sebbene l'obiettivo di Zoom Mesh per le riunioni sia ridistribuire il feed video dell'oratore attivo, i cambiamenti dell'oratore attivo non influiscono sulle relazioni tra client padre e figlio né sui risparmi di larghezza di banda offerti dalla ridistribuzione video. Quando l'oratore attivo cambia, i client padre designati semplicemente cambiano il feed video che stanno ridistribuendo.
{% hint style="success" %}
**Esempio**
Se Maurice sta parlando in una riunione e poi Holly inizia a parlare, il feed di ridistribuzione del client padre passerà dal feed video di Maurice a quello di Holly.
Questo cambiamento non altera quali client utente siano attualmente designati come padre o figlio, né i risparmi generali di larghezza di banda offerti dalla ridistribuzione video; cambia solo il feed video ridistribuito.
{% endhint %}
#### I risparmi di larghezza di banda possono variare a seconda dei layout video selezionati dall'utente
Sebbene Zoom Mesh consenta di risparmiare sul consumo di larghezza di banda ridistribuendo il feed video dell'oratore attivo, i risparmi di larghezza di banda possono essere influenzati a seconda dei layout scelti dagli utenti. Ad esempio, Vista galleria supporta fino a 49 feed video sullo schermo contemporaneamente, mentre Vista oratore mostra un feed video alla volta. Se un utente sta guardando una riunione in Vista galleria, trarrà vantaggio ricevendo il singolo feed video dell'oratore attivo tramite la rete mesh, ma continuerà a consumare quantità Standard di larghezza di banda scaricando i restanti 48 flussi video degli utenti da cloud Zoom.
Per ottenere le migliori pratiche di risparmio della larghezza di banda, si consiglia agli utenti di visualizzare le riunioni con un layout il più simile possibile a quello di un webinar, come Multi-Speaker o Vista oratore.
### Funzionalità di Zoom Mesh per i webinar
Le sezioni seguenti descrivono in dettaglio la funzionalità di Zoom Mesh per i webinar.
#### Mesh for Webinars ridistribuisce *tutti* i flussi video degli host del webinar e dei relatori all'interno della rete
A differenza di Zoom Mesh per le riunioni, Zoom Mesh per i webinar ridistribuisce tutti i flussi video degli host del webinar e dei relatori all'interno della rete locale utilizzando relazioni padre-figlio, non solo quelli degli oratori attivi. Con questa progettazione, tutti gli utenti coinvolti nella rete mesh continueranno a beneficiare di un consumo ridotto di larghezza di banda esterna, pur sperimentando la stessa qualità video degli altri.
#### I vantaggi di Mesh for Webinars non cambiano in base ai layout video
Indipendentemente dai layout video che gli utenti scelgono quando visualizzano un webinar, continueranno a ricevere i vantaggi della ridistribuzione video all'interno della rete, inclusi Vista galleria, Vista oratore o Vista Multi-Speaker.
---
# 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/it/servizi-enterprise-avanzati/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 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.
