Le chiamate da VoIP cadono dopo 30 secondi

Ti trovi quì:

Può accadere che una chiamata proveniente da un operatore VoIP cada inspiegabilmente e sistematicamente dopo un tempo preciso (tipicamente 30 secondi). Il fenomeno è molto chiaro e cercheremo di spiegarlo nel seguito. Diciamo subito che l’autore della disconnessione è il centralino VOIspeed, che si vede “costretto” a chiudere la chiamata per la mancanza di particolari segnalazioni previste dallo standard.

Una chiamata VoIP in ingresso si presenta sempre secondo questa sequenza (standard SIP 2.0):

  1. al PBX arriva il messaggio INVITE dell’operatore (Incoming SIP request “INVITE” FROM 83.211.227.21:5060)
  2. il PBX comunica all’operatore che sta provando a gestire la chiamata con il messaggio 100 Trying (Outgoing SIP response “100 Trying” to request INVITE TO 83.211.227.21:5060);
  3. quando la chiamata viene accettata, il PBX invia all’operatore il messaggio 200 OK (Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060). All’interno di questo messaggio, viene comunicato l’indirizzo IP sul quale l’operatore deve rispondere. L’indirizzo IP in questione non è altro l’indirizzo IP pubblico con il quale il PBX si presenta al mondo esterno e che viene indicato nel tag Contact del pacchetto di risposta 200 OK (vedi sotto).
  4. Dopo il 200 OK, il PBX si aspetta, come da standard, il messaggio ACK da parte dell’operatore per indicare che “ha capito” che la chiamata è stata accettata.

L’anomalia si presenta allorché il messaggio ACK non viene mai ricevuto dal PBX. Ci si può accorgere di questo perché nel tracciato della chiamata si può osservare una lunga serie di messaggi 200 OK ripetuti in rapida successione all’operatore. Dopo 30 secondi, in assenza di risposte, il PBX è costretto a chiudere la chiamata.

Ecco come potrebbe apparire il messaggio 200 OK inviato dal PBX verso l’operatore (gli indirizzi IP e altri dettagli del pacchetto possono essere diversi in base al proprio PBX allo stato della chiamata e dell’operatore:

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 83.211.227.21;branch=z9hG4bKbd33.9b6523b1.0
Via: SIP/2.0/UDP 62.94.71.98:5060;rport=62061;received=62.94.71.98;x-route-tag=”tgrp:Slot6″;branch=z9hG…
From: <sip:num_chiamante@62.94.71.98>;;tag=84D579C0-24C6
To: <sip:username@voip.eutelia.it>;;tag=56CB67A8
Call-ID: CC6193A1-FF6D11E3-8433A80D-2E4E112F@62.94.71.98
CSeq: 101 INVITE
Contact: <sip:username@82.100.101.102:5060>
User-Agent: UAVoispeed

… (altre informazioni omesse per brevità) …

CAUSE

Il problema interessa quasi certamente un nodo della connettività (il proprio router/firewall o apparati dal lato operatore). Infatti dopo la risposta del PBX (200 OK) inviata all’operatore come conferma di aver instaurato la conversazione (il flusso audio viene aperto in questa fase e si può già parlare, prima della conferma dell’operatore), il PBX stesso non riceve l’ACK dell’operatore, necessario per continuare la conversazione, altrimenti, dopo 30 secondi scatta il timeout che abbatte la chiamata.
La mancata ricezione di questi pacchetti può essere causato da funzioni ALG attive nel proprio router, oppure da un’errata configurazione del NAT dello stesso router, ove si richiede (soprattutto in presenza di terminali remoti al PBX) l’apertura delle porte 5004-5060 UDP verso l’indirizzo IP privato del PBX.
La mancata ricezione della risposta (ACK) dell’operatore è esterna al PBX: ciò significa che probabilmente la risposta del PBX (200 OK) arriva correttamente all’operatore, e l’operatore risponde, ma su un IP:porta errati perché il proprio router ha i problemi già menzionati; oppure l’operatore non riceve mai il 200 OK del PBX e quindi non invia mai la sua risposta.

COME DIAGNOSTICARE

Come detto precedentemente, la diagnosi di questo problema è abbastanza semplice: basta prelevare un tracciato di una chiamata e constatare la presenza di numerosi messaggi 200 OK inviati dal PBX (outgoing), messaggi a cui non segua mai una risposta (incoming) ACK…

Oggi 11:14:52.332 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:52.472 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:52.873 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:53.679 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:55.284 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:58.529 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:02.551 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:02.551 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:06.598 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:10.697 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:18.916 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060

COME RISOLVERE

Occorre verificare che l’indirizzo IP pubblico risolto dal PBX coincida con quello indicato dal campo Contact del messaggio 200 OK.
Disabilitare le funzioni SIP ALG, o qualsiasi altra funzione legata al protocollo SIP. Controllare di non aver mal configurato il NAT del router. Ove richiesto occorre aprire le porte UDP 5004-5060 verso l’IP privato del PBX.
L’operatore dovrebbe verificare dove spedisce la risposta (ACK) o se mai riceve il 200 OK del PBX (in particolare dall’IP pubblico del PBX). Se l’operatore non può risolvere e se non si notano anomalie sul proprio router, l’ultimo controllo da effettuare per indagare sulle responsabilità del fenomeno è attivare sulla macchina server uno sniffer esterno a VOIspeed (es. WireShark) per verificare effettivamente il flusso dei pacchetti SIP.

A questo punto dovrebbe bastare un controllo del proprio router e l’impostazione corretta delle configurazioni relative al VoIP. Si suggerisce quindi di:

  • disattivare tutte le funzioni legate al VoIP/SIP (chiamate anche ALG);
  • riconfigurare eventuali mappature statiche del NAT sul nuovo IP di VOIspeed;
  • verificare che il router non si presenti con più di un indirizzo IP pubblico (ad esempio quando ci sono due o più ADSL in balancing) o se si hanno diversi IP pubblici assegnati su altrettante interfacce di rete WAN;
  • riavviare sempre il router dopo le modifiche e verificare che siano state recepite.
Tags: