Ogni installatore VoIP si è trovato, almeno una volta, ad affrontare problemi legati all’improvvisa caduta della chiamata dopo pochi secondi di conversazione. In tutti questi casi, la chiamata si interrompe generalmente con un messaggio BYE trasmesso da parte del chiamato. È fondamentale sottolineare che questa richiesta di BYE non viene attivata dall'utente finale, ma direttamente dal PBX, un'operazione eseguita automaticamente a livello SIP dal sistema. La caduta della chiamata in queste circostanze, dove il flusso multimediale è già stato scambiato e l'INVITE iniziale con il 200 OK (entrambi contenenti le segnalazioni SDP) sono stati trasmessi, indica un errore nell'impostazione della chiamata SIP. La disconnessione automatica è infatti esplicitamente prevista dalla RFC3261 in caso di assenza dell’ACK, un meccanismo di sicurezza per evitare sessioni zombie. Questa decisione di terminare automaticamente la chiamata, a prescindere dalla volontà e dal controllo dell’utente finale, indica chiaramente una problematica sottostante nelle impostazioni SIP.
La Mancanza dell'ACK e il Suo Impatto sulla Stabilità della Chiamata
La problematica principale spesso risiede nella mancata ricezione della conferma (ACK) da parte del chiamante relativa al ricevimento del 200 OK. Senza entrare in tutti i dettagli, è cruciale comprendere come l’ACK venga instradato dal chiamante al dispositivo finale del chiamato. L’ACK viene reindirizzato al chiamato in base alle intestazioni (header) Record-Route e Contact contenute nella risposta 200 OK.
Le intestazioni Record-Route, presenti nel 200 OK, sono generalmente le meno responsabili di problemi, poiché vengono inserite nel messaggio SIP dai proxy visitati e non vengono quasi mai modificate. Supponendo di trovarsi in uno scenario con un centralino IP dietro NAT, possiamo normalmente scartare la possibilità di avere un Record-Route corrotto. Il principale sospetto ricade quindi sull’intestazione “Contact” presente nel 200 OK. Questa intestazione viene inserita nel 200 OK dal dispositivo finale del chiamato e può essere modificata da un router, firewall o proxy presente nel tragitto percorso dal messaggio SIP di risposta. La modifica errata di questa intestazione è una causa comune della perdita dell'ACK.
L’assenza di ACK comporta, secondo le specifiche RFC, l’attivazione del timer di tipo F, che scadrà dopo 32 secondi esatti (Timer4 T1*64 volte = 500×64 = 32 secondi). Questo spiega la frequente caduta delle chiamate dopo un intervallo di tempo così specifico. La comprensione di questo meccanismo è fondamentale per la diagnosi e la risoluzione del problema.
Un esempio di chiamata SIP con assenza di conferma ACK dopo il 200 OK mostrerebbe un INVITE seguito da un 200 OK, ma senza il successivo ACK. Una chiamata regolare, invece, alla risposta di 200 OK segue la conferma ACK, stabilendo correttamente la sessione. L’analisi di questi dati, tipicamente attraverso un'acquisizione di pacchetti, permette di riscontrare l’anomalia e trovare una soluzione mirata.
15.Protocolli TCP & UDP - Corso Ethical Hacking italiano - 2020
Identificazione e Soluzione dei Problemi di Caduta Chiamata a 32 Secondi
La caduta improvvisa delle chiamate a 32 secondi rappresenta sicuramente uno dei casi di malfunzionamento più frequenti. Questo fenomeno si presenta perché il NAT non funziona correttamente. Nella maggior parte dei casi, ciò avviene perché i router/firewall impediscono il transito degli ACK. Un’analisi dettagliata del flusso SIP, idealmente con strumenti come Wireshark, è indispensabile per diagnosticare con precisione la causa.
È possibile che una chiamata attiva (in corso), dopo il classico periodo di 32 secondi, cada perché il messaggio SIP ACK (Conferma dell’INVITE da parte del chiamante) non è riuscito a raggiungere la destinazione desiderata entro il periodo di timeout. In questa situazione, è opportuno effettuare una cattura dei pacchetti con Wireshark per esaminare il problema e provare a diagnosticare eventuali problemi di NAT o SIP ALG. Questo tipo di errore è facilmente identificabile in quanto, al messaggio di INVITE nel tracciato .pcap acquisito con Wireshark, seguono più risposte di “200 OK” senza che sia presente la conferma ACK.
Per risolvere i problemi legati al NAT, è possibile, a seconda dei casi, modificare la regola di NAT da dinamica a statica oppure procedere a disabilitare la funzionalità di PAT simmetrico a favore di un PAT statico. Queste configurazioni assicurano che il router gestisca correttamente il reindirizzamento dei pacchetti, inclusi gli ACK. Il protocollo SIP richiede attenzione per tutti i minimi dettagli. Non è sufficiente prestare attenzione alla sola richiesta di INVITE. È sufficiente attivare le estensioni STUN e RPORT per superare questo specifico problema, migliorando la capacità del client SIP di determinare il proprio indirizzo IP pubblico e la porta utilizzata per la comunicazione, specialmente in ambienti NAT.
SIP ALG: Un Ostacolo Spesso Nascosto
L’ultima circostanza, e spesso la più difficile da diagnosticare, si verifica nel caso in cui sul router sia attivo un SIP ALG (Application Layer Gateway). Questa ipotesi è molto frequente per tutti gli apparati router che prevedono una funzionalità VoIP integrata e la presenza di porte analogiche FXS destinate al collegamento di telefoni analogici.
Un SIP ALG è progettato per aiutare i dispositivi SIP a funzionare dietro un firewall o un router NAT riscrivendo gli header SIP e i dettagli di connessione. Tuttavia, spesso questi algoritmi sono implementati male e possono alterare i pacchetti SIP in modo scorretto, interrompendo il flusso di comunicazione e causando problemi come la caduta delle chiamate. La disabilitazione del SIP ALG sul router è spesso la soluzione a questo tipo di problema. È essenziale consultare la documentazione del proprio router per individuare e disattivare questa funzionalità.
Altre Cause Comuni di Caduta Chiamate SIP
Il protocollo SIP è ormai lo standard di riferimento per le moderne telecomunicazioni voce. A prescindere dal centralino telefonico in uso, esiste sempre la possibilità che si presentino problemi, di diversa natura, con le chiamate SIP. Ciò accade principalmente quando, nella fase di analisi preventiva all’installazione del sistema, viene omessa la valutazione di fattori determinanti per il corretto funzionamento del protocollo.
Oltre ai problemi legati all'ACK e al SIP ALG, esistono altre casistiche che possono portare alla caduta delle chiamate:
1. Limiti di Tempo Imposti dal PBX:Molti PBX VoIP, tra i parametri di configurazione del centralino, impongono un tempo limite per ogni singola chiamata effettuata. Questo limite è normalmente fissato a un’ora, ma potrebbe variare in base alle richieste o alle policy del produttore. Questo limite è dato per evitare che eventuali chiamate in sospeso continuino ad essere attive per tempo illimitato con generazione di costi indesiderati. Se le chiamate cadono sempre allo stesso intervallo (ad esempio, dopo un'ora), è probabile che questa sia la causa. La soluzione consiste nel modificare questo parametro nelle impostazioni del PBX, se le esigenze operative lo richiedono.
2. Problemi con Numerazioni Speciali o Inesistenti:Capita che alcune chiamate effettuate su alcune numerazioni speciali e non, cadano al momento della risposta senza però dare segnali di occupato o messaggi di sistema da parte del gestore. Questo potrebbe verificarsi a causa di numerazioni inesistenti o non raggiungibili oppure di errata configurazione del PBX che non si dimostra in grado di interpretare correttamente le risposte provvisorie di 180 Ringing o 183 (SDP). La specifica casistica si identifica attraverso un’analisi Wireshark, che permette di visualizzare i messaggi SIP scambiati e identificare eventuali risposte anomale. La correzione in questo caso può richiedere la verifica della validità delle numerazioni o un aggiornamento della configurazione del PBX per la gestione delle risposte provvisorie.
3. Incomprensioni dei Toni DTMF:I toni DTMF sono generati normalmente dall’apparecchio telefonico alla pressione dei tasti, ma il destinatario della chiamata, per esempio un PBX con risponditore digitale, potrebbe interpretare in maniera non corretta alcune frequenze percepite e terminare la chiamata sia essa in ingresso o in uscita. È fondamentale verificare eventuali impostazioni riferite ai toni DTMF sul proprio sistema telefonico (per le chiamate in ingresso) per ottimizzare il sistema di rilevamento. Normalmente il rilevamento dei toni DTMF raccomandato è con modalità RFC2833. Altre opzioni sono “Inband” o “Automatico”, ma potrebbero essere la causa dei problemi riscontrati di caduta chiamata, in quanto meno robuste o soggette a interferenze. Assicurarsi che entrambi gli endpoint della comunicazione utilizzino un metodo DTMF compatibile e preferibilmente RFC2833.
15.Protocolli TCP & UDP - Corso Ethical Hacking italiano - 2020
4. Mancanza di Pacchetti RTP in Caso di Silenzio:Alcuni server VoIP verificano la presenza di pacchetti RTP per mantenere attiva la sessione audio. In presenza di silenzio prolungato nella conversazione, si potrebbe interrompere l’invio di pacchetti RTP e, non rilevando alcun segnale, la chiamata si considera conclusa. Normalmente, il solo rumore di fondo del microfono o ambientale dovrebbe generare un minimo di pacchetti audio RTP, sufficiente a mantenere la sessione attiva. Potrebbe però succedere che, mettendo in Mute il microfono del telefono o attivando la soppressione di rumore o il VAD (Voice Activity Detection, per diminuire l’occupazione di banda), il dispositivo non trasmetta alcun pacchetto RTP, facendo fallire la chiamata. Alcuni telefoni hanno funzionalità di trasmissione pacchetti RTP anche in modalità muto o silenzioso, ma deve essere abilitata. La disattivazione del VAD o l'attivazione della trasmissione di pacchetti RTP "comfort noise" anche in silenzio può risolvere questo problema.
Strumenti di Diagnosi: L'Importanza di Wireshark
In molte delle casistiche descritte, l'uso di uno sniffer di rete come Wireshark è uno strumento diagnostico insostituibile. Effettuare una cattura dei pacchetti sul flusso SIP/RTP permette di visualizzare in dettaglio ogni singolo messaggio scambiato tra gli endpoint e i dispositivi intermedi. Analizzando il tracciato .pcap, è possibile identificare:
- INVITE senza ACK: La presenza di 200 OK ripetuti senza il successivo ACK è una chiara indicazione di un problema di instradamento dell'ACK o di un SIP ALG difettoso.
- Intestazioni SIP alterate: Esaminare gli header "Contact" e "Record-Route" nel 200 OK può rivelare modifiche indesiderate da parte di router o firewall.
- Risposte SIP anomale: Codici di risposta SIP non standard o inaspettati (es. 4xx, 5xx) possono indicare problemi di configurazione del PBX o di compatibilità.
- Flusso RTP: Verificare la presenza e la continuità dei pacchetti RTP può aiutare a diagnosticare problemi legati alla soppressione del silenzio o alla modalità muto.
- Toni DTMF: L'analisi del flusso RTP può mostrare se i toni DTMF vengono trasmessi correttamente e nel formato atteso (RFC2833).
La capacità di un installatore di utilizzare efficacemente Wireshark è fondamentale per la risoluzione rapida ed efficiente dei problemi di caduta chiamata in ambienti VoIP.
Best Practice per una Configurazione Robusta
Per minimizzare i problemi di caduta chiamata con dispositivi come il Mediant 500L o qualsiasi altro PBX SIP, è consigliabile adottare le seguenti best practice:
- Disabilitare il SIP ALG: Su tutti i router e firewall coinvolti nel percorso della chiamata, disabilitare sempre la funzione SIP ALG, a meno che non sia specificamente richiesta e si abbia la certezza della sua corretta implementazione.
- Configurare NAT in modo Statico: Laddove possibile, optare per regole NAT statiche o port forwarding specifici per le porte SIP (solitamente 5060 UDP/TCP) e RTP (un range di porte UDP, es. 10000-20000). Evitare PAT simmetrico se crea problemi.
- Utilizzare STUN/RPORT: Abilitare le estensioni STUN e RPORT sui dispositivi SIP client e sul PBX, se supportate, per facilitare il superamento dei problemi di NAT.
- Verificare i Timer SIP: Assicurarsi che i timer SIP (inclusi i timer di sessione e i keep-alive) siano configurati in modo appropriato e compatibile tra tutti i dispositivi.
- Preferire RFC2833 per DTMF: Configurare i dispositivi per l'uso del metodo RFC2833 (out-of-band) per la trasmissione dei toni DTMF.
- Gestione del Silenzio: Verificare che i telefoni e i gateway non interrompano completamente la trasmissione di pacchetti RTP in caso di silenzio prolungato (es. configurando "comfort noise" o disabilitando VAD se necessario).
- Aggiornamenti Firmware: Mantenere aggiornato il firmware di router, firewall e dispositivi VoIP per beneficiare delle ultime correzioni di bug e miglioramenti.
- Monitoraggio: Implementare strumenti di monitoraggio della qualità delle chiamate e del traffico SIP/RTP per identificare proattivamente eventuali anomalie.
Adottando un approccio metodico nella diagnosi e applicando queste soluzioni, è possibile garantire una maggiore stabilità e affidabilità delle comunicazioni VoIP, riducendo significativamente le problematiche legate alle chiamate che cadono improvvisamente.