RFC 3261: Il DNA del VoIP – Capitolo 14
Codici di risposta SIP 5xx e 6xx: errore del server o fallimento globale?

Apriamo un tracciato pcap relativo a una chiamata non riuscita. Il PBX invia un INVITE, il provider risponde con 503 Service Unavailable e il telefono riproduce un tono di congestione. Poco dopo, un’altra chiamata termina invece con 603 Decline. Per l’utilizzatore il risultato sembra identico: la comunicazione non parte. Per il tecnico, però, le due risposte descrivono situazioni molto diverse.

Nel primo caso un server dichiara di non essere temporaneamente in grado di elaborare la richiesta. Potrebbero esistere un altro server, una seconda destinazione o una rotta alternativa capaci di completarla. Nel secondo caso la rete comunica un esito riferito all’utente nel suo complesso: continuare a cercare altri recapiti di quella persona non dovrebbe cambiare il risultato.

Nel Capitolo 13 abbiamo analizzato le risposte 3xx e 4xx. Abbiamo visto che un 4xx riguarda la richiesta ricevuta da un determinato server o la risorsa indirizzata e che, in diversi casi, la stessa richiesta potrebbe riuscire altrove. Ora completiamo il percorso dedicato ai codici di risposta della RFC 3261 con le classi 5xx Server Failure e 6xx Global Failure.

Non ci limiteremo a tradurre le reason phrase. Collegheremo ogni codice a un caso riconoscibile in un PBX, in un proxy, in un SBC o in un gateway. Vedremo inoltre quali campi confrontare, quando una nuova prova ha senso e quando invece la risposta invita a fermare la ricerca di altre destinazioni.

Due classi, due portate diverse

La sezione 21.5 della RFC 3261 definisce in modo molto sintetico la classe 5xx:

“5xx responses are failure responses given when a server itself has erred.”
Le risposte 5xx indicano un fallimento dovuto a un errore del server stesso.

La formulazione va letta con attenzione. Una risposta 5xx non afferma necessariamente che il destinatario non esista, sia occupato o rifiuti la chiamata. Segnala che il server che sta rispondendo non riesce a soddisfare la richiesta per una condizione interna, per indisponibilità, per un problema verso un sistema successivo oppure per un limite tecnico.

La sezione 21.6 della RFC 3261 assegna alle risposte 6xx una portata differente:

“6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI.”
Le risposte 6xx indicano che un server possiede informazioni definitive su un determinato utente, non soltanto sulla specifica istanza indicata nella Request-URI.

La parola da ricordare è definitive. Il server non sta descrivendo soltanto il telefono, il contatto o il ramo che ha raggiunto. Sta comunicando un esito globale relativo all’utente. Questa differenza assume particolare importanza quando la richiesta viene inoltrata verso più contatti: un insuccesso locale può lasciare aperta un’altra strada, mentre un 6xx può interrompere la ricerca complessiva.

Nel funzionamento reale intervengono politiche di routing, normalizzazioni e traduzioni tra SIP e altre reti. Non tutti i sistemi espongono sempre il codice più preciso; alcuni trasformano gli errori ricevuti a valle in un generico 500, 503 o 603. La RFC fornisce il significato normativo, ma il tracciato pcap va sempre correlato con il punto della rete che ha generato la risposta.

500 Server Internal Error: una condizione inattesa

Secondo la sezione 21.5.1, il server ha incontrato una condizione inattesa che gli impedisce di soddisfare la richiesta. Il client può mostrare l’errore specifico e può riprovare dopo alcuni secondi. Se la condizione è temporanea, il server può indicare il momento opportuno con l’header Retry-After.

In un impianto, un 500 può comparire per un errore applicativo del PBX, per un dato interno incoerente, per l’impossibilità di applicare una regola o per un caso che il software non sa gestire correttamente. La reason phrase non identifica da sola la causa. Per questo i log del server che genera la risposta sono spesso decisivi.

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-500-matteo;rport=5060
From: "Matteo" <sip:matteo@example.it>;tag=from-1401
To: "Daniele" <sip:daniele@example.net>;tag=to-5001
Call-ID: cap14-500@example.it
CSeq: 1 INVITE
Retry-After: 8
Server: PBX-Daniele
Content-Length: 0

La Status-Line indica l’errore interno. Via, From, To, Call-ID e CSeq permettono di associare la risposta all’INVITE originario. L’header Retry-After: 8 suggerisce che la condizione potrebbe risolversi e indica di attendere otto secondi prima di una nuova prova. Non garantisce che il tentativo successivo avrà successo.

Un 500 non autorizza a creare un ciclo aggressivo di nuovi INVITE. Le ripetizioni troppo ravvicinate possono aggravare il problema e rendere meno leggibile la diagnosi. Occorre inoltre distinguere un nuovo tentativo applicativo dalle ritrasmissioni della stessa transaction, riconoscibili tramite lo stesso branch nel Via e lo stesso CSeq.

501 Not Implemented e la differenza dal 405

Il 501 Not Implemented indica che il server non supporta la funzione necessaria per soddisfare la richiesta. La RFC lo considera appropriato quando un UAS non riconosce il metodo e non è in grado di supportarlo per alcun utente.

La distinzione con 405 Method Not Allowed, trattato nel capitolo precedente, è concreta. Con 501 il metodo non è implementato dal server; con 405 il server riconosce il metodo, ma non lo consente o non lo supporta per la risorsa richiesta. Nel secondo caso la risposta dovrebbe aiutare il client indicando nell’header Allow i metodi ammessi.

Immaginiamo che un apparato invii un metodo SIP opzionale a un vecchio PBX. Se quel PBX non conosce affatto il metodo, 501 descrive il limite generale del prodotto. Se invece il PBX conosce il metodo ma lo vieta su quello specifico servizio o account, 405 è più preciso. Alcune implementazioni restituiscono comunque codici generici: il tecnico deve registrare il comportamento osservato senza trasformarlo automaticamente in una regola del protocollo.

La RFC precisa anche che i proxy inoltrano le richieste indipendentemente dal metodo. Il proxy non dovrebbe quindi usare 501 semplicemente perché non comprende il significato applicativo del metodo che sta trasportando. La funzione del proxy e quella dell’UAS non vanno confuse.

502 Bad Gateway: la risposta a valle non è valida

Il 502 Bad Gateway viene generato da un server che opera come gateway o proxy e riceve una risposta non valida dal server a valle contattato per completare la richiesta.

Lo scenario contiene quindi almeno tre ruoli: il client che invia l’INVITE, il sistema intermedio che tenta di proseguirlo e il sistema a valle che risponde in modo non utilizzabile. Il 502 non dice che il numero chiamato sia errato. Dice che il sistema intermedio non ha potuto utilizzare ciò che ha ricevuto dal passo successivo.

In una rete convergente, il sistema a valle potrebbe non parlare SIP. Un gateway può interrogare una piattaforma differente o tradurre la segnalazione verso una rete telefonica. Se la risposta ricevuta è malformata, incoerente o non interpretabile, il gateway può riportare a monte un 502. La causa originaria resta quindi oltre il nodo che vediamo rispondere.

Per la diagnosi conviene individuare l’indirizzo IP sorgente del 502 e ricostruire la catena: chi ha ricevuto l’INVITE, verso quale destinazione lo ha inoltrato e quale risposta ha ottenuto. Se il tracciato è raccolto soltanto sul lato PBX del cliente, vedremo probabilmente il 502 ma non lo scambio problematico tra provider e sistema a valle.

503 Service Unavailable: quando il trunk esaurisce le chiamate simultanee

Il 503 Service Unavailable è uno dei codici più frequenti nell’attività operativa. La RFC lo collega all’incapacità temporanea del server di elaborare la richiesta per sovraccarico o manutenzione. Il server può inserire Retry-After; in sua assenza il client deve comportarsi come se avesse ricevuto un 500.

La temporaneità distingue il 503 da molti errori strutturali. Il servizio non è necessariamente configurato male e il destinatario non è necessariamente irraggiungibile. Il nodo può essere saturo, in riavvio, sottoposto a manutenzione o momentaneamente privo di una risorsa necessaria.

Un caso concreto e molto frequente riguarda il numero massimo di chiamate simultanee previsto per un trunk SIP. Immaginiamo un account VoIP configurato per gestire dieci comunicazioni contemporanee. Quando sono già attive dieci chiamate, l’undicesimo INVITE raggiunge correttamente il provider, ma non può essere servito finché una delle risorse occupate non torna disponibile. La stessa condizione può verificarsi sul trunk gestito da un PBX: il sistema ha raggiunto il limite di sessioni contemporanee configurato o consentito e deve rifiutare temporaneamente una nuova richiesta.

In entrambi i casi 503 Service Unavailable è un uso corretto e coerente con la RFC. L’indisponibilità riguarda la capacità temporanea del servizio, non lo stato personale del destinatario. Nel linguaggio commerciale si continua spesso a parlare di “canali voce”, ma in un trunk SIP si tratta normalmente di un limite logico di chiamate o sessioni simultanee, non di canali fisici come nella telefonia tradizionale.

Una risposta 486 Busy Here sarebbe invece semanticamente impropria per rappresentare il semplice esaurimento delle chiamate simultanee del trunk. Il 486 descrive il fatto che il chiamato non vuole o non può accettare altre chiamate presso quella specifica destinazione. Usarlo per un limite di capacità dell’account attribuirebbe quindi al destinatario una condizione di occupato che non è stata realmente accertata e nasconderebbe la vera natura del rifiuto.

Non tutti i provider e non tutti i PBX applicano la stessa mappatura: alcuni prodotti possono restituire codici meno precisi per ragioni storiche o per scelte di compatibilità. Questo comportamento va documentato come caratteristica dell’implementazione, non assunto come significato alternativo del 486. Se il limite raggiunto è quello delle chiamate simultanee e la risorsa potrà liberarsi, il 503 comunica in modo più fedele ciò che sta accadendo.

SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 198.51.100.20:5060;branch=z9hG4bK-trunk-503;rport=5060
From: "Matteo" <sip:0551234567@pbx.example.it>;tag=from-5031
To: <sip:0212345678@provider.example.net>;tag=edge-503
Call-ID: cap14-503@pbx.example.it
CSeq: 104 INVITE
Retry-After: 30
Warning: 399 edge.example.net "Concurrent call limit reached"
Content-Length: 0

La risposta appartiene all’INVITE con CSeq 104. Retry-After: 30 indica trenta secondi di attesa. Il Warning esplicita che è stato raggiunto il limite delle chiamate contemporanee, ma si tratta di un’informazione dipendente dall’implementazione: la RFC non obbliga il server a usare questa frase. Il client non deve interpretare una reason phrase o un testo personalizzato come se fosse un nuovo codice SIP.

La RFC dice che un client, proxy o UAC, che riceve 503 dovrebbe tentare di inoltrare la richiesta a un server alternativo e, se Retry-After è presente, non dovrebbe inviare altre richieste allo stesso server per la durata indicata. Ciò non significa che ogni telefono debba conoscere una seconda rotta. In molte reti la logica di ridondanza risiede nel PBX, nel proxy in uscita, nell’SBC o nella risoluzione DNS.

Esiste inoltre un dettaglio importante: un server può rifiutare la connessione o scartare la richiesta invece di inviare 503. L’assenza di risposta non esclude quindi un sovraccarico. In quel caso il tracciato mostrerà ritrasmissioni e infine un timeout, non una Status-Line esplicita.

504 Server Time-out: il server intermedio ha atteso invano

Con il 504 Server Time-out, il server dichiara di non aver ricevuto in tempo una risposta da un server esterno contattato durante l’elaborazione. Anche qui la topologia conta: chi genera il 504 è riuscito a ricevere la richiesta iniziale, ma il passo successivo non ha prodotto la risposta attesa.

Il confronto con 502 aiuta molto. Nel 502 qualcosa torna dal sistema a valle, ma la risposta non è valida. Nel 504 il server intermedio non riceve in tempo la risposta necessaria. Per capire il guasto servono quindi entrambi i lati del nodo intermedio oppure i suoi log: una cattura eseguita solo sul PBX del cliente non prova da sola dove sia avvenuto il ritardo.

La RFC distingue inoltre il 504 dal 408 Request Timeout. Il 408 descrive un timeout della richiesta nel contesto indicato dalla specifica; il 504 comunica invece che un server, mentre elaborava la richiesta, ha atteso senza successo un altro server. Nelle reti commerciali questa distinzione può essere attenuata da traduzioni e politiche interne, ma rimane essenziale per leggere correttamente il significato originario.

505 e 513: versione e dimensione del messaggio

Il 505 Version Not Supported segnala che il server non supporta, o rifiuta di supportare, la versione SIP usata nella richiesta. In un normale impianto basato su SIP/2.0 questo codice è raro. Se compare, occorre controllare la Request-Line e la versione indicata anche nelle righe Via, senza confondere un errore di sintassi con un’autentica incompatibilità di versione.

Il 513 Message Too Large indica invece che la lunghezza del messaggio supera le capacità del server. Header numerosi, corpi SDP estesi, contenuti MIME o informazioni aggiunte lungo il percorso possono far crescere la richiesta. Il problema riguarda il messaggio SIP, non la dimensione dei pacchetti RTP che trasporteranno l’audio dopo l’eventuale instaurazione della sessione.

La presenza di frammentazione IP o l’uso di UDP merita una verifica, ma non deve essere confusa con il significato del 513. Se il server ha ricevuto il messaggio e ha generato 513, sta dichiarando un proprio limite di elaborazione. Un pacchetto frammentato perso in rete, invece, può condurre a ritrasmissioni o timeout senza che il destinatario riesca a produrre alcuna risposta SIP. Il trasporto UDP e TCP sarà affrontato in modo organico nel Capitolo 16.

600 Busy Everywhere: occupato su tutte le destinazioni note

Entriamo ora nelle risposte globali. Il 600 Busy Everywhere indica che il sistema finale del chiamato è stato contattato, ma l’utente è occupato e non desidera ricevere la chiamata in quel momento. Può essere presente Retry-After.

Il confronto fondamentale è con 486 Busy Here. Il 486 si riferisce alla specifica destinazione raggiunta: l’utente potrebbe essere disponibile altrove, per esempio su un altro telefono o tramite segreteria. Il 600 deve essere usato soltanto quando il client sa che nessun altro apparato o servizio potrà rispondere.

Supponiamo che Daniele abbia un telefono fisso, un’applicazione mobile e una segreteria. Se soltanto il telefono fisso è occupato, un 486 lascia spazio agli altri contatti. Se il sistema possiede informazioni definitive e sa che nessuna destinazione alternativa deve essere tentata, può produrre 600. La conoscenza globale richiesta dalla RFC spiega perché questo codice sia meno comune di quanto suggerisca il suo nome.

SIP/2.0 600 Busy Everywhere
Via: SIP/2.0/TCP 203.0.113.15:5060;branch=z9hG4bK-global-600
From: "Matteo" <sip:matteo@example.it>;tag=from-6001
To: "Daniele" <sip:daniele@example.net>;tag=global-600
Call-ID: cap14-600@example.it
CSeq: 1 INVITE
Retry-After: 120
Content-Length: 0

La Status-Line comunica che l’occupato non vale soltanto per un singolo contatto. Retry-After suggerisce una nuova prova dopo centoventi secondi. I campi Via, Call-ID e CSeq consentono di correlare la risposta alla richiesta; il tag nel To identifica la risposta finale prodotta dal lato remoto nel contesto dello scambio.

L’utilizzatore potrebbe sentire un tono di occupato o di congestione, ma il suono non è contenuto nel codice 600. Il telefono o il PBX possono generarlo localmente dopo aver interpretato la risposta. In altre architetture un annuncio può essere stato inviato prima come audio inband in un flusso RTP anticipato, per esempio dopo un 183 con SDP. Per stabilire l’origine del suono bisogna verificare segnalazione, SDP e pacchetti RTP, non soltanto leggere la reason phrase.

603 Decline: rifiuto globale senza dichiararne il motivo

Il 603 Decline indica che l’apparato del chiamato è stato raggiunto, ma l’utente non desidera o non può partecipare. Anche questa risposta può includere Retry-After e deve essere restituita come esito globale soltanto quando si sa che nessun’altra destinazione risponderà.

Un caso tipico è il rifiuto esplicito applicato da una politica centrale dell’utente. Tuttavia, la provenienza reale va verificata. Un 603 può essere generato dal telefono, dal PBX, da un servizio di instradamento o da un’interconnessione che ha tradotto una causa ricevuta da un’altra rete. Dire che “l’utente ha premuto rifiuta” senza individuare il generatore è una conclusione troppo forte.

La differenza con 600 riguarda l’informazione resa disponibile: 600 espone la condizione di occupato; 603 permette di rifiutare senza rivelare quella ragione. La differenza con 486 resta invece nella portata: 486 riguarda il contatto specifico, 603 afferma un rifiuto che chiude le alternative note.

604 Does Not Exist Anywhere: informazione autorevole sull’identità

Il 604 Does Not Exist Anywhere viene usato quando il server possiede informazioni autorevoli secondo cui l’utente indicato nella Request-URI non esiste in alcun luogo.

Confrontiamolo con 404 Not Found. Un 404 descrive l’impossibilità del server interrogato di trovare l’utente nel proprio dominio o contesto e, secondo l’architettura, la richiesta potrebbe ancora riuscire altrove. Un 604 richiede una conoscenza più ampia e definitiva. Non equivale quindi semplicemente a “numero non presente nella tabella di questo PBX”.

In una rete aziendale, l’autorevolezza può appartenere al sistema che governa l’intero dominio. In una catena di operatori, invece, un nodo intermedio potrebbe non avere elementi sufficienti per dichiarare che l’identità non esiste ovunque. Le traduzioni tra protocolli possono produrre comunque un 604, ma la diagnosi deve distinguere il significato previsto dalla RFC dalla politica concreta dell’operatore.

606 Not Acceptable: l’utente esiste, la sessione proposta no

Il 606 Not Acceptable comunica che lo user agent è stato raggiunto, ma alcuni aspetti della descrizione di sessione non sono accettabili: mezzi richiesti, banda, modalità di indirizzamento o altri parametri. L’utente vorrebbe comunicare, ma non può supportare adeguatamente la sessione descritta.

La risposta può contenere un header Warning con le ragioni dell’incompatibilità e un corpo che descrive le capacità multimediali. Anche qui “può” traduce MAY: non dobbiamo aspettarci obbligatoriamente questi dettagli in ogni 606.

Il confronto è con 488 Not Acceptable Here. Il 488 vale per la specifica risorsa indirizzata dalla Request-URI e la richiesta potrebbe riuscire altrove. Il 606 estende l’esito all’utente, quando il client sa che nessun altro apparato potrà accettare la sessione. In pratica, un’offerta con un solo codec non supportato può produrre 488 sul telefono raggiunto; 606 richiede la certezza che neppure le altre destinazioni dell’utente possano soddisfarla.

Per la ricerca del guasto non basta leggere il codice. Occorre confrontare l’SDP dell’INVITE, gli eventuali formati indicati nella risposta, i payload type, gli attributi e il Warning. Un 606 avviene prima dell’instaurazione della sessione: l’assenza del flusso RTP successivo è una conseguenza normale del rifiuto, non un guasto audio indipendente.

La risposta finale e l’ACK

Quando 5xx o 6xx rispondono a un INVITE, sono risposte finali negative. Il chiamante invia un ACK per confermarne la ricezione secondo le regole già incontrate nella collana. L’ACK non trasforma il fallimento in successo e non costituisce un nuovo tentativo di chiamata.

Nel tracciato si potrà quindi osservare una sequenza come INVITE, eventuali risposte 1xx, risposta finale 503 e ACK. Se l’INVITE viaggia su UDP, la risposta finale può essere ritrasmessa finché l’ACK non raggiunge il nodo che la gestisce. Più copie dello stesso 503 non indicano necessariamente più guasti: possono rivelare la perdita dell’ACK o un problema sul percorso di ritorno.

Per distinguere una ritrasmissione da una nuova chiamata si confrontano branch del Via, Call-ID, tag e CSeq. Una nuova prova applicativa avrà normalmente una nuova transaction e quindi un nuovo branch, anche se l’identità chiamante e quella chiamata restano uguali.

Una lettura operativa: dove nasce davvero l’errore?

Le reason phrase aiutano, ma l’indirizzo sorgente del pacchetto aiuta di più. Un PBX può ricevere 504 da un SBC del provider; ciò prova che l’SBC ha risposto al PBX, non che sia necessariamente il componente originariamente guasto. Lo stesso SBC potrebbe avere atteso un softswitch, un gateway o una rete esterna.

Conviene ricostruire la catena con quattro domande. Chi ha inviato la richiesta? Chi ha generato la risposta osservata? Quel nodo stava agendo come UAS finale, proxy o gateway? Il codice descrive una propria condizione o riassume un problema ricevuto a valle?

Anche la presenza di più Via mostra il percorso seguito dalla segnalazione, pur senza esporre necessariamente tutta la topologia. SBC e dispositivi di interconnessione possono riscrivere header, mascherare indirizzi e normalizzare codici. I log correlati tramite Call-ID e orario restano spesso indispensabili.

Errori di interpretazione ricorrenti

Un 5xx non significa automaticamente guasto del provider. Il pacchetto può provenire dal PBX locale, da un’applicazione, da un SBC o da un server remoto. La sorgente va identificata prima di attribuire la responsabilità.

503 non significa sempre linea congestionata. Può indicare sovraccarico o manutenzione del server. Il termine “congestione” mostrato sul display o nei log può essere una categoria locale usata dal prodotto per più cause diverse.

Un tono non prova la presenza di audio inband. Il dispositivo può generarlo localmente in risposta al codice SIP. Per parlare di annuncio o tono ricevuto dalla rete occorre osservare un flusso RTP coerente con l’SDP.

603 non dimostra da solo un gesto dell’utente. Una politica del PBX, un servizio di blocco o una traduzione della rete possono generarlo. Il significato protocollare è un rifiuto globale; l’azione fisica che lo ha provocato richiede altre evidenze.

600 non è un sinonimo elegante di 486. Il primo richiede conoscenza globale; il secondo descrive l’occupato sulla specifica destinazione. La stessa relazione esiste tra 604 e 404, e tra 606 e 488.

Riprovare non è sempre corretto. Con alcuni 5xx una rotta alternativa o un tentativo successivo hanno senso. Con un 6xx la rete ha dichiarato un esito definitivo sull’utente: continuare sugli altri contatti contraddice la portata della risposta.

Dal codice alla diagnosi

Le risposte 5xx e 6xx chiudono il percorso iniziato con le classi 1xx e 2xx e proseguito con 3xx e 4xx. La loro lettura diventa più semplice se si parte dalla portata: 5xx descrive il fallimento di un server nel soddisfare la richiesta; 6xx descrive un esito globale relativo all’utente.

All’interno dei 5xx, 500 raccoglie una condizione interna inattesa, 501 un limite di funzione, 502 una risposta a valle non valida, 503 un’indisponibilità temporanea, 504 l’attesa scaduta verso un server esterno, 505 una versione SIP non supportata e 513 un messaggio troppo grande. Nei 6xx, 600 estende l’occupato a tutte le destinazioni note, 603 esprime un rifiuto globale, 604 dichiara autorevolmente inesistente l’utente e 606 estende a livello globale l’incompatibilità della sessione proposta.

Il codice è l’inizio della diagnosi, non la sua conclusione. IP sorgente, percorso dei Via, Call-ID, branch, CSeq, Retry-After, Warning, SDP, tempi e flussi RTP permettono di trasformare una semplice schermata “chiamata fallita” in una spiegazione tecnica verificabile.

Nel prossimo capitolo entreremo nella autenticazione SIP Digest. Distingueremo 401 da 407, WWW-Authenticate da Proxy-Authenticate e vedremo come nonce, realm e credenziali costruiscono il nuovo tentativo autenticato, senza confondere l’autenticazione con la cifratura del traffico.