Ogni installatore VoIP si è trovato, almeno una volta, ad affrontare problemi legati all’improvvisa caduta della chiamata dopo pochi secondi di conversazione. Ancora più frequente è il caso in cui la chiamata si interrompe sistematicamente dopo 5, 10 o 32 secondi.
In tutti questi casi la chiamata si interrompe generalmente con un BYE trasmesso da parte del chiamato. La richiesta di BYE, in queto caso, non viene attivata dalla persona chiamata ma direttamente dal PBX. Questa operazione viene infatti eseguita automaticamente a livello SIP da parte del sistema. Si tratta sicuramente di uno dei problemi più ricorrenti e fastidiosi ma, allo stesso tempo, più facile da indentificare e risolvere.
Come diagnosticare il problema
Se vi capita di sperimentare quanto appena descritto, la prima operazione da svolgere è eseguire una cattura .pcap a livello SIP e verificare se il dispositivo finale del chiamato stia effettivamente ricevendo o meno una richiesta di ACK . È fondamentale verificare la presenza dell’ACK a livello del dispositivo finale (PBX) del chiamato e non a livello del chiamante o dei proxy SIP intermedi: l’ ACK infatti viene normalmente perso a livello di routing, nel passaggio di NAT a livello della connettività del chiamante.
In caso di assenza dell’ACK, la disconnessione della chiamata è esplicitamente prevista dalla RFC3261. Qualunque dispositivo SIP che non riceva l’ ACK dopo la sua risposta finale di 200 OK, deve infatti disconnettere la chiamata con una richiesta di BYE standard .
Tale decisione di terminare automaticamente la chiamata, a prescindere della volontà e dal controllo dell’utente finale, indica un errore nell’impostazione della chiamata SIP. In queste situazioni la chiamata è stata in genere già stabilita e il flusso multimediale è già stato scambiato tra gli endpoint. L’INVITE iniziale e la risposta di 200 OK, entrambi contenenti le segnalazioni SDP, sono stati quindi già trasmessi tra il chiamante e il chiamato. Manca però in questo caso la conferma, da parte del chiamante, relativa al ricevimento del 200 OK. La richiesta SIP “ACK” consiste proprio nella conferma che viene trasmessa a seguito del ricevimento del 200 OK.
Indagare sulla perdita dell’ACK
Per comprendere le modalità con le quali l’ACK viene perso, è necessario capire come esso venga instradato dal chiamante al dispositivo finale del chiamato. Senza entrare in tutti i dettagli, l’ ACK viene reindirizzato al chiamato in base alle intestazioni (header) Record-Route e Contact contenute nella risposta 200 OK . E’ quindi corretto attendersi che le l’ACK venga instradato in modo errato a causa di errate informazioni contenute nel 2oo OK .
Le intestazioni Record-Route (nel 200 OK ) sono generalmente le meno colpevoli, in quanto vengono inserite nel messaggio SIP dai proxy visitati e non vengono generalmente modificate. Supponendo di trovarci in uno scenario con un centralino IP dietro NAT, possiamo normalmente scartare la possibilità di avere Record-Route corrotto. Il principale sospetto è quindi l’ intestazione “contact” present 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. Quanto appena descritto accade principalmente a causa di una gestione errata a livello di NAT sul lato dell’utente finale: la colpa è quindi del router che esegue il NAT.
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 = 32secondi). In questo caso il ricevente della chiamata che non si vede recapitare la conferma ACK entro 32 secondi, invierà alla controparte una richiesta di BYE pere terminare la chiamata.
Esempio Pratico
Nei due esempi seguenti è possibile visualizzare la sessione di una chiamata VoIP SIP con assenza di ACK e confrontarla con il successivo esempio di chiamata corretta.
NAT e SIP ALG
In alcune circostanze particolari è possibile che il problema sia innescato a livello di SIP ALG (SIP Helper) contenuto
Per eseguire la diagnosi è necessario ricorrere a Wireshark ma, ancora prima, è fondamentale identificare le variabili in gioco:
- Identificare l’IP e la porta SIP privata utilizzata dal dispositivo.
- Identificare l’IP e la porta SIP pubblica tradotte a livello di NAT dal dispositivo Router
- Analizzare, attraverso una cattura Wireshark l’header “contact” e “via” presenti all’interno della risposta 200 OK che viene trasmessa al chiamante.
L’analisi di questi dati permette di riscontrare l’anomalie a trovare una soluzione. E’ 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. In altri casi è sufficiente disabilitare il SIP ALG presente sul router.
Intervenire sul dispositivo VoiP SIP
Il protocollo SIP richiede attenzione per tutti i minimi dettagli. Non è sufficiente prestare attenzione alla sola richiesta di INVITE. In essa va sempre verificata la corretta composizione delle intestazioni “contact” e “via” e la presenza eventuale dell’estensione “rport” nell’header via.
Quando viene rilevata una interruzione della chiamata a 5-10-32 secondi è sempre necessario analizzare l’header “contact” nella risposta di 200 OK.
L’header contact è fondamentale in un messaggio SIP in quanto rappresenta l’indirizzo URI al quale ci si aspetta di essere ricontattati con qualunque successivo messaggio,
L’header “contact” contiene un indirizzo IP locale (172.20.12.102) che, in assenza di estensione rport nell’header via, non può essere riconosciuto dal chiamante come IP raggiungibile.
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 200.200.200.200;branch=grTyehjdjeu45667
Via: SIP/2.0/UDP 50.50.50.50:5060;rport=62061;branch=z9hG…
From: <sip:numerochiamante@50.50.50.50>;;tag=84D579C0-24C6
To: <sip:numerodestinatario@user.voipvoice.it>;;tag=56CB67A8
Call-ID: SFIJOIJO-ASGSAGSAG-ASDG-ADG
CSeq: 101 INVITE
Contact: <sip:username@172.20.12.102:5060>
E’ sufficiente attivare le estensioni stun e rport per superare questo specifico problema. In altre circostanze, quali ad esempio l’utilizzo di un PBX, sarebbe più consigliabile la creazione di opportune regole di NAT statico per le porte SIP e RTP utilizzate dallo specifico PBX.
L’ultima circostanza, la più difficile da diagnosticare, si verifica nel caso in cui sul router sia attivo un SIP ALG. Anche se l’header “contact” fosse formulato correttamente, l’algoritmo SIP provvederebbe a modificare, a livello del router, l’header “contact” contenuto nel 200 OK, prima di inviarlo alla controparte.
In questo specifico caso l’anomalia risulterebbe apparentemente non visibile nella traccia .pcap.
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. In questo caso l’unica opzione percorribile è quella di provvedere alla disabilitazione dell’algoritmo SIP.
