RFC 3261: Il DNA del VoIP – Capitolo 12
Codici di risposta SIP: classi 1xx e 2xx

Un utente chiama un interno aziendale. Sul display compare il nome del collega, si sente il tono di libero e, pochi secondi dopo, la conversazione comincia regolarmente. Per chi usa il telefono è un gesto quotidiano. Nel tracciato pcap, però, quei pochi secondi sono raccontati da più risposte SIP: spesso un 100 Trying, poi un 180 Ringing oppure un 183 Session Progress e infine un 200 OK.

Leggere soltanto i numeri non basta. Il 180 non trasporta il suono del telefono remoto. Il 183 non significa automaticamente che la chiamata sia stata risposta. Il 200 OK non indica sempre che una conversazione sia iniziata: dipende dal metodo al quale sta rispondendo. Serve quindi collegare ogni codice alla richiesta, all’apparato che lo genera e a ciò che accade sui flussi audio.

Nel capitolo precedente abbiamo visto il re-INVITE, cioè un INVITE inviato all’interno di un dialogo già esistente per modificare una sessione. Anche quel messaggio riceve risposte provvisorie o definitive. In questo capitolo allarghiamo lo sguardo: analizziamo le classi 1xx e 2xx, osserviamo come una risposta torna verso chi ha inviato la richiesta e impariamo a distinguere avanzamento della chiamata, early media e successo della singola operazione SIP.

La prima cifra descrive la classe

Una risposta SIP inizia con una Status-Line. La riga contiene la versione del protocollo, un codice numerico di tre cifre e una Reason-Phrase leggibile. Per esempio:

SIP/2.0 180 Ringing

SIP/2.0 identifica la versione, 180 è lo Status-Code e Ringing è la frase descrittiva. Per decidere come trattare la risposta conta soprattutto il codice. La frase può essere personalizzata e non deve diventare la base di una logica automatica.

La sezione 21 della RFC 3261 organizza le risposte in sei classi. La prima cifra ne esprime il significato generale: 1xx per le risposte provvisorie, 2xx per quelle positive definitive, 3xx per il reindirizzamento, 4xx per gli errori riferiti alla richiesta, 5xx per i problemi del server e 6xx per gli insuccessi globali. In questo capitolo restiamo sulle prime due classi; le altre saranno sviluppate nei Capitoli 13 e 14.

Un apparato che non riconosce un codice specifico deve comunque poter comprendere la classe. Un futuro codice 199, per esempio, rimarrebbe una risposta provvisoria. Questo principio permette al protocollo di evolvere senza rendere inutilizzabili gli apparati che conoscono la semantica generale della prima cifra.

Le risposte provvisorie 1xx

La sezione 21.1 della RFC 3261 definisce le 1xx come risposte informative: il server contattato sta eseguendo altre operazioni e non dispone ancora di una risposta definitiva.

“The server contacted is performing some further action and does not yet have a definitive response.”
IL SERVER CONTATTATO STA ESEGUENDO ALTRE OPERAZIONI E NON HA ANCORA UNA RISPOSTA DEFINITIVA.

Una 1xx non chiude quindi la richiesta. Dice al mittente che l’elaborazione procede e può fornire informazioni utili sul suo stato. La RFC indica che un server invia una 1xx quando prevede di impiegare più di 200 millisecondi per ottenere una risposta definitiva. Questa soglia appartiene al comportamento definito dalla specifica, ma non va interpretata come una misura della qualità della voce o come un tempo massimo di instaurazione della chiamata.

Con INVITE è normale ricevere più risposte provvisorie. Una chiamata può attraversare un proxy, raggiungere un PBX, essere inoltrata a un gruppo e infine arrivare a un telefono. Lungo il percorso possono comparire più 100, 180 o 183, generati da elementi diversi. Non sono nuovi tentativi di chiamata: sono risposte associate alla richiesta iniziale, riconoscibili tramite Via, branch, Call-ID, CSeq e tag.

Per richieste diverse da INVITE, il comportamento atteso è più diretto: un UAS dovrebbe produrre quanto prima una risposta finale e non dovrebbe normalmente inviare una provvisoria. Per questo un 100 Trying dopo un OPTIONS o un BYE non va assunto come passaggio obbligatorio. Alcuni prodotti possono mostrarlo, ma non è il modello ordinario indicato dalla RFC.

100 Trying: la richiesta è in lavorazione

Il 100 Trying comunica che un elemento ha ricevuto la richiesta e sta lavorando per conto del mittente. In una chiamata reale può essere generato dal primo proxy, da un SBC o dal PBX. La sua funzione è particolarmente importante su UDP: informa l’UAC che la richiesta è arrivata a un elemento in grado di elaborarla e arresta le ritrasmissioni dell’INVITE su quel tratto.

Non significa che il telefono chiamato stia squillando, che l’utente sia stato trovato o che il percorso completo sia disponibile. Un SBC può rispondere immediatamente 100 Trying e poi non ricevere alcuna risposta dal trunk successivo. Dal punto di vista dell’utente la chiamata può restare silenziosa e infine fallire. Il 100 prova soltanto una fase locale dell’elaborazione.

La risposta 100 ha anche una particolarità: il tag nel campo To può mancare. Non bisogna quindi diagnosticare un errore soltanto perché il To del 100 non contiene un tag. Nelle risposte successive generate dallo UAS, invece, il tag identifica il lato che risponde e deve rimanere coerente per quella sequenza.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-a71;received=192.0.2.10
From: "Matteo" <sip:201@pbx.example.it>;tag=mt73
To: <sip:202@pbx.example.it>
Call-ID: 8f4c22@192.0.2.10
CSeq: 314 INVITE
Server: PBX-Aziendale
Content-Length: 0

La Status-Line dichiara che l’INVITE è in elaborazione. Il primo Via conserva il branch della richiesta e consente di correlare la risposta alla transaction corretta. From, To, Call-ID e CSeq riprendono i valori necessari a identificare lo scambio; CSeq: 314 INVITE chiarisce sia il numero sia il metodo al quale il server sta rispondendo. Non c’è un corpo e non viene negoziato alcun flusso audio.

I toni della telefonia non viaggiano sempre in rete

Per chi inizia a studiare il SIP serve un chiarimento importante. Il tono di libero, il tono di occupato, quello di congestione e gli altri segnali acustici che conosciamo non nascono nel VoIP nello stesso modo in cui venivano prodotti dalla vecchia telefonia analogica. Il SIP è un protocollo di segnalazione: comunica agli apparati lo stato di una richiesta. Telefoni, PBX, gateway e reti degli operatori trasformano poi quello stato in un suono comprensibile per l’utente, conservando abitudini costruite in decenni di telefonia tradizionale.

Nella maggior parte degli scenari aziendali il suono viene generato localmente. Il telefono o il PBX riceve una risposta SIP, ne interpreta il significato e riproduce il tono previsto dal proprio piano dei toni e dalla propria configurazione. Il caso più evidente in questo capitolo è il 180 Ringing: la rete informa che il destinatario viene avvisato e l’apparato del chiamante può produrre localmente il tono di libero. Quel suono non è stato registrato sul telefono chiamato e non ha attraversato il trunk come audio.

Lo stesso principio generale vale per altri esiti, come occupato o congestione, che affronteremo parlando delle classi successive. L’apparato riceve un’informazione di segnalazione e può trasformarla nel tono previsto per il paese, per il prodotto o per l’impianto. Frequenza, cadenza e durata non sono quindi proprietà del codice SIP: dipendono dal generatore locale e dal suo profilo. Un dispositivo configurato con il piano dei toni sbagliato può riprodurre un segnale insolito anche quando il provider ha inviato una risposta corretta.

Esiste però un secondo modello. La rete del provider può inviare il tono o un annuncio come audio inband, cioè dentro un flusso RTP anticipato. In questi casi compare spesso un 183 Session Progress con SDP. È una situazione tipica nelle terminazioni verso rete mobile: prima del 200 OK l’utente può ascoltare messaggi come numero non raggiungibile, telefono spento, credito insufficiente o altre comunicazioni generate dall’operatore. L’apparato locale non deve inventare quel contenuto; deve aprire correttamente il percorso audio e riprodurre ciò che arriva dalla rete.

Le due modalità possono produrre all’orecchio un risultato simile, ma nel tracciato pcap sono profondamente diverse. Nel primo caso vediamo la segnalazione e il tono nasce nel telefono o nel PBX. Nel secondo vediamo anche la negoziazione SDP e, se tutto funziona, i pacchetti RTP provenienti dalla rete. Questa distinzione evita di cercare in rete un audio che dovrebbe essere generato localmente oppure, al contrario, di attribuire al telefono un annuncio che deve arrivare inband dal provider.

180 Ringing: il destinatario viene avvisato

Il 180 Ringing indica che lo User Agent che ha ricevuto l’INVITE sta tentando di avvisare l’utente. In un telefono fisico può corrispondere alla suoneria; in un softphone può far comparire una finestra; in un gruppo di chiamata possono squillare più terminali. Il codice descrive lo stato della segnalazione, non certifica che una persona abbia davvero sentito la suoneria.

Quando l’UAC riceve un 180 senza SDP, può generare localmente il tono di libero. La RFC dice che la risposta MAY, cioè può, essere usata per avviare il tono locale. Non impone quindi un unico comportamento. Nella maggior parte degli impianti il suono ascoltato dal chiamante viene prodotto dal telefono, dal PBX o da un apparato intermedio secondo configurazione e architettura. Il 180 funziona come informazione di stato; non trasporta una registrazione del tono.

Questa distinzione risolve un equivoco comune: il 180 non contiene il tono di libero. Il pacchetto SIP porta un’informazione di stato; il suono richiede una generazione locale oppure un flusso RTP. Se nel tracciato compare 180 ma il chiamante non sente nulla, occorre verificare chi dovrebbe generare il tono. Cercare necessariamente pacchetti RTP può essere fuorviante, perché in questo scenario il flusso audio anticipato potrebbe non esistere.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-a71;received=192.0.2.10
From: "Matteo" <sip:201@pbx.example.it>;tag=mt73
To: "Daniele" <sip:202@pbx.example.it>;tag=dn91
Call-ID: 8f4c22@192.0.2.10
CSeq: 314 INVITE
Contact: <sip:202@198.51.100.24:5060>
Content-Length: 0

Il branch nel Via resta quello dell’INVITE. Call-ID e CSeq permettono di collegare il 180 alla stessa chiamata e alla stessa richiesta. Nel To compare ora il tag dn91, generato dal lato chiamato. Il Contact indica dove quel terminale può essere raggiunto per richieste successive nel dialogo; non è l’indirizzo al quale inviare il flusso RTP. Poiché Content-Length vale zero, questa risposta non contiene SDP.

181 e 182: inoltro e accodamento

Il 181 Call Is Being Forwarded può indicare che la chiamata viene inoltrata verso un diverso insieme di destinazioni. Per l’utente può non cambiare nulla: continuerà ad attendere mentre il PBX prova un cellulare, un collega o un altro gruppo. La risposta non rivela necessariamente il numero finale e non deve essere confusa con un metodo SIP chiamato “forward”. In Request-Line non compare alcun metodo con questo nome: il trasferimento di percorso è una decisione del server.

Molti PBX non inviano il 181 anche quando applicano un inoltro. Possono continuare con 100, 180 o 183 e nascondere la logica interna. La RFC consente l’uso del codice, ma la sua assenza non dimostra che non sia avvenuto un inoltro. I log applicativi del PBX e i rami SIP effettivamente generati restano spesso le fonti più utili.

Il 182 Queued informa invece che il destinatario è temporaneamente indisponibile ma il server ha deciso di accodare la chiamata invece di rifiutarla. La Reason-Phrase può aggiungere dati, come il numero di chiamate davanti o il tempo stimato, e il server può inviare più 182 per aggiornare la situazione. Nelle piattaforme di contact center moderne, tuttavia, messaggi vocali, posizione in coda e musica vengono spesso realizzati mediante servizi applicativi ed early media; non è garantito che il codice 182 sia visibile.

183 Session Progress ed early media

Il 183 Session Progress trasporta informazioni sull’avanzamento della chiamata che non rientrano nelle categorie precedenti. La Reason-Phrase, gli header o il corpo del messaggio possono offrire ulteriori dettagli. Nella pratica VoIP, il 183 è spesso associato a un corpo SDP e a un flusso RTP prima del 200 OK: il cosiddetto early media.

Immaginiamo una chiamata verso la rete telefonica. Il gateway riceve dall’operatore un annuncio: “il numero chiamato non è disponibile”. Se attendesse il 200 OK, la chiamata risulterebbe formalmente risposta e potrebbe iniziare la contabilizzazione. Il gateway può invece inviare 183 con SDP; una volta negoziati indirizzo, porta e codec, l’annuncio raggiunge il chiamante tramite RTP mentre l’INVITE non ha ancora ricevuto una risposta definitiva.

Lo stesso meccanismo può trasportare un tono di libero generato dalla rete remota, un tono speciale, una musica di attesa prima della risposta o un messaggio informativo. Questa modalità viene chiamata inband perché il segnale acustico viaggia nel flusso audio, come accadeva nella telefonia tradizionale. Il contenuto che l’utente sente non è nel codice 183. Il 183 e l’SDP preparano il percorso; la voce o il tono viaggiano nei pacchetti RTP. Se la segnalazione arriva ma l’RTP viene bloccato da NAT, firewall o indirizzi SDP errati, il chiamante può sentire silenzio.

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-a71;received=192.0.2.10
From: "Matteo" <sip:201@pbx.example.it>;tag=mt73
To: <sip:+390555550202@operatore.example>;tag=gw48
Call-ID: 8f4c22@192.0.2.10
CSeq: 314 INVITE
Contact: <sip:gateway@198.51.100.40:5060>
Content-Type: application/sdp
Content-Length: 146

v=0
o=gateway 481 481 IN IP4 198.51.100.40
s=-
c=IN IP4 198.51.100.40
t=0 0
m=audio 24000 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

La Status-Line dice che la sessione sta avanzando, non che la chiamata è stata accettata. Via, branch, Call-ID e CSeq collegano la risposta all’INVITE. Il tag nel To identifica il lato remoto che risponde. Content-Type annuncia un corpo SDP. Le righe c= e m=audio indicano che il gateway propone di ricevere o inviare audio all’indirizzo 198.51.100.40, porta UDP 24000. Il payload type 8 identifica PCMA e il 101 gli eventi DTMF secondo la mappatura dichiarata.

Non tutti i 183 contengono SDP e non ogni SDP provvisorio produce necessariamente audio. Inoltre, l’affidabilità delle risposte provvisorie può essere estesa da meccanismi specifici, ma questa materia esce dai confini della RFC 3261 di base e di questo capitolo. Ai fini dell’analisi operativa, conviene verificare che cosa è realmente presente nel pacchetto e se dopo la risposta comincia un flusso RTP coerente.

Le risposte positive 2xx

La sezione 21.2 della RFC 3261 assegna alle 2xx un significato netto:

“The request was successful.”
LA RICHIESTA HA AVUTO SUCCESSO.

La parola importante è “richiesta”. Il successo riguarda il metodo indicato nel CSeq, non un’intera esperienza utente e neppure tutti i componenti del servizio. Un 200 OK a REGISTER conferma che il registrar ha accettato l’operazione di registrazione descritta dalla richiesta. Un 200 OK a OPTIONS indica che la richiesta è stata elaborata e può riportare le capacità del destinatario. Un 200 OK a BYE conferma la terminazione del dialogo dal punto di vista SIP. Un 200 OK a INVITE accetta l’invito e, quando è presente SDP, completa o porta avanti la negoziazione della sessione.

Per questo non è corretto dire che “200 OK significa che va tutto bene”. Un trunk può rispondere 200 OK a OPTIONS ma fallire le chiamate per problemi di autenticazione, credito, instradamento o audio. Un REGISTER può ricevere 200 OK e il telefono può comunque non essere raggiungibile a causa di una mappatura NAT scaduta. Il codice certifica l’esito della richiesta osservata; il tecnico deve poi verificare il servizio completo.

200 OK a INVITE

Quando Daniele risponde, il suo terminale o il PBX genera un 200 OK all’INVITE. Per l’utente chiamante il tono di libero termina e si apre la conversazione. Dal punto di vista della segnalazione, il 200 è una risposta definitiva positiva. Il chiamante deve confermarne la ricezione con ACK. Solo leggendo la sequenza INVITE, 1xx, 200 OK e ACK si vede il completamento corretto dell’instaurazione.

Il 200 OK a INVITE include normalmente un Contact e può contenere SDP. Se l’INVITE iniziale conteneva un’offerta SDP, il 200 trasporta la risposta; se l’offerta non era presente nell’INVITE, può trovarsi nel 200 e la risposta dovrà seguire nell’ACK. Queste varianti fanno parte del modello di offerta e risposta già richiamato parlando di re-INVITE. Non bisogna quindi stabilire a priori che ogni 200 OK abbia lo stesso corpo.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-a71;received=192.0.2.10
From: "Matteo" <sip:201@pbx.example.it>;tag=mt73
To: "Daniele" <sip:202@pbx.example.it>;tag=dn91
Call-ID: 8f4c22@192.0.2.10
CSeq: 314 INVITE
Contact: <sip:202@198.51.100.24:5060>
Content-Type: application/sdp
Content-Length: 123

v=0
o=telefono 902 903 IN IP4 198.51.100.24
s=-
c=IN IP4 198.51.100.24
t=0 0
m=audio 31000 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=sendrecv

La Status-Line rende definitivo e positivo l’esito dell’INVITE. Via e branch consentono alla risposta di tornare lungo il percorso e di essere associata allo scambio corretto. From, To con tag, Call-ID e CSeq mantengono la correlazione. Il Contact presenta l’URI del lato remoto per richieste successive; anche in questo caso non va confuso con la destinazione RTP. Nel corpo SDP, l’indirizzo 198.51.100.24 e la porta 31000 definiscono invece il recapito proposto per l’audio PCMA.

Dopo il 200 OK, l’ACK dell’UAC completa la procedura SIP dell’INVITE. L’assenza dell’ACK è riconoscibile dalle ritrasmissioni del 200 OK, soprattutto su UDP. L’audio può persino essere già presente, ma la segnalazione resta incompleta. Se il 200 viene ritrasmesso e l’ACK non compare sul lato remoto, occorre controllare percorso SIP, Contact, Route, NAT e comportamento degli apparati intermedi, senza attribuire subito il problema ai codec.

200 OK non significa sempre risposta alla chiamata

Consideriamo un REGISTER. Il telefono invia i propri binding al registrar e riceve 200 OK. In questo caso non esistono chiamante, chiamato, tono di libero o RTP. Il CSeq contiene REGISTER e il Contact della risposta può riportare i binding accettati con la relativa scadenza. Leggere soltanto “200 OK” e classificarlo come chiamata risposta sarebbe un errore elementare ma frequente quando si filtrano grandi acquisizioni.

Con OPTIONS accade qualcosa di simile. Il 200 conferma l’elaborazione della richiesta e può contenere header come Allow, Supported e Accept. Come visto nel Capitolo 10, questa risposta dimostra che un elemento SIP ha risposto; non certifica da sola che la fonia, l’instradamento e tutti i servizi siano funzionanti.

Un 200 OK a CANCEL conferma che la richiesta CANCEL è stata accettata per l’elaborazione, ma non sostituisce la risposta finale all’INVITE originale. Normalmente l’INVITE riceverà una propria risposta, spesso 487 Request Terminated. Sono due transaction correlate ma distinte. Analogamente, il 200 OK a BYE conferma il BYE e non richiede un ACK: l’ACK appartiene alla gestione delle risposte finali a INVITE, non a ogni 200 presente nel protocollo.

Nel re-INVITE, infine, un 200 OK non crea una seconda chiamata. Accetta la modifica proposta all’interno della sessione esistente. Può confermare la ripresa dalla messa in attesa, un nuovo codec o un cambio di indirizzo e porta RTP. Il Call-ID resta quello del dialogo, mentre il CSeq permette di distinguere il nuovo INVITE da quello iniziale.

Risposta definitiva e comportamento dei rami

Quando un proxy inoltra un INVITE verso più destinazioni, il tracciato può mostrare più risposte provvisorie con tag To differenti. Due telefoni possono inviare 180; uno può inviare 183 con SDP; infine uno dei rami risponde 200 OK. Per il chiamante sembrano sempre pochi secondi di attesa, ma nella segnalazione esistono più tentativi paralleli.

La presenza di tag diversi non indica automaticamente una chiamata duplicata o corrotta. Può rappresentare il forking, cioè l’inoltro della stessa richiesta verso più destinazioni. La trattazione completa dei proxy e dei dialoghi arriverà più avanti nella collana; per ora basta non correlare le risposte usando soltanto Call-ID e numero CSeq. Occorre osservare anche i tag e la catena dei Via.

Le risposte seguono il percorso descritto dai Via, in ordine inverso rispetto alla richiesta. Ogni proxy rimuove il proprio Via superiore prima di inoltrare la risposta al tratto precedente. Per questo l’indirizzo nel Contact non determina il viaggio della risposta corrente. Confondere Via, Contact e indirizzi SDP porta a diagnosi sbagliate: il primo serve al ritorno delle risposte, il secondo alle richieste successive e l’SDP ai flussi multimediali.

Errori di lettura ricorrenti

Considerare ogni 1xx come prova che il telefono remoto squilla. Il 100 dice soltanto che la richiesta è in elaborazione. Il 183 descrive un avanzamento e può precedere un annuncio. Il 180 è il codice più vicino al concetto di avviso del chiamato, ma anche in quel caso l’effetto concreto dipende dall’apparato e dalla configurazione.

Confondere segnalazione e audio. Un codice SIP non contiene per forza il suono ascoltato. Il tono locale viene generato da un apparato; l’early media viaggia in RTP. Occorre analizzare entrambi i piani senza dedurre la presenza dell’uno dalla sola esistenza dell’altro.

Attribuire ogni tono errato al provider. Se il tono deve essere prodotto localmente, il provider consegna la risposta SIP ma non genera il suono ascoltato. Un piano dei toni errato, un profilo paese non corretto o una gestione sbagliata delle risposte nel telefono o nel PBX sono cause più probabili. Il provider entra direttamente nella verifica del contenuto acustico quando invia early media inband; anche in quel caso vanno prima esclusi blocchi RTP e problemi SDP lungo il percorso.

Interpretare il 183 come risposta della persona. Un annuncio o un tono remoto può essere ricevuto prima della risposta finale. Per stabilire se l’INVITE è stato accettato bisogna cercare la 2xx definitiva e il successivo ACK, non affidarsi alla percezione di una voce registrata.

Leggere il 200 senza leggere il CSeq. Il metodo nel CSeq stabilisce quale operazione è riuscita. Un 200 a OPTIONS, REGISTER, CANCEL, BYE e INVITE ha conseguenze differenti. La Status-Line da sola non fornisce il contesto sufficiente.

Usare la Reason-Phrase come dato normativo. Un prodotto può mostrare SIP/2.0 180 Sta squillando o un testo proprietario. Il codice 180 conserva il significato protocollare. Filtri, allarmi e correlazioni devono basarsi sul numero e sugli altri campi SIP, non su una frase che può cambiare.

Attribuire ogni risposta al telefono. Proxy, PBX, SBC, gateway e servizi applicativi possono generare risposte. Il campo Server o User-Agent può aiutare, ma non è sempre presente e può essere modificato. Indirizzi IP, Via, direzione dei pacchetti e conoscenza dell’architettura sono necessari per identificare con affidabilità l’origine.

Un metodo pratico di analisi

Quando si incontra una risposta 1xx o 2xx, conviene seguire una sequenza stabile. Prima si legge il CSeq per sapere a quale metodo si riferisce. Poi si confrontano Call-ID, branch e tag per capire a quale scambio e a quale ramo appartiene. Si identifica l’apparato che ha inviato il pacchetto e si osserva se il messaggio contiene SDP. Infine si collega la segnalazione a ciò che accade davvero: tono locale, RTP anticipato, risposta dell’utente, registrazione completata o chiusura della chiamata.

Questo metodo evita diagnosi basate su una sola riga. Se il chiamante sente silenzio fra INVITE e 200 OK, il 180 senza SDP orienta verso la generazione locale del tono e quindi verso la configurazione del dispositivo; il 183 con SDP orienta verso il percorso RTP anticipato e soltanto dopo verso il contenuto fornito dal provider. Se il telefono continua a mostrare “connessione” dopo un 200 OK a INVITE, la ricerca si sposta sull’ACK e sulla gestione del dialogo. Se un monitor dichiara il trunk disponibile grazie a un 200 OK a OPTIONS ma le chiamate falliscono, si deve testare l’intero servizio e non contestare il significato della risposta.

Dalla progressione positiva agli altri esiti

Le classi 1xx e 2xx raccontano due momenti diversi: elaborazione in corso e successo definitivo della richiesta. Fra questi due momenti l’utente può sentire un tono generato localmente, ricevere early media dalla rete, vedere un inoltro o restare in coda. SIP descrive lo stato della segnalazione; RTP porta l’audio; PBX, SBC, gateway e terminali trasformano quei messaggi in un comportamento percepibile.

La lettura corretta nasce dalla correlazione. Status-Code, CSeq, Via, branch, tag, Call-ID, Contact e SDP rispondono a domande differenti. Riunirli permette di capire se la richiesta sta ancora avanzando, chi ha prodotto la risposta, dove viaggeranno i messaggi successivi e se esiste già un flusso audio.

Non tutte le richieste, però, terminano con un 200 OK. A volte la rete propone un’altra destinazione; altre volte la richiesta è incompleta, non autorizzata o non può essere soddisfatta dal destinatario. Nel prossimo capitolo analizzeremo le classi 3xx e 4xx, collegando reindirizzamenti ed errori della richiesta ai casi che un tecnico incontra ogni giorno.