Se gestite conferenze in HCL Sametime 12.0.3, potreste aver notato che lo streaming video salta o si blocca quando tra i partecipanti ci sono utenti che utilizzano Firefox.
Il problema
Il comportamento è legato a come Sametime gestisce i flussi video tramite Jitsi VideoBridge (JVB). Firefox, rispetto a Chrome, può avere difficoltà con il Simulcast, la tecnica che invia più flussi video a differenti risoluzioni contemporaneamente. Questo permette un uso più efficiente della banda, ma può generare instabilità in un meeting (si vedono altri utenti a cui salta la videocamera in pratica).
La soluzione corretta e testata
HCL consiglia di disabilitare il Simulcast, che risolve il problema su Firefox. Con Sametime in ambiente Docker, la procedura corretta è:
1. Aprire il file custom.env nella configurazione di Sametime.
2. Inserire la seguente riga: ENABLE_SIMULCAST=false
3. Salvare il file.
4. Riavviare Nginx con Docker Compose: docker-compose up -d nginx
Dopo questa modifica, lo streaming video torna fluido anche con utenti Firefox
Perché funziona
Disabilitando Simulcast, Jitsi VideoBridge invia un solo flusso video a tutti i partecipanti, evitando problemi di compatibilità tra browser e semplificando la gestione dei flussi video durante le conferenze. Questo migliora la stabilità senza compromettere l’esperienza utente.
Versione JVB in Sametime 12.0.3
La versione di Jitsi Videobridge inclusa in Sametime 12.0.3 è:
· jvb: 2.3.105-ge155b81e
Conclusione
Se le vostre conferenze prevedono partecipanti sia su Chrome che su Firefox, impostare ENABLE_SIMULCAST=false nel custom.env e riavviare Nginx con Docker Compose è il modo più rapido per garantire uno streaming video stabile.
Per dettagli ufficiali, consultate la KB HCL: KB0127923.
Note Tecniche su JVB (Jitsi)
Il passaggio dalla versione 2.3.105 (rilasciata intorno a maggio 2024 e integrata in Sametime 12.0.3) alla versione 2.3-270 (di inizio 2026) rappresenta un salto tecnologico di circa un anno e mezzo di sviluppo nel mondo Jitsi.
In questo intervallo, Jitsi Videobridge (JVB) ha ricevuto numerosi aggiornamenti focalizzati sulla stabilità delle conferenze ad alta densità e sulla transizione definitiva verso nuovi protocolli di segnalazione.
1. Evoluzione del Protocollo: Colibri2
La differenza più significativa riguarda la maturazione di Colibri2. Mentre nella versione 105 era già presente ma spesso in coesistenza con il vecchio Colibri1, nella versione 270 il supporto è molto più raffinato:
· Riduzione del carico di segnalazione: Colibri2 ottimizza il modo in cui il bridge comunica con Jicofo (il componente che gestisce le sessioni), riducendo i tempi di "join" dei partecipanti.
· Gestione degli endpoint: Migliore gestione della creazione e distruzione degli endpoint, risolvendo bug che in passato causavano "fantasmi" (partecipanti che apparivano ancora connessi anche se usciti).
2. Performance e Gestione Media
Tra le build 105 e 270 sono state introdotte ottimizzazioni cruciali per la qualità video:
· Miglioramenti al Bandwidth Estimation (BWE): La versione 270 include algoritmi più aggressivi per il recupero dei pacchetti persi e per l'adattamento della risoluzione in caso di connessioni instabili.
· Supporto AV1 (Sperimentale/Migliorato): Sebbene dipenda dai browser, le versioni più recenti del bridge gestiscono meglio il codec AV1, che offre una qualità superiore con un consumo di banda inferiore rispetto a H.264 o VP8.
· Fix per il Simulcast: Corretti diversi problemi legati allo switching dei flussi video (es. quando si passa dalla visualizzazione a griglia a quella dell'oratore principale), rendendo il passaggio più fluido e senza interruzioni di "schermo nero".
3. Diagnostica e Monitoraggio
Se il supporto HCL ha indicato la versione come un problema, potrebbe essere legato alla visibilità dei guasti:
· Debug State Exporter: È stata aggiunta una funzione (debugState) che permette di esportare lo stato interno del bridge in modo più granulare (utile per il supporto tecnico per capire perché una chiamata è caduta).
· Stats Reporting: Migliorata la precisione delle statistiche inviate a sistemi come Grafana o Prometheus, inclusi nuovi parametri sul ritardo dei pacchetti (RTT) e sul jitter.
4. Sicurezza e Infrastruttura
· Aggiornamenti Java (JRE): Le build più recenti sono ottimizzate per versioni di Java più nuove (Java 17/21), risolvendo vulnerabilità di sicurezza e migliorando la gestione della memoria (Garbage Collection).
· Octo (Cascading): Se utilizzi più bridge (architettura distribuita), la versione 270 corregge bug critici nel relay dei pacchetti tra bridge situati in zone geografiche diverse.
Il problema di Firefox nella versione di Sametime 12.0.3 (che utilizza la build JVB 2.3.105) è ben noto alla community Jitsi e al supporto HCL.
Il "colpevole" principale non è solo un bug del codice, ma un cambiamento nel modo in cui Firefox gestisce la sicurezza delle connessioni (DTLS), che la versione 105 del bridge non riesce a gestire correttamente senza interventi.
Ecco le differenze tecniche cruciali che risolvono il problema nella versione 2.3-270 rispetto alla 2.3.105:
1. Incompatibilità DTLS 1.3 (Il problema principale)
A partire dalla versione 126, Firefox ha aggiornato il protocollo di sicurezza predefinito per il WebRTC a DTLS 1.3 (o ha modificato i parametri di negoziazione).
· Nella build 2.3.105: Il bridge utilizza una versione della libreria Bouncy Castle e uno stack DTLS che spesso fallisce la "stretta di mano" (handshake) con le versioni moderne di Firefox. Il risultato è che la chiamata sembra connettersi, ma non c'è né audio né video (schermo nero).
· Nella build 2.3-270: Lo stack DTLS è stato aggiornato per supportare correttamente le specifiche richieste dai browser più recenti, garantendo che il tunnel criptato per i media si stabilizzi correttamente.
2. Gestione degli Header DD (Dependency Descriptor)
Esiste un bug specifico (identificato come Issue #2319 nei log Jitsi) che riguarda il modo in cui il JVB inoltra i flussi video di Firefox:
· Il Problema: Firefox ha iniziato a inviare metadati video (Dependency Descriptors) che la build 105 non interpreta correttamente. Questo causa spesso la perdita di pacchetti video o l'impossibilità per gli altri partecipanti di vedere l'utente Firefox.
· La Soluzione: La versione 270 include il fix per il corretto parsing di questi header, rendendo il flusso video di Firefox stabile quanto quello di Chrome.
3. Bandwidth Estimation (BWE) e Firefox
Firefox utilizza un algoritmo di stima della banda leggermente diverso da Chromium.
· Nella build 105: In conferenze con più di 3 persone, il bridge 105 tende a "sottostimare" la banda disponibile per i client Firefox, portandoli a ricevere video a risoluzione bassissima (180p) o a disattivare del tutto la ricezione video per "risparmiare risorse", anche se la connessione è ottima.
· Nella build 270: L'allocatore di banda è stato riscritto per essere più tollerante e preciso con lo stack WebRTC di Firefox.
HCL ha dichiarato che sistemerà in HCL Sametime 12.0.4 il problema in questa technote:
https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0127923
0 Commenti:
Nessun Commento Trovato