Bollettino tecnico: Fanvil e GDS Grandstream

Segnalato a entrambi i produttori il 15/07/2026

Prodotti afflitti

Sono potenzialmente afflitti tutti i telefoni Fanvil con supporto al codec H.264, compresi i posti interni serie i5 (i5x, i50x), specialmente se aggiornati a firmware recenti, quando in uso con i nuovi modelli di videocitofoni GDS e GSC di Grandstream (GDS372x, GSC356x).

Descrizione del problema

Quando il videocitofono Grandstream chiama un dispositivo Fanvil, non vi è alcun problema.
Quando è un dispositivo Fanvil a chiamare il videocitofono Grandstream, il video è interamente corrotto e non visibile.

Causa

Il firmware Fanvil più recenti dichiarano, nell’offerta SDP della chiamata SIP, il parametro packetization-mode=0 per il video H.264 — parametro che il firmware precedente non dichiarava.
Con questo valore negoziato, il flusso video H.264 ricevuto dal citofono Grandstream non viene ricostruito correttamente dal decoder del Fanvil, con conseguente corruzione dell’immagine.

Soluzione

In attesa del fix definitivo da parte dei produttori (entrambi dovranno fare la loro parte, come indicato nell’approfondimento sotto) è possibile correggere packetization-mode=0 in packetization-mode=1 grazie ad una semplice patch di configurazione scaricabile cliccando qui (o selezionando il link tramite il tasto destro, Salva con nome).

Il file andrà poi caricato nella sezione System > Configurations > Import Configurations.
Non è generalmente richiesto il riavvio.

Approfondimento tecnico

Introduzione

Quando il Fanvil chiama il citofono via SIP, negozia i parametri video nell’offerta SDP dentro l’INVITE.
Confrontando il traffico catturato con Wireshark tra firmware più datati e più recenti, la riga relativa alla parte video cambia così:

Firmware vecchio (funziona):
a=fmtp:117 profile-level-id=428028; max-br=2000

Firmware nuovo (corrotto):
a=fmtp:117 profile-level-id=428028; max-br=2000;packetization-mode=0

Cosa significa “packetization-mode”

Nello standard RTP per H.264 (RFC 6184), packetization-mode indica al ricevitore come interpretare i pacchetti video:

• mode=0 (single NAL unit): ogni pacchetto RTP deve contenere un’unità NAL H.264 completa e non frammentata.
• mode=1 (non-interleaved): permette di frammentare le unità NAL troppo grandi per un pacchetto usando il meccanismo FU-A (Fragmentation Unit).

Un keyframe H.264 (I-frame) a una risoluzione/bitrate normale è quasi sempre più grande di un singolo pacchetto RTP (MTU ~1400 byte), quindi richiede la frammentazione prevista da mode=1.

Con packetization-mode=0 negoziato, il videocitofono deve comunque spezzare il keyframe su più pacchetti, ma anziché usare la frammentazione FU-A standard, invia i frammenti etichettandoli con un header che sembra quello di una NAL unit completa invece del corretto header di frammentazione.

Verifica a livello di pacchetto RTP

Confrontando il tipo di NAL unit (i primi 5 bit del byte dopo l’header RTP) nel flusso video:

I byte di payload dei pacchetti “tipo 5” nel caso corrotto risultano identici, byte per byte, ai byte trasportati nei frammenti FU-A del firmware vecchio: è lo stesso frammento di dati, cambia solo l’etichetta che lo accompagna.
Nel caso funzionante il pacchetto è marcato correttamente come frammento (FU-A) di un NAL tipo 5; nel caso corrotto lo stesso frammento viene spedito con un header che dichiara (falsamente) di essere un NAL intero: il decoder del Fanvil non ha quindi modo di riassemblare i pacchetti e li tratta come fotogrammi indipendenti, da cui i blocchi di colore casuale.