Nextcloud Talk: Funzionalità, Integrazioni ed Infrastruttura - Terza Parte - RIOS
Nextcloud Talk: Funzionalità, Integrazioni ed Infrastruttura - Terza Parte
07 novembre 2022
Introduzione
Dopo la nostra carrellata sulle funzionalità (capitolo 1 della serie) e sulle integrazioni di Talk (capitolo 2 della serie), passiamo ora a trattare gli aspetti infrastrutturali, di particolare rilevanza per le organizzazioni che scelgono un’installazione on-premise.
Elementi costitutivi
Le funzionalità di comunicazione in tempo reale, cioè chiamate e videochiamate, si basano su protocollo WebRTC. Di natura peer-to-peer, questo protocollo permette di connettere direttamente tra di loro i dispositivi dei partecipanti ad una chiamata, senza bisogno di un sistema centralizzato. Sicuramente questo aspetto rappresenta un vantaggio quando ci limitiamo a chiamate con 2-3 partecipanti, ma osserviamo che non ha delle buone proprietà di scalabilità, in quanto il numero di connessioni, entranti e uscenti da ogni dispositivo, aumenta proporzionalmente al quadrato del numero di partecipanti.
Per ovviare a questa ed altre limitazioni, l’applicazione Talk si avvale di un sistema centralizzato, chiamato Talk High Performance Backend (Talk HPB), composto da due sotto-sistemi:
Janus, in veste di Gateway WebRTC (anche chiamato Media Server), si occupa di ricevere tutti i flussi (audio, video, schermo) degli emittenti (“publishers”) dai dispositivi partecipanti e trasmetterli ai dispositivi dei riceventi (“subscribers”). È sviluppato e manutenuto dall’azienda italiana Meetecho come progetto Open Source e adattato a Talk dal partner di Nextcloud, Struktur.
Signaling Server Stand-alone, in veste di server di segnalazione, si occupa di trasmettere i messaggi tra i partecipanti e fa da tramite tra il server Nextcloud e il server Janus. Se durante una chiamata cambiamo qualche proprietà della nostra connessione (es. disabilitiamo il microfono), il Signaling Server si incarica di trasmettere e consegnare l’informazione a tutti gli altri partecipanti. È sviluppato e manutenuto Struktur.
Pensando in particolare ad ambienti produttivi, due servizi addizionali si rendono necessari, principalmente per due fattori:
La rotta di comunicazione tra l’emittente ed il server Janus si stabilisce su una porta aleatoria compresa in un range predefinito e con protocollo UDP. In alcune reti aziendali, la politica di sicurezza potrebbe impedire connessioni uscenti che non siano di tipo TCP e/o connessioni uscenti che non avvenagno su porte standard, per esempio la 443. In questo caso si raccomanda di introdurre un server TURN (Transversal Using Relays around NAT), che accetta pacchetti TCP o UDP su un’unica porta e li trasmette al server Janus in UDP, come se fosse il partecipante.
Il Talk HPB deve poter conoscere l’IP pubblico dei partecipanti, che spesso è l’IP del router della rete locale in cui sono situati. Il server STUN (Session Traversal Utilities for NAT) ha esattamente questo compito, di poter fornire l’IP pubblica al dispositivo che lo richiede e di cui necessita per partecipare ad una chiamata.
CoTURN, l’implementazione del servizio TURN raccomandata, ha l’ulteriore vantaggio di fornire anche il servizio STUN.
Nella seguente schermata, possiamo osservare l’architettura di produzione basica di Talk, con gli elementi infrastrutturali appena introdotti.
Per capire bene il processo di connessione e di trasmissione dei media, ripercorriamo i vari eventi che si succedono quando un utente inizia una chiamata:
L’utente, connesso al server Nextcloud tramite app o navigatore, inizia una chiamata.
Tale evento è inviato dal dispositivo dell’utente al Signaling Server, che crea una connessione al Janus, corrispondente alla chiamata.
A questo punto l’utente, che vuole emettere e/o ricevere audio e/o video, prova a connettersi direttamente al Janus. Il primo tentativo è effettuato direttamente verso Janus stesso, su una porta aleatoria con protocollo UDP. Se questo non funziona prova a connettersi all’unica porta definita nel TURN Server con UDP. Se questo non funziona prova a connettersi all’unica porta definita nel TURN Server con TCP, eventualmente anche con certificato TLS.
A questo punto dovrebbe risultare chiaro che durante l'inizializzazione di (o la connessione a) una chiamata c’è una fase di raccolta delle rotte candidate, ognuna con una certa priorità, che finisce con l’identificazione della miglior rotta e l’inizio del flusso di comunicazione.
Consumo di banda
Il lettore esperto avrà già sospettato che un’applicazione per chiamate e videoconferenze come Talk può caratterizzarsi per un consumo di banda notevole. Cerchiamo quindi di trattare brevemente questo aspetto.
Se indichiamo con vv la velocità di trasmissione del video e np il numero dei partecipanti possiamo compilare la tabella seguente in cui si indica il traffico entrante ed uscente che genera una chiamata con np partecipanti sia nel server Janus che nel dispositivo del partecipante:
| Janus | Partecipante | |
|---|---|---|
| Entrante | vv*np*(np-1) | vv |
| Uscente | vv*np | vv*(np-1) |
Notando che vv = 1 Mbit/s di default, concretizziamo con due esempi:
100 videochiamate simultanee così distribuite: 50 con 2 partecipanti, 30 con 4 e 20 con 6.
Con la configurazione di default il consumo di banda massimo del server Janus è:
uscente: 1060 Mbit/s
entrante: 340 Mbit/s
Webinar: 2 oratori alternando condivisione video e schermo, tutti gli altri solo ascoltando e vedendo lo schermo condiviso dall’oratore.
Con la configurazione di default il consumo di banda massimo del server Janus è:
uscente: 207 Mbit/s
entrante: 3 Mbit/s
Osserviamo che questi sono esempi approssimati: da un lato, possiamo abbassare la velocità di transmissione del video senza particolare impatto nella qualità. Dall’altro Talk consta di algoritmi avanzati di controllo della qualità della chiamata che permette di aumentare o diminuire la velocità di trasmissione del video in tempo reale, basandosi sulla monitorizzazione continua di differenti parametri di qualità.
È inoltre rilevante ricordare che una parte più o meno importante del flusso in streaming sarà dirottato sul TURN server, dipendendo della configurazione di rete scelta e delle politiche di sicurezza che si applicano ai dispositivi dei partecipanti.
I benefici di un abbonamento enterprise a Nextcloud Talk sono i seguenti:
installazione ed aggiornamenti del software semplificati grazie all’accesso ai repository di software (APT o YUM) mantenuti e certificati da Struktur sugli OS più diffusi. Senza accesso ai suddetti repository, l’operatore dovrà compilare da sorgente tutte le componenti facendo attenzione a garantire alla compatibilità d’integrazione tra le diverse librerie utilizzate.
Accesso alla documentazione aziendale, che copre tutorial d’installazione passo a passo, requisiti hardware e software dettagliati ed altri aspetti operazionali importanti, come sicurezza e monitoraggio.
Installazione del SIP Bridge, (unica) componente proprietaria, sviluppata da Struktur, che permette l’accesso alle conferenze da rete telefonica.
Come tutte le altre componenti di Nextcloud, accesso al supporto garantito dagli ingegneri che hanno sviluppato il software.
Accesso ad un servizio d’installazione “chiavi in mano” erogato da Nextcloud stessa o un partner ufficiale.
Accesso ai consulenti Nextcloud, che accompagnano i clienti nelle varie fasi del progetto: concetto, prima implementazione e produzione.
Scalabilità ed alta disponibilità
All’aumentare il numero di utenti, aumenta in proporzione anche il carico sui server centrali che garantiscono il corretto funzionamento del servizio. Da quanto descritto in precedenza, il sistema che lavora di più è Janus, che deve gestire un numero di connessioni che cresce con il quadrato del numero di partecipanti. Inoltre, anche il consumo di banda passante può crescere notevolmente.
In questa situazione possiamo espandere il sistema come segue.
Per quanto riguarda il Signaling Server, novità introdotta con la versione 1.0.0 del software rilasciata ad Agosto 2022, possiamo ora creare una batteria di nodi sia a scopi di alta disponibilità che per scalabilità.
Introduciamo due o più server Janus, separandoli quindi dal (o dai) Signaling Server, ovvero li mettiamo in macchine dedicate.
Introduciamo un Signaling Proxy per server Janus, che fa da tramite tra il Signaling Server ed il Janus corrispondente.
Questa modalità di espansione del sistema permette di distribuire gli emittenti su diversi server Janus, anche nella stessa chiamata, garantendo allo stesso tempo che tutti i riceventi da un dato emittente finiscano nel server Janus assegnato a quest'ultimo.
Osserviamo, inoltre che, per ottimizzare la latenza in ambienti con nodi distribuiti in maniera globale, possiamo utilizzare il servizio di geolocalizzazione MaxMind per ridirigere l’utente verso il Signaling Proxy della sua regione, proprietà che dobbiamo associare ad ogni Signaling Proxy nel file di configurazione.
Uno schema semplificato di un’installazione scalabile di Talk è riportato di seguito:
Ricordiamo infine che il Talk HPB supporta il concetto di multi-tenancy. Pertanto una stessa installazione può servire a diverse istanze di Nextcloud totalmente indipendenti. Ognuna avrà la sua chiave privata di autenticazione al servizio ed un numero massimo di utenti simultanei.
Operatività
Esponiamo infine brevemente le opzioni più importanti di amministrazione dell’applicazione Talk.
L’amministratore dell’istanza troverà le configurazione di amministrazione, come per tutte le altre app, in settings/admin/talk e da lì potrà definire i parametri d’accesso ai vari servizi introdotti in precedenza: Server STUN, Server TURN, Talk HPB, SIP.
L’installazione di Talk è anche configurabile da linea di comando grazie al programma occ. Possiamo gestire (aggiungere, rimuovere, mostrare a schermo) il Server STUN, Server TURN ed il Signaling Server ed inoltre mostrare le chiamate attive, gestire le conversazioni ed i partecipanti. Per ottenere una panoramica dei vari comandi a disposizione, bisognerà semplicemente eseguire occ talk: da linea di comando.
A titolo di esempio, il seguente comando restituirà, in formato Json, le chiamate che in questo istante sono attive nell’istanza:
occ talk:monitor:calls --output json
Questa informazione risulta utile a fini di monitoraggio.
Conclusione
In questa serie di articoli abbiamo trattato di Talk abbordandolo da tre punti di vista: funzionalità, integrazioni ed infrastruttura.
Per quanto riguarda le funzionalità, abbiamo mostrato come Talk sia diventato senz’ombra di dubbio uno strumento di chat e videoconferenze completo e maturo, che permette alle aziende ed enti pubblici di offrire un’esperienza di comunicazione fluida ed immediata.
Per le organizzazioni che optano per l’utilizzo, parziale o totale, di Nextcloud Hub, l’esperienza utente è addirittura superiore, grazie alle integrazioni che arricchiscono Talk come app nativa della piattaforma. Files, Deck, Calendario, Ricerca unificata, notifiche ed attività.. abbiamo rivisitato alcuni degli esempi danno un impulso notevole alla produttività.
Infine, come punto fondamentale nel caso di un servizio da gestire su infrastruttura propria, abbiamo esposto gli aspetti infrastrutturali più importanti. Possiamo partire da un server unico, contenente Talk HPB e servizio TURN, per poi espandere l’erogazione del servizio a grandi quantità di utenti, grazie ad un modello di scalabilità chiaro, performante e rodato.
Il team di Nextcloud GmbH, in collaborazione coi numerosi partner sul territorio, come ITServiceNet, sarà a disposizione di ogni azienda, organizzazione o ente pubblico, interessati ad approfondire su quanto esposto in questi articoli.