> 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/area-admin/network-management/quality-of-service-subscription-explainer.md).

# Spiegazione dell’abbonamento alla qualità del servizio

L’abbonamento alla qualità del servizio è un prodotto add-on che fornisce i dati QoS di riunione, webinar e telefono a un endpoint di terze parti del cliente.

### abbonamento alla qualità del servizio è un prodotto add-on che trasmette metadati QoS quasi in tempo reale per Zoom Meetings, Webinars e Zoom Phone tramite sottoscrizioni di Evento

L’abbonamento alla qualità del servizio (QSS) di Zoom è un prodotto add-on che offre dati di qualità del servizio (QoS) quasi in tempo reale per Zoom Meetings, Webinar e chiamate telefoniche. QSS amplia le funzionalità di prodotto di Zoom inviando eventi QoS a livello di partecipante a intervalli a livello di minuto (velocità e aggregazione possono variare in base alla configurazione). I Clienti possono usare questo flusso di dati ricco per identificare se gli ambienti di rete stanno influenzando i servizi di Zoom.

#### <mark style="color:blu;">QSS fornisce le stesse metriche QoS sottostanti utilizzate in Zoom Dashboards e nelle API, ma il campionamento e la tempistica differiscono</mark>

L'esistente [Zoom Dashboard](https://support.zoom.us/hc/en-us/articles/204654719-Getting-started-using-the-Zoom-Dashboard-) fornisce metriche di prestazioni e utilizzo della rete, che possono aiutare i Clienti a capire come Zoom sta operando in un ambiente di rete. QSS offre gli stessi dati Zoom QoS, ma a un ritmo più rapido. A causa di questo campionamento a ritmo più rapido, le metriche QoS aggregate Mostra valori diversi dalla principale Zoom Dashboard. Tuttavia, queste metriche possono ancora consentire ai Clienti di Configura le proprie viste Dashboard per correlare i dati Zoom con sistemi aggiuntivi.

La tabella seguente descrive i dati QoS forniti agli endpoint di un cliente tramite QSS.

<table><thead><tr><th width="230"></th><th>Dati QoS forniti tramite QSS</th></tr></thead><tbody><tr><td>Metriche di qualità</td><td>Bitrate, latenza, jitter, perdita di pacchetti, risoluzione, frequenza dei fotogrammi, utilizzo della CPU</td></tr><tr><td>Metriche di utilizzo</td><td>Dispositivo, Rete, Regione di segnalazione, Versione client, audio (I/O), Video (I/O)</td></tr><tr><td>Frequenza</td><td>Circa 1 Evento al minuto, per partecipante (per metrica QoS o insieme aggregato a seconda delle Impostazioni dell'account).</td></tr><tr><td>Conservazione dei dati</td><td>I log di consegna degli Eventi vengono conservati per 7 giorni tramite la API dei log dei webhook; i dati storici QoS tramite endpoint API possono persistere più a lungo (a seconda della licenza).</td></tr></tbody></table>

#### <mark style="color:blu;">I dati di Zoom Dashboard non devono essere confrontati con i dati forniti tramite QSS a un endpoint di terze parti del cliente</mark>

QSS e Zoom Dashboard offrono due meccanismi separati per accedere ai dati QoS di Zoom che non devono essere confrontati. Sebbene Zoom Dashboard e QSS attingano dallo stesso insieme di dati QoS, i dati in ciascun meccanismo non coincideranno a causa delle differenze nel momento di recupero e nella frequenza di consegna dei dati.

#### <mark style="color:blu;">QSS supporta i dati Evento in tempo reale per Zoom Meetings, webinar e chiamate Zoom Phone</mark>

QSS fornisce dati Evento QoS per tutti gli utenti di un account per Zoom Meetings e webinar, nonché per le chiamate Zoom Phone. Poiché Zoom non gestisce l'ultimo tratto delle chiamate, QSS fornisce solo dati Evento QoS a livello di account per le chiamate Zoom Phone e pertanto non può offrire una visibilità completa sui dati avanzati end-to-end dei partecipanti.

#### <mark style="color:blu;">I dati QSS non includono dati per partecipanti esterni</mark>

QSS non fornisce dati per i partecipanti esterni alla riunione. Tuttavia, QSS può aiutare a individuare quale partecipante interno alla riunione ha avuto un problema e qual era il problema, oltre alle metriche di qualità e di utilizzo di cui i Clienti avranno bisogno per risolvere i problemi.

### QSS consente ai Clienti di portare dati grezzi di QoS da Zoom Dashboard nei loro flussi di lavoro esistenti

Sebbene in passato i Clienti Zoom abbiano potuto usare strumenti come Zoom Dashboard o le API per visualizzare o recuperare dati QoS di Zoom, QSS consente di trasmettere in streaming la telemetria QoS di Zoom nelle tue piattaforme di gestione e monitoraggio della rete tramite sottoscrizioni a Evento (webhook o WebSocket).

#### <mark style="color:blu;">QSS distribuisce eventi QoS quasi in tempo reale ai tuoi endpoint sottoscritti, riducendo il polling delle API e l'impatto dei limiti di frequenza</mark>

I Clienti di QSS possono sottoscriversi a eventi e dati QoS in tempo reale che verranno inviati ai loro endpoint dell'applicazione, il che aiuta a liberare capacità API e a ottimizzare l'utilizzo della rete. QSS è un'estensione di Zoom’s [servizio webhook standard](https://developers.zoom.us/docs/api/webhooks/) perché può inviare dati grezzi di QoS a un endpoint a una frequenza quasi in tempo reale di 4-6 volte al minuto.

#### <mark style="color:blu;">QSS consente ai Clienti di accedere a dati QoS quasi in tempo reale da Zoom Dashboard senza superare i limiti di frequenza delle API</mark>

I servizi API sono basati su richieste e usano un meccanismo “pull” per raccogliere i dati richiesti da un'app o da un utente. Le API richiedono più risorse dei webhook perché necessitano di chiamate ripetute per prelevare dati da un endpoint API.

I Clienti che utilizzano [API Zoom](https://developers.zoom.us/docs/api/) per estrarre i dati QoS da Dashboard Zoom può incontrare limiti di frequenza, il che significa che hanno raggiunto il numero massimo di chiamate API che possono effettuare in un determinato periodo di tempo. QSS non aumenta i limiti di frequenza delle API, ma riduce le preoccupazioni dei Clienti relative ai limiti di frequenza inviando i dati grezzi QoS ai loro endpoint invece di richiedere ai Clienti di estrarre i dati autonomamente.

#### <mark style="color:blu;">QSS consente ai Clienti di consumare i dati grezzi QoS di Zoom e di risolvere i problemi utilizzando il loro sistema di gestione della rete preferito</mark>

Alcuni Clienti potrebbero dover valutare le prestazioni della loro rete su più applicazioni contemporaneamente. QSS consente loro di monitorare i dati QoS di Zoom in una Dashboard insieme ad altri dati nella loro suite di applicazioni, offrendo un modo flessibile e scalabile per consumare i dati QoS di Zoom e integrarli perfettamente nelle Dashboard personalizzate.

#### <mark style="color:blu;">I dati QoS di Zoom vengono trasmessi tramite TLS 1.2</mark>

I dati QSS sono crittografati in transito usando TLS 1.2 o superiore. Gli endpoint devono usare un certificato valido dell'Autorità di Certificazione (CA). Le richieste webhook includono un'intestazione di firma e un controllo challenge-response per la Verifica.

Per una sicurezza aggiuntiva, ai Clienti verrà chiesto di [convalidare i propri endpoint webhook](https://developers.zoom.us/docs/api/webhooks/) usando un Challenge-Response Check (CRC). Il CRC confermerà la proprietà e la sicurezza dei loro URL degli endpoint di Notifica Evento.

### I Clienti possono iniziare a consumare i dati QoS creando un'applicazione in grado di ricevere Evento QSS

Dopo che un cliente acquista il piano add-on QSS, almeno un utente sull’account deve avere abilitate le autorizzazioni per sviluppatori. I Clienti possono quindi utilizzare i seguenti tre passaggi per creare una webhook applicazione che possa sottoscrivere eventi QSS.

I Clienti possono anche intraprendere il [Zoom Pacchetto per sviluppatori](https://news.zoom.com/zoom-announces-developer-pack-resale-for-channel-partners/) con un flag QSS abilitato, che include QSS insieme ad altri strumenti per sviluppatori.

{% stepper %}
{% step %}
**Crea un'app per la sottoscrizione agli Evento (OAuth generico o server-to-server). Abilita le sottoscrizioni Evento e Seleziona gli eventi QoS**

I Clienti devono prima creare un'app OAuth Generale o Server-to-Server nella [Zoom App Marketplace](https://marketplace.zoom.us/). Poi, avrebbero Abilita le Sottoscrizioni Evento e Seleziona gli Evento QoS che desiderano ricevere.

Avanti, i Clienti devono specificare la destinazione per le notifiche Evento QSS inserendo l'URL endpoint di Notifica Evento della loro applicazione

{% hint style="info" %}
Un'app solo webhook non è richiesta per questa configurazione. Zoom consiglia di creare una app generale.
{% endhint %}
{% endstep %}

{% step %}
**Iscriviti agli eventi webhook di QSS**

Per iscriversi agli eventi QSS, i Clienti devono Aggiungi eventi e Scegli dall'elenco dei QSS Disponibile **Tipi di Evento**. I Clienti possono Seleziona uno o più eventi QSS prima di completare il processo e attivare la loro applicazione.

<figure><img src="https://2272214008-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-0e6bcd7f34f9ebd6a9342919e58f15d0e72d51d0%2Fsubscribe-to-qss-webhook.png?alt=media" alt="Image of the Event types screen, focused on QSS options."><figcaption></figcaption></figure>

Puoi anche gestire gli abbonamenti tramite l'interfaccia utente di Marketplace o usando chiamate API:

* `POST /Marketplace/app/Evento_subscription – create`
* `PATCH /{id} – iscrivi utenti/account`
* `DELETE /{id} – annulla iscrizione/elimina`
* `GET /marketplace/app/Evento_subscription – elenco`

Per autenticare tramite API, utilizza un token del Client Credentials Grant.
{% endstep %}

{% step %}
**Verifica gli eventi webhook**

Dopo aver configurato le sottoscrizioni all'Evento, assicurati che sia la proprietà dell'URL del webhook sia l'autenticità dell'Evento siano convalidate correttamente.

* **Convalida dell'URL**
  * Quando Abilita per la prima volta le sottoscrizioni all'Evento, Zoom esegue un Challenge–Response Check (CRC) per verificare la proprietà del tuo endpoint webhook. Questo processo garantisce che Zoom stia inviando dati a una destinazione legittima controllata dalla tua app. (Puoi includere la gestione del CRC in una fase di configurazione precedente, se preferisci.)
* **Verifica dell'Evento**
  * Ogni Notifica di Evento in arrivo dovrebbe essere verificata dalla tua applicazione per confermare che provenga da Zoom. L'app può convalidare le richieste in arrivo utilizzando l'intestazione della firma fornita in ciascun Evento webhook. Gli sviluppatori che preferiscono un'alternativa al metodo di firma predefinito possono utilizzare una delle altre opzioni di Verifica supportate descritte nella documentazione per sviluppatori di Zoom.
  * Usa l'API Get Webhook Logs per esaminare fino a sette giorni di dati di recapito dei webhook, inclusi stato, numero di tentativi e trace ID.
    {% endstep %}
    {% endstepper %}

Per tutti i dettagli sull'implementazione, fai riferimento alla [Guida all'implementazione QSS](https://drive.google.com/file/d/1oOEUeizi5VqtMTJIn3E1dFbYcbuv-Y2n/view) per gli sviluppatori. Per i dettagli tecnici, consulta le guide all'autenticazione di API di sottoscrizione all'Evento, Webhook Logs API e Client Credentials Grant nella documentazione per sviluppatori di Zoom.


---

# 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/it/area-admin/network-management/quality-of-service-subscription-explainer.md?ask=<question>&goal=<user_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.