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. Affinché il protocollo SIP funzioni correttamente, è necessario rispettare una serie di regole di Routing e Networking e utilizzare apparati pienamente compatibili con l’impiego del VoIP SIP.
Identificare le specifiche casistiche in cui si verifica la caduta della chiamata SIP
La prima operazione da compiere è relativa all’identificazione del problema. >E’ sempre necessario domandarsi in quale contesto avvenga la caduta della chiamata:
- Si verifica sempre dopo un certo intervallo di tempo in maniera ripetitiva?
- Avviene solo su alcune numerazioni?
- Accade se il destinatario è un risponditore automatico?
- Si presenta dopo un tempo prolungato di silenzio nella conversazione?
- Sembra avvenire in maniera casuale, indipendentemente dal tempo di conversazione?
1. I Problemi di SIP Timer Session e la caduta della chiamata SIP a 32 secondi
La caduta improvvisa delle chiamate a 32 secondi rappresenta sicuramente uno dei casi di malfunzionamento più frequente. Si tratta di una fattispecie correlata, nella quasi totalità dei casi a problemi o errori a livello di configurazione di NAT o di apparati router/firewall impiegati.
Per comprendere perché si verifica questo tipo di errore è necessario introdurre l’argomento dei Timer SIP.
I Timer SIP T1, B e F vengono utilizzati per determinare principalmente il tempo impiegato dal dispositivo remoto per rispondere prima che il mittente lo consideri un timeout.
Quello dei 32 secondi è un intervallo di caduta delle chiamate piuttosto comune ed è sostanzialmente dettato dall’azione dei c.d. “Timer SIP”. Ecco cosa accade nel dettaglio:
Le Tipologie di Timer SIP: T1, B e F
- Il timer T1 è il tempo di andata e ritorno stimato di un pacchetto IP e il valore predefinito è 500ms per quasi tutti i sistemi SIP.
- Il timer B è il tempo massimo che il mittente attenderà per ricevere un INVITE. Corrisponde ad un valore di 64 volte il valore di T1.
- il Timer F è il tempo massimo che il mittente attenderà per i messaggi non INVITE. Corrisponde ad un valore di 64 volte il valore di T1.
B e F sono raddoppiati ad ogni iterazione e quindi un INVITE senza risposta assomiglierà a questo:
T0 – invio dell’INVITE originale.
500ms – invio del 2 ° INVITE.
1000 ms – invio del 3 ° INVITE.
2000 ms – invia del 4 ° INVITE.
4000 ms – invia del 5 ° INVITE.
8000ms – invia il 6° INVITE.
16s – invia 7th INVITE.
32s – invia l’8° e l’ultimo INVITE. Si verifica l’interruzione della chiamata.
Ecco dunque spiegato il motivo della caduta di una chiamata a 32sec.
Perché l’errore si presenta e dove cercare la causa?
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. In questa situazione, entra in gioco il timer SIP di tipo B, interrompendo, di fatto, la chiamata alla scadenza dei 32 secondi.
Le impostazioni di questi Timer possono verosimilmente essere compromesse da una errata impostazione del NAT a livello di PBX o a livello di interno telefonico.
E’ consigliabile, in questi casi, verificare attentamente la funzionalità del firewall e ricercare l’eventuale presenza di SIP ALG o errate configurazioni di NAT.
2. Perdita di Richieste SIP ACK (Conferme di un INVITE)
Come abbiamo appena visto, il protocollo SIP richiede che siano impostati dei tempi di timeout entro i quali avere una risposta dal dispositivo chiamato.
È 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. La chiamata cadrà sempre dopo lo stesso intervallo di tempo.
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. Il problema può presentarsi sia per le chiamate in entrata che per quelle in uscita.
In quasi tutti i casi di questo tipo, il problema si spiega con la presenza di un SIP ALG, un configurazione di doppio NAT, la presenza di un router con funzionalità di VoIP integrate che crea un conflitto con il PBX installato a valle del router stesso.
3. Superamento del tempo massimo di chiamata impostato.
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. Nella quasi totalità dei casi, questo parametro è liberamente modificabile.
4. Numerazioni inibite.
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. Per approfondire l’argomento relativo all'”Early Media” con 183 (SDP), è possibile consultare questo precedente articolo.
5. Toni DTMF erroneamente rilevati.
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. 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 che potrebbero essere la causa dei problemi riscontrati di caduta chiamata. Per approfondire il tema dei toni DTMF potete visitare questo precedente articolo.
6. Nessun pacchetto audio RTP trasmesso.
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. Potrebbe però succedere che, mettendo in Mute il microfono del telefono o attivando la soppressione di rumore o il VAD ( 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. In tutti i questi casi si tratta di un semplice problema di configurazione del telefono.
