Codici di risposta SIP: guida al troubleshooting delle chiamate

Quando una chiamata VoIP non va a buon fine, il centralino restituisce quasi sempre un codice numerico. Saperlo leggere accorcia di ore il tempo di diagnosi: il codice dice se il problema è nel centralino, nel trunk, nella rete o nella numerazione chiamata.

Struttura di una risposta SIP

SIP riprende la logica di HTTP: ogni risposta ha un codice a tre cifre e una frase descrittiva. La prima cifra identifica la classe:

• 1xx – provvisorie, la richiesta è in elaborazione
• 2xx – successo
• 3xx – redirezione verso un'altra destinazione
• 4xx – errore lato richiedente
• 5xx – errore lato server
• 6xx – fallimento globale, nessun server può accettare la chiamata

La frase testuale accanto al codice non è normalizzata: ogni operatore la personalizza. Fidatevi del numero, non della descrizione.

Le provvisorie (1xx) e cosa dicono sullo stato della chiamata

• 100 Trying – il proxy ha ricevuto l'INVITE e lo sta instradando. Se non arriva entro pochi secondi, il problema è di raggiungibilità: firewall, routing o trunk giù.
• 180 Ringing – la destinazione sta squillando. Da qui in poi il percorso di segnalazione funziona.
• 183 Session Progress – l'operatore invia early media, tipicamente un annuncio o il ringback generato in rete. Se sentite un messaggio vocale ma la chiamata cade subito dopo, il motivo reale è nell'annuncio, non nel codice finale.

I 4xx: la classe che genera più ticket

• 401 / 407 – richiesta di autenticazione. Normale nel flusso di registrazione. Se si ripete all'infinito, credenziali o realm sono errati.
• 403 Forbidden – l'operatore rifiuta di instradare. Le cause tipiche sono IP sorgente non in whitelist, CLI non autorizzato o direzione non abilitata sul trunk. È il codice più frequente quando si attiva un trunk nuovo.
• 404 Not Found – numerazione inesistente o formattata male. Verificate il piano di numerazione: molti operatori accettano solo E.164 completo con prefisso internazionale.
• 407 Proxy Authentication Required – come il 401 ma richiesto dal proxy intermedio.
• 408 Request Timeout – nessuna risposta entro il timer. Quasi sempre un problema di rete, non di configurazione applicativa.
• 480 Temporarily Unavailable – il destinatario è registrato ma non raggiungibile. Su interni interni significa telefono spento o registrazione scaduta.
• 486 Busy Here – occupato. Codice legittimo, non un guasto.
• 487 Request Terminated – chiamata annullata da un CANCEL, tipicamente perché il chiamante ha riagganciato o è scattato un timer di forwarding.
• 488 Not Acceptable Here – negoziazione media fallita. Nessun codec in comune, oppure SDP con indirizzi privati non raggiungibili. È il codice classico dietro il problema dell'audio assente in un senso.

I 5xx e i 6xx

• 500 Server Internal Error – guasto generico sull'apparato remoto.
• 503 Service Unavailable – trunk saturo, licenza esaurita o piattaforma in manutenzione. Se compare a ondate negli orari di punta, controllate il numero di canali contrattualizzati.
• 504 Server Time-out – timeout su un hop a monte.
• 603 Decline – rifiuto esplicito. Diverso dal 486: la chiamata è stata scartata per policy, non per occupato.
• 604 Does Not Exist Anywhere – numerazione cessata a livello di rete.

Come catturare la segnalazione

Su FreePBX e Asterisk il modo più rapido è la CLI:

# Abilita il log SIP dettagliato su chan_pjsip
asterisk -rx "pjsip set logger on"

# Mostra lo stato dei trunk configurati
asterisk -rx "pjsip show endpoints"

# Cattura filtrata sul solo traffico di segnalazione
tcpdump -i any -n -s 0 port 5060 -w /tmp/sip.pcap

Il file .pcap si apre in Wireshark: il menu Telephony → VoIP Calls ricostruisce il flow diagram completo, con tutti i codici in sequenza. È il modo più veloce per capire chi ha chiuso la chiamata e con quale motivazione.

Su MikroTik, se il router fa da NAT davanti al centralino, verificate sempre che SIP ALG sia disattivato:

/ip firewall service-port set sip disabled=yes

L'ALG riscrive gli header SDP e produce esattamente i sintomi del 488 e dell'audio unidirezionale.

Leggere il codice nel contesto giusto

Un errore ricorrente è fermarsi al codice finale ignorando la sequenza. Un 403 preceduto da un 407 significa che l'autenticazione è passata ma la policy ha bloccato la chiamata: due problemi diversi che richiedono interlocutori diversi. Allo stesso modo, un 503 che arriva dopo un 100 Trying indica che il trunk è raggiungibile ma non ha risorse, mentre un 503 immediato senza provvisorie punta a un problema di raggiungibilità dell'endpoint.

Un secondo elemento spesso trascurato è l'header Reason, che alcuni operatori inseriscono nelle risposte di errore con il codice ISUP originale della rete PSTN. Quando presente, è molto più informativo del codice SIP: distingue per esempio fra numero inesistente, numero portato non aggiornato e blocco per credito esaurito.

Errori più frequenti sui trunk italiani

• CLI presentato non appartenente alle numerazioni assegnate → 403
• Numerazione inviata in formato nazionale su trunk che richiede E.164 → 404
• G.729 non licenziato sul centralino con trunk che offre solo G.729 → 488
• Canali simultanei oltre il contratto → 503
• Registrazione con NAT e keepalive troppo lungo → 408 intermittenti

Nella maggior parte dei casi, il codice non è il problema: è l'indice che punta al punto esatto della catena da verificare.