RFC 3261: Il DNA del VoIP – Capitolo 5
Come UAC e UAS trattano una richiesta

Nel capitolo precedente abbiamo visto le regole generali del comportamento degli User Agent. Ora facciamo il passo successivo. Entriamo nelle sottosezioni 8.1 e 8.2 della RFC 3261 per capire come un UAC costruisce e invia una richiesta e come un UAS la riceve, la controlla e risponde.

Questo è uno dei punti in cui SIP diventa molto concreto. Finché restiamo sul piano dei ruoli, tutto sembra ordinato ma ancora un po’ astratto. Quando invece guardiamo come nasce una richiesta e come viene trattata dall’altro lato, il protocollo mostra il suo carattere vero. E nei tracciati SIP è proprio qui che iniziano molti problemi reali.

Una richiesta SIP non va solo inviata. Va costruita bene. E chi la riceve non deve solo rispondere. Deve prima capire se quella richiesta è corretta, se è rivolta al nodo giusto, se il metodo è supportato e se il contenuto si può accettare. Questa è la base del capitolo.

Il lato UAC

La Sezione 8.1 descrive il comportamento del User Agent Client. In termini semplici, il UAC è il lato che genera la richiesta. Ma dire solo questo non basta. Il suo compito non è mandare un messaggio. Il suo compito è costruire una richiesta che la rete e il destinatario possano leggere e trattare senza ambiguità.

La RFC parte da un’idea chiara: una richiesta SIP deve contenere un insieme minimo di informazioni che permetta di capirne origine, destinazione, contesto e ordine logico. Se uno di questi elementi è sbagliato, il problema non nasce nella risposta finale. Nasce molto prima, nella costruzione stessa del messaggio.

Per questo la lettura del lato UAC è così importante anche nel troubleshooting. Molti errori che sembrano colpa del nodo remoto sono in realtà conseguenza di una richiesta partita male.

Costruire la richiesta

La RFC elenca una serie di elementi che il UAC deve inserire e gestire bene quando costruisce una richiesta. Non li analizziamo ancora tutti in modo completo, ma qui iniziano davvero a contare: Request-URI, To, From, Call-ID, CSeq, Max-Forwards, Via, Contact e, quando serve, il contenuto del body.

Non serve memorizzare una lista. Serve capire che ognuno di questi campi ha una funzione precisa. Il Request-URI indica la destinazione operativa della richiesta. Il To e il From definiscono le identità coinvolte. Il Call-ID aiuta a collegare i messaggi tra loro. Il CSeq mantiene l’ordine logico delle richieste. Il Via aiuta il ritorno delle risposte. Il Contact dice dove il nodo potrà essere raggiunto in seguito.

Quando questi campi sono coerenti, il flusso regge. Quando uno di questi campi è debole, sbagliato o incoerente, la richiesta può essere rifiutata, inoltrata male o accettata solo in apparenza.

I campi che pesano di più

Alcuni campi, nella pratica, pesano più di altri. Il primo è il Request-URI. Se è sbagliato, la richiesta va nel posto sbagliato o viene trattata dal nodo sbagliato. Subito dopo c’è il Via. Se non è coerente, le risposte possono non tornare dove dovrebbero. Poi c’è il Contact. Se punta a un indirizzo inutile o non raggiungibile, i messaggi successivi rischiano di rompersi. Un caso tipico è questo: un client SIP collegato su rete pubblica inserisce nel Contact un IP privato, per esempio 192.168.1.100. Se dall’altra parte non c’è un meccanismo di correzione, come un SIP helper o una riscrittura fatta dalla centrale, quel nodo proverà a inviare la risposta o le richieste successive verso quell’indirizzo privato. E naturalmente non potrà raggiungerlo.

Anche Call-ID e CSeq vanno gestiti con attenzione. Il primo serve a identificare il contesto della comunicazione. Il secondo serve a mantenere l’ordine corretto delle richieste. Quando questi due elementi sono gestiti male, il flusso SIP diventa difficile da seguire e il nodo remoto può reagire in modo inatteso.

Nel lavoro quotidiano conviene fare una regola semplice: prima di commentare il codice di risposta, guardare come è nata la richiesta.

Invio della richiesta

Dopo la costruzione arriva l’invio. La Sezione 8.1.2 ricorda che il UAC non deve solo preparare il messaggio, ma anche spedirlo verso destinazione usando il trasporto corretto e con informazioni coerenti con il percorso previsto.

Questo punto sembra banale, ma non lo è. Una richiesta formalmente ben costruita può fallire comunque se viene inviata verso il nodo sbagliato, con un trasporto non adatto o con parametri che non corrispondono alla realtà della rete. È uno dei motivi per cui nei sistemi reali non basta guardare il testo del messaggio. Bisogna sempre collegarlo al percorso che sta facendo.

Nel tracciato SIP questo si vede bene quando il messaggio sembra corretto ma la risposta non torna, torna in modo strano oppure non arriva affatto. In questi casi il problema può stare non nella logica del metodo, ma nel modo in cui la richiesta è stata instradata o trasmessa.

Come il UAC legge le risposte

Il lavoro del UAC non finisce quando la richiesta parte. La Sezione 8.1.3 spiega che il client deve anche saper leggere le risposte ricevute e reagire nel modo giusto.

Qui torna un’idea importante del SIP: una risposta non è solo un esito. Spesso è anche un’indicazione su che cosa fare dopo. Una risposta 3xx può indicare un’altra destinazione. Una 401 o una 407 può chiedere di ripetere la richiesta con autenticazione. Una 415 può dire che il contenuto non va bene. Una 420 può segnalare che un’estensione richiesta non è supportata.

Questo significa che un buon UAC non si limita a ricevere il codice di risposta. Deve capirne il significato e reagire in modo coerente. Nei sistemi fatti bene questo si vede subito. Nei sistemi deboli, invece, ogni errore viene trattato come un blocco definitivo oppure viene aggirato con soluzioni proprietarie che peggiorano la compatibilità con gli altri nodi SIP.

Il lato UAS

Dall’altra parte c’è il User Agent Server. La Sezione 8.2 descrive come una richiesta ricevuta debba essere letta e trattata. Qui il punto decisivo è questo: il UAS non può rispondere in modo casuale. Deve seguire un ordine di controllo preciso.

Questo ordine conta molto. Quando una richiesta arriva, il nodo deve prima capire se può accettarla in termini generali, poi se il metodo è supportato, poi se gli header sono corretti, poi se il contenuto si può gestire. Solo dopo questi passaggi può davvero elaborare la richiesta e formulare la risposta.

Nel troubleshooting questo schema è molto utile. Quando una richiesta viene rifiutata, non basta chiedersi perché. Conviene chiedersi in quale fase del controllo si è fermata.

Ordine dei controlli

La RFC suggerisce un ordine chiaro. Prima l’autenticazione. Poi l’ispezione del metodo. Poi il controllo degli header. Poi il controllo del contenuto. Poi l’applicazione di eventuali estensioni. Solo dopo arriva il trattamento vero e proprio della richiesta.

“UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section).”
“Gli UAS dovrebbero elaborare le richieste seguendo l’ordine dei passi che seguono in questa sezione, cioè iniziando dall’autenticazione, poi dall’ispezione del metodo, dei campi header e così via per il resto della sezione.”

Questo ordine non è solo una formalità. Serve a evitare risposte confuse. Se il nodo controlla prima le cose essenziali, il motivo del rifiuto resta chiaro e il comportamento del protocollo rimane leggibile. Se invece i controlli vengono fatti in modo disordinato, anche il tracciato diventa più difficile da capire.

Controllo del metodo

Uno dei primi filtri reali è il metodo. Il UAS deve capire se riconosce il metodo ricevuto e se lo supporta. Se il metodo è noto ma non supportato, la RFC chiede una risposta 405 Method Not Allowed con l’header Allow che elenca i metodi supportati.

Questo passaggio è utile perché mostra bene la logica del SIP. Il protocollo non risponde con un generico errore. Cerca di dire quale errore è avvenuto e in che modo va letto. Una 405 non racconta la stessa cosa di una 403, di una 404 o di una 420.

Nel tracciato SIP questo fa la differenza. Se leggiamo tutti i 4xx come rifiuti uguali, perdiamo informazione. Se invece leggiamo il codice giusto nel punto giusto, capiamo molto meglio il ragionamento del nodo remoto.

Controllo degli header

Dopo il metodo arrivano gli header. La RFC distingue bene tra header che contano davvero per la logica della richiesta e header che possono essere ignorati se non sono capiti o non sono rilevanti per quel nodo.

Questa distinzione è molto importante. Il protocollo deve poter crescere senza rompersi ogni volta che compare un’informazione nuova o proprietaria. Per questo un UAS non deve rifiutare una richiesta solo perché vede un header sconosciuto che non cambia il senso del messaggio.

Nel lavoro quotidiano questo punto torna spesso quando si analizzano richieste generate da piattaforme diverse. Alcune aggiungono header proprietari, altre usano estensioni particolari. Se il nodo remoto sa distinguere ciò che conta da ciò che non conta, il sistema resta compatibile. Se non lo sa fare, i problemi aumentano subito.

Request-URI, To e bersaglio reale

Uno dei punti più utili di questa parte della RFC è la distinzione tra To e Request-URI. Il To indica il destinatario dichiarato dal mittente. Il Request-URI, invece, indica il vero bersaglio operativo della richiesta.

Questa differenza conta molto perché, con proxy, inoltri o altre logiche di rete, il nome del destinatario e il nodo che deve davvero trattare la richiesta possono non coincidere. Per questo la RFC chiede al UAS di essere più tollerante sul To e più rigoroso sul Request-URI.

In Wireshark questo è un controllo che conviene fare quasi sempre. Quando una risposta sembra strana, guardare solo il To può portare fuori strada. Il Request-URI, molto spesso, spiega meglio perché il nodo abbia accettato o rifiutato la richiesta.

Controllo del contenuto

Se la richiesta contiene un body, il UAS deve capire anche se quel contenuto si può trattare. Qui entrano in gioco il tipo di contenuto, il modo in cui è descritto e la capacità del nodo di gestirlo.

Questo passaggio è spesso sottovalutato. Si tende a pensare che il problema stia sempre negli header o nel metodo. In realtà molte richieste vengono rifiutate perché il contenuto non è compatibile, non è supportato o non è descritto nel modo giusto.

È il caso classico delle risposte come 415 Unsupported Media Type. Quando compaiono, il messaggio da leggere è chiaro: il nodo ha capito la richiesta, ma non può accettare quel contenuto in quella forma.

Risposta provvisoria e risposta finale

Una volta fatti i controlli, il UAS deve rispondere nel modo corretto. Qui la RFC distingue tra risposte provvisorie e risposte finali. Anche questo non è un dettaglio. Le risposte provvisorie servono a dire che qualcosa sta andando avanti. Le risposte finali chiudono davvero lo scambio dal punto di vista di quella richiesta.

Nel lavoro quotidiano questa differenza è importante perché cambia il modo in cui il lato UAC legge la situazione. Un 100 Trying non racconta la stessa cosa di un 180 Ringing, e nessuna delle due racconta la stessa cosa di un 200 OK o di un 4xx.

La risposta giusta non serve solo a chiudere il flusso. Serve a far capire in modo chiaro in che stato si trova la richiesta.

Un esempio minimo

Per fissare le idee, guardiamo un esempio semplice. Daniele invia un INVITE verso Matteo. Qui non ci interessa ancora tutta l’analisi dei singoli header. Ci interessa vedere che il lato UAC costruisca la richiesta in modo pulito e che il lato UAS la controlli secondo un ordine chiaro.

INVITE sip:matteo@user.voipvoice.it SIP/2.0
Via: SIP/2.0/UDP pbx.user.voipvoice.it;branch=z9hG4bK-12345
Max-Forwards: 70
From: <sip:daniele@user.voipvoice.it>;tag=abc123
To: <sip:matteo@user.voipvoice.it>
Call-ID: 123456@pbx.user.voipvoice.it
CSeq: 1 INVITE
Contact: <sip:daniele@user.voipvoice.it>

Daniele, come UAC, deve costruire bene la richiesta. Matteo, o il nodo che agirà come UAS, deve capire se il metodo è supportato, se la richiesta è davvero per lui, se gli header essenziali sono coerenti e se il contenuto si può trattare.

Se guardiamo solo la presenza di un INVITE, vediamo solo la superficie. Se invece osserviamo come quella richiesta è stata costruita e come viene controllata, leggiamo molto meglio il comportamento reale dello User Agent.

Cosa guardare nel tracciato pcap

Quando una richiesta SIP dà problemi, ci sono alcune verifiche che conviene fare subito. Prima il Request-URI. Poi il Via. Poi il Contact. Poi Call-ID e CSeq. Dopo questi elementi, ha senso guardare il metodo, il contenuto e il codice di risposta ricevuto.

Questo ordine aiuta molto. Evita di partire dalla fine del flusso e costringe a guardare prima la qualità della richiesta. In molti casi è proprio lì che si trova l’errore.

Conclusione

In questo capitolo abbiamo visto una cosa essenziale: una richiesta SIP vive su due lati. Da un lato c’è il UAC, che la costruisce e la invia. Dall’altro c’è il UAS, che la controlla e decide come rispondere. Se uno dei due lati lavora male, il flusso si rompe.

Nel prossimo capitolo potremo entrare ancora di più nel dettaglio dei singoli campi della richiesta e del loro peso reale nel comportamento della rete SIP.