Il software di collaborazione self-hosted supporta chiamate vocali e video? Checklist per verificare la rete

Parti dalle chiamate di cui il tuo team ha davvero bisogno

«Supporta le chiamate» non è un requisito di deployment completo. Prima di confrontare le opzioni di hosting, definisci chi chiamerà chi, quali client userà e da dove si collegheranno gli utenti. Un team i cui membri condividono la stessa rete aziendale può incontrare vincoli diversi rispetto a un team con ospiti esterni e utenti collegati da casa o tramite rete mobile.

Verifica anche quali funzionalità sono importanti. Voce, video, condivisione dello schermo e chiamate con partecipanti esterni possono avere requisiti di supporto o configurazione diversi. La [guida al deployment di Calls di Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) descrive Calls come una funzionalità self-hosted per le chiamate audio e la condivisione dello schermo. Questa descrizione delle funzionalità, da sola, non dimostra che tutti i client o le reti degli utenti funzioneranno nel tuo ambiente.

• Elenca le funzionalità di chiamata, i tipi di partecipanti e i tipi di client necessari, ad esempio browser o applicazione nativa.
• Includi le reti che gli utenti utilizzeranno: aziendale, domestica, mobile ed eventuali reti di ospiti o partner.
• Decidi quali compromessi sono accettabili. Per esempio, se il video non si connette, è sufficiente poter passare all’audio?

Distingui accesso web, segnalazione e flussi multimediali

Un primo passo utile consiste nel consultare la documentazione ufficiale aggiornata dell’applicazione e suddividerne i requisiti in percorsi distinti. L’interfaccia web è ciò che gli utenti caricano; la segnalazione è lo scambio di informazioni utilizzato per stabilire o gestire una chiamata; i flussi multimediali trasportano audio e video. La documentazione dell’applicazione può descrivere questi percorsi separatamente o usare una terminologia diversa.

Riuscire ad accedere tramite browser conferma la disponibilità dell’accesso web, ma non dimostra necessariamente che l’avvio di una chiamata o lo scambio di flussi multimediali in entrambe le direzioni funzioneranno. Annota i requisiti documentati per ciascun percorso invece di presumere che un sito funzionante dimostri che le chiamate siano pronte all’uso.

La [descrizione di Talk di Nextcloud](https://nextcloud.com/blog/nextcloud-talk-open-source-online-video-conferencing-software/) lo presenta come un software open source per videoconferenze online che supporta chat, chiamate, webinar e trasmissioni. Questa descrizione delle funzionalità è utile per identificare l’ambito del prodotto, ma da sola non specifica la configurazione di rete necessaria per i tuoi utenti.

• Trova la documentazione di deployment del fornitore relativa all’applicazione esatta e al modello di deployment che intendi usare.
• Annota separatamente i requisiti documentati per l’interfaccia web, la segnalazione delle chiamate e i flussi multimediali.
• Verifica se i requisiti cambiano in base al client, alla funzionalità o al componente di deployment; non colmare le lacune con supposizioni.

Verifica protocolli, porte, firewall, NAT e relay

Usa la documentazione ufficiale per preparare un elenco delle modifiche di rete necessarie. Annota i protocolli e le porte specificati, se il traffico deve essere consentito in ingresso, in uscita o in entrambe le direzioni e quali sistemi o endpoint sono coinvolti. Non copiare un elenco generico di porte da un altro prodotto di collaborazione: i requisiti possono variare e le descrizioni dei prodotti disponibili non specificano valori precisi per porte o firewall.

Cerca nella documentazione indicazioni sul comportamento previsto quando i partecipanti si trovano dietro NAT o firewall restrittivi. In particolare, verifica se ci si aspetta che le connessioni multimediali dirette funzionino, se un relay TURN è supportato o necessario in alcune circostanze e chi gestisce tale relay. Se la documentazione non risponde a queste domande, considerale questioni di deployment ancora aperte e chiedi chiarimenti al fornitore dell’applicazione o dell’hosting prima del rilascio.

Un relay può essere una dipendenza, non un dettaglio facoltativo. Verifica se deve essere distribuito, se deve essere raggiungibile, configurato nell’applicazione o gestito separatamente; conferma questi aspetti nella documentazione del prodotto invece di darli per scontati. La [guida al deployment di Calls di Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) è un punto di partenza basato su una fonte primaria per Mattermost, ma le informazioni disponibili sulle funzionalità non specificano i requisiti relativi a porte, NAT o relay.

• Crea una tabella con protocollo, porta, direzione, destinazione e finalità, secondo quanto documentato.
• Chiedi agli amministratori di rete di verificare che il traffico richiesto sia consentito sulle reti aziendali e remote pertinenti.
• Conferma il comportamento documentato relativo all’attraversamento del NAT e a TURN, compresi la gestione del relay e le responsabilità operative.
• Contrassegna come non verificato ogni requisito non documentato; non considerare un accesso riuscito una prova che il traffico multimediale sia consentito.

Verifica TLS, domini e presupposti relativi al reverse proxy

Controlla come l’applicazione si aspetta che siano configurati il dominio pubblico, la terminazione TLS e gli eventuali reverse proxy. Individua il componente che gestisce ciascuna connessione e verifica se la documentazione ufficiale indica requisiti aggiuntivi per le chiamate rispetto all’interfaccia web. Non presumere che una determinata configurazione di proxy o TLS sia supportata per tutte le funzionalità di chiamata, a meno che la documentazione dell’applicazione non lo specifichi.

Una pagina HTTPS valida non costituisce un test completo del percorso della chiamata. Può dimostrare che l’endpoint web è raggiungibile, lasciando però senza verifica i requisiti di segnalazione o dei flussi multimediali. Se la tua architettura colloca un proxy davanti all’applicazione, confronta l’architettura delle chiamate descritta nella documentazione con il routing e la configurazione dei certificati effettivi, e chiarisci ogni dubbio prima di invitare gli utenti a fare affidamento sulle chiamate.

Le [informazioni sui prodotti Airbip](https://airbip.com) descrivono il routing automatico e i certificati TLS tramite Traefik e Let’s Encrypt, oltre al supporto per un sottodominio Airbip o un dominio personalizzato compatibile. Queste funzionalità descrivono la configurazione dell’hosting web; da sole non dimostrano che le funzionalità di chiamata o i percorsi dei flussi multimediali di una determinata applicazione siano supportati su tutte le reti.

• Verifica nella documentazione di deployment dell’applicazione il dominio pubblico richiesto e il comportamento TLS previsto.
• Confronta l’architettura documentata con la configurazione effettiva di proxy, DNS e certificati.
• Chiedi al fornitore o al vendor interessato di chiarire eventuali requisiti specifici per le chiamate relativi a proxy o TLS che non siano documentati.

Testa con utenti rappresentativi, non solo con il team dei server

Dopo aver implementato la configurazione documentata, esegui test sulle reti che gli utenti utilizzeranno davvero. Un test dalla stessa rete aziendale o dallo stesso ambiente del server potrebbe non rilevare le restrizioni presenti sulle reti domestiche, mobili, per ospiti o partner. Se questi utenti fanno parte del pubblico previsto, includi almeno una rete restrittiva.

Usa una checklist ripetibile: i partecipanti riescono ad avviare e unirsi a una chiamata, a sentirsi in entrambe le direzioni, a vedersi se il video è richiesto e a condividere i contenuti necessari? Verifica poi cosa succede quando una connessione viene interrotta e ripristinata. Se l’applicazione mostra se viene utilizzato un relay, annota il risultato; non dedurre l’uso di un relay dalla sola qualità della chiamata.

Un test superato dimostra che la configurazione verificata ha funzionato per gli utenti e sulle reti testate in quel momento. Non garantisce che la rete, il dispositivo o una successiva modifica di rete di ogni partecipante si comportino allo stesso modo. Le descrizioni dei prodotti citate sopra non prescrivono una procedura per testare reti rappresentative, quindi considera questa checklist come indicazione generale per il deployment, non come garanzia del prodotto.

• Testa ogni tipo di client richiesto e le funzionalità di chiamata che il team intende utilizzare.
• Esegui test con partecipanti su reti aziendali, domestiche, mobili e altre reti pertinenti, includendo, se disponibili, ambienti restrittivi.
• Registra l’avvio della chiamata, l’audio bidirezionale, il video, la condivisione dello schermo se necessaria, la riconnessione e il comportamento del relay documentato.
• Annota la data, il tipo di client, il contesto di rete e il risultato per poter confrontare i dati dopo eventuali modifiche.

Scegli il modello di deployment sulla base di requisiti verificati

Confronta le opzioni di hosting solo dopo aver consultato i requisiti documentati dell’applicazione e aver stabilito quali controlli di rete puoi ottenere. Valuta se puoi configurare le regole firewall necessarie, gestire o procurarti eventuali servizi relay richiesti e indagare sui problemi che si verificano sulle diverse reti degli utenti.

Un deployment gestito dell’applicazione può occuparsi di alcune parti dell’infrastruttura, ma non dimostra automaticamente che siano supportate tutte le funzionalità di chiamata o tutti i percorsi di rete. Le [informazioni sui prodotti Airbip](https://airbip.com) descrivono istanze applicative eseguite come workload Docker sui suoi server cloud, insieme alla gestione del ciclo di vita dei servizi, ai controlli DNS e ai backup configurabili con frequenza giornaliera, settimanale e mensile. Valuta queste funzionalità insieme ai requisiti specifici per le chiamate, non al loro posto, verificandoli nella documentazione dell’applicazione.

Se il tuo team non può fornire un controllo di rete o un servizio relay necessario, o non è in grado di gestire le differenze tra le reti degli utenti, un altro modello di deployment o un servizio progettato per il caso d’uso potrebbe essere più adatto. Basa la scelta sui requisiti verificati, non sulla presenza di un pulsante per le chiamate o su un accesso web riuscito.

• Assegna ogni requisito documentato a un responsabile: il tuo team, il fornitore dell’hosting o il vendor dell’applicazione.
• Conferma le dipendenze da relay e dai controlli di rete prima di impegnarti in un deployment.
• Scegli un altro modello se non è possibile soddisfare una funzionalità o una responsabilità operativa necessaria.

Documenta le responsabilità e ripeti i test dopo le modifiche

Conserva una registrazione sintetica dell’architettura, dei protocolli e delle porte documentati, della configurazione di DNS e TLS, del reverse proxy, delle dipendenze da relay e dei responsabili di ogni modifica. Includi una procedura per la risoluzione dei problemi, così gli utenti sapranno dove segnalare i malfunzionamenti e gli amministratori potranno distinguere i problemi di accesso web da quelli di avvio delle chiamate o dei flussi multimediali.

Pianifica di ripetere i test con utenti rappresentativi dopo modifiche all’applicazione, all’hosting, al proxy, al firewall, al relay o alla rete degli utenti. Una verifica documentata e ripetibile è più utile che considerare una singola riunione riuscita come una garanzia permanente.

• Annota la documentazione di riferimento e la data in cui è stata consultata, insieme alle eventuali domande senza risposta.
• Assegna responsabili per le modifiche al firewall, la gestione del relay, la configurazione dell’applicazione e l’assistenza agli utenti.
• Ripeti i test dopo modifiche rilevanti all’infrastruttura o alla rete e aggiorna la documentazione.