RFC 3261: Il DNA del VoIP – Capitolo 4
Il comportamento degli User Agent

Dopo aver chiarito nel capitolo precedente che cosa siano User Agent, UAC e UAS, a questo punto dobbiamo fare un passo in avanti. Fin qui abbiamo costruito il vocabolario. Adesso dobbiamo vedere come quel vocabolario si traduce in comportamento operativo reale.

In questo articolo entriamo nella Sezione 8 della RFC 3261 per capire che cosa significhi General User Agent Behavior. Qui la RFC non si limita a definire dei ruoli. Spiega le regole comuni con cui uno User Agent costruisce una richiesta, la invia, riceve una risposta, ispeziona un messaggio e decide come reagire.

Questa sezione potrebbe sembrare di raccordo, ma non lo è. La RFC chiarisce che esistono regole comuni valide per tutti i metodi. Queste regole governano il comportamento del UAC quando costruisce una richiesta e del UAS quando riceve una richiesta e genera una risposta. Qui il comportamento degli endpoint diventa leggibile con precisione.

Regole generali

Per capire il senso di questa sezione bisogna collegarla alla struttura del protocollo descritta poco prima nella RFC. La specifica spiega che i diversi elementi SIP sono ruoli logici e che, sopra il livello di trasporto e sopra il livello delle transazioni, esiste un core che distingue i diversi tipi di elemento. Per gli User Agent, questo core è proprio il luogo in cui vivono le regole comuni della Sezione 8.

“While the behavior of the UAC and UAS cores depends on the method, there are some common rules for all methods (Section 8). For a UAC, these rules govern the construction of a request; for a UAS, they govern the processing of a request and generating a response.”
“Anche se il comportamento del core UAC e del core UAS dipende dal metodo, esistono alcune regole comuni valide per tutti i metodi (Sezione 8). Per un UAC, queste regole governano la costruzione di una richiesta; per un UAS, governano l’elaborazione di una richiesta e la generazione di una risposta.”

Il punto è semplice: prima dei dettagli di INVITE, REGISTER, OPTIONS o BYE, esiste un insieme di regole generali per il comportamento degli User Agent. È una grammatica operativa comune. Nel lavoro quotidiano questa distinzione aiuta a capire se stiamo osservando una regola generale del protocollo o il comportamento di un metodo specifico.

Nel tracciato SIP questo punto si vede molto bene. Alcuni errori che sembrano “problemi di INVITE” o “problemi di BYE”, in realtà, nascono da una violazione di regole più generali: costruzione incompleta della richiesta, ispezione errata di header fondamentali, uso sbagliato dei codici di risposta, gestione incoerente di estensioni o contenuti. Quando si capisce bene il ruolo della Sezione 8, diventa più facile riconoscere questi casi.

Comportamento generale

Quando la RFC parla di General User Agent Behavior, non sta descrivendo una singola macchina a stati in senso stretto. Sta definendo un insieme di regole comuni che ogni User Agent deve saper applicare quando si comporta da client o da server della segnalazione.

Da un lato c’è il UAC, che genera la richiesta, la costruisce in modo coerente e poi sa interpretare le risposte ricevute. Dall’altro lato c’è il UAS, che riceve una richiesta, la ispeziona, decide se accettarla, rifiutarla o reindirizzarla, e formula la risposta corretta. Questo è il punto decisivo: lo User Agent non è solo il nodo che “partecipa alla chiamata”. È il luogo in cui le regole del protocollo vengono applicate davvero.

Nel lavoro quotidiano questa distinzione è utile. Quando un terminale SIP o un PBX si comporta in modo anomalo, spesso il problema non è nella teoria del protocollo. Il problema è che quel nodo, in quel passaggio, non sta applicando bene una regola da UAC o da UAS. Per questo la Sezione 8 è anche uno strumento diagnostico.

Il lato UAC

Il primo grande fronte della Sezione 8 riguarda il comportamento del User Agent Client. Qui la RFC si concentra sul fatto che una richiesta SIP non nasce come un testo libero. Deve essere costruita secondo regole ben precise: destinazione corretta, header obbligatori coerenti, valori che si possano collegare tra loro, informazioni di instradamento corrette e, quando serve, contenuto descritto in modo accurato.

Questo punto è decisivo. In SIP una richiesta mal costruita non è un dettaglio estetico. È un errore che cambia direttamente il comportamento della rete. Un Request-URI sbagliato può mandare la richiesta al nodo errato. Un Via incoerente può compromettere il ritorno delle risposte. Un Contact inaffidabile può rendere irraggiungibile lo User Agent nelle richieste successive. Un CSeq gestito male può rompere il collegamento logico del flusso.

L’esame completo di queste sottosezioni arriverà nel capitolo successivo. Qui basta fissare la logica di fondo: il UAC non “manda un messaggio”. Costruisce una richiesta che deve essere leggibile, coerente e utilizzabile dall’intera rete SIP.

Nel tracciato SIP questo passaggio si vede subito. Quando una richiesta nasce bene, il flusso successivo diventa ordinato. Quando nasce male, iniziano risposte apparentemente misteriose, percorsi incoerenti, ritrasmissioni, errori di instradamento o rifiuti che a colpo d’occhio sembrano colpa del nodo remoto ma che in realtà hanno origine molto prima.

Il lato UAS

L’altro grande fronte della Sezione 8 riguarda il comportamento del User Agent Server. Qui la RFC descrive la logica con cui una richiesta ricevuta deve essere trattata. E questo passaggio è molto più importante di quanto sembri, perché ci dice che il nodo che riceve una richiesta non può reagire in modo arbitrario. Deve seguire un ordine di controllo preciso.

Per le richieste fuori da un dialogo, il UAS dovrebbe seguire un ordine preciso: autenticazione, ispezione del metodo, controllo degli header, controllo del contenuto, applicazione di eventuali estensioni e solo dopo elaborazione vera e propria della richiesta. Il protocollo non lascia al server una risposta istintiva. Gli chiede un comportamento disciplinato.

“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.”

Qui la RFC ci sta dicendo una cosa molto concreta: una richiesta SIP va letta e valutata per livelli, non in modo confuso o casuale. Nel lavoro quotidiano questo approccio è estremamente utile anche nel troubleshooting. Quando una richiesta viene rifiutata, la domanda corretta non è solo “perché è stata rifiutata?”, ma “in quale fase della valutazione è stata rifiutata?”. È una differenza enorme.

Atomicità della richiesta

La Sezione 8 chiarisce anche un principio molto importante sul lato UAS: l’elaborazione della richiesta è atomica. Se il server accetta la richiesta, tutti i cambiamenti di stato associati devono essere eseguiti. Se la rifiuta, quei cambiamenti non devono avvenire.

Detto così può sembrare un dettaglio teorico. In realtà non lo è. Questo principio serve a evitare che il comportamento del nodo diventi ambiguo. Una richiesta SIP non può essere “mezzo accettata”. O produce gli effetti previsti, oppure non li produce. È una regola semplice che rende il protocollo più chiaro e più solido.

Nel tracciato SIP questo punto si riflette spesso nei casi in cui un sistema applica modifiche parziali allo stato interno, oppure in cui sembra accettare una richiesta ma poi si comporta come se non l’avesse realmente integrata. Sul campo questo problema compare in modo particolare quando le implementazioni sono deboli o quando un B2BUA o un PBX ibrido mescolano logiche interne e logiche RFC in modo poco trasparente.

Controllo del metodo

Una delle prime verifiche esplicite descritte nella Sezione 8 è l’ispezione del metodo. Una volta superato il controllo di autenticazione, il UAS deve capire se riconosce e supporta il metodo ricevuto. Se lo riconosce ma non lo supporta, la RFC è molto chiara: deve generare una risposta 405 Method Not Allowed e indicare i metodi supportati tramite header Allow.

Questo è un passaggio molto istruttivo, perché ci mostra che il protocollo non si limita a dire “errore”. Dice anche quale tipo di errore e, soprattutto, come deve essere qualificato. In SIP il codice di risposta non è una decorazione. È parte delil significato operativo. Una risposta corretta aiuta il nodo remoto a capire se il problema sia sintattico, funzionale o legato alle capacità dichiarate.

Nel tracciato SIP questo passaggio si vede bene quando un nodo riceve richieste che non sa gestire o che non sono abilitate sulla sua implementazione. Un errore frequente consiste nel leggere ogni 4xx come rifiuto generico. In realtà qui la differenza tra 405, 403, 404, 415, 416 o 420 racconta cose molto diverse sulla logica che il server sta applicando.

Controllo degli header

Un altro passaggio fondamentale della Sezione 8 riguarda l’ispezione degli header. La RFC dice che, se un UAS non comprende un determinato header non definito nella specifica o in un’estensione supportata, deve ignorarlo e continuare l’elaborazione. Questo è un punto molto interessante, perché mostra una filosofia precisa del protocollo: potersi estendere senza diventare fragile.

Qui si vede bene una differenza importante. Non tutti gli header hanno lo stesso peso. Alcuni sono centrali per la corretta elaborazione della richiesta. Altri possono essere ignorati se non compresi, purché non siano necessari per la logica del messaggio. È una regola molto utile per la compatibilità tra sistemi, perché evita che la sola presenza di informazioni non rilevanti o non supportate faccia fallire inutilmente lo scambio.

Nel tracciato SIP questo passaggio è molto utile quando si analizzano richieste che contengono estensioni, header proprietari o variazioni introdotte da piattaforme specifiche. Un errore frequente consiste nel credere che ogni header sconosciuto debba produrre un rifiuto. La RFC, invece, distingue. E questa distinzione, sul campo, evita molte letture superficiali.

Request-URI e To

Uno dei punti più utili della Sezione 8, anche per il troubleshooting, è la distinzione tra To e Request-URI. Su questo punto molti tracciati vengono letti male. Il campo To indica il destinatario originariamente pensato dal mittente. Il Request-URI, invece, identifica il bersaglio operativo della richiesta, cioè il nodo che deve realmente processarla.

Questa differenza è fondamentale perché, a causa di proxy, inoltri o altre logiche di rete, il destinatario nominale e il nodo che riceve davvero la richiesta possono non coincidere. Per questo la RFC chiede al UAS di essere più tollerante sul campo To, mentre sul Request-URI il controllo deve essere molto più rigoroso.

Nella pratica questa distinzione conta soprattutto quando si analizzano richieste deviate, inoltrate o passate attraverso piattaforme intermedie. In Wireshark conviene quindi verificare sempre se il nodo che risponde stia reagendo al To, cioè al destinatario dichiarato, oppure al Request-URI, cioè al vero obiettivo della richiesta. Quando questa differenza viene gestita male, il risultato tipico è una risposta che sembra inspiegabile se si guarda solo al nome del destinatario originale.

Le risposte

La Sezione 8 non riguarda solo la ricezione della richiesta. Riguarda anche il modo in cui le risposte vengono interpretate dal lato UAC e generate dal lato UAS. Questo è uno dei punti in cui il comportamento degli User Agent diventa davvero leggibile nel tracciato SIP.

Dal lato UAC, la RFC prevede che alcune classi di risposta producano reazioni precise. Per esempio, in caso di 401 Unauthorized o 407 Proxy Authentication Required, il client dovrebbe ritentare la richiesta seguendo la procedura di autorizzazione. In caso di 415 Unsupported Media Type, dovrebbe adeguare il contenuto alle capability dichiarate. In caso di 416 Unsupported URI Scheme o 420 Bad Extension, dovrebbe correggere rispettivamente lo schema URI o le estensioni richieste.

Qui si vede bene un punto importante: una risposta SIP non chiude soltanto lo scambio, ma spesso dice anche come correggere la richiesta e riprovare. Per questo i codici di risposta contano molto.

Nella pratica, quando un nodo interpreta bene la risposta e ritenta in modo corretto, mostra di seguire davvero la logica del protocollo. Quando invece tratta ogni errore come un blocco definitivo, o lo aggira con soluzioni proprietarie, la compatibilità tra sistemi quasi sempre peggiora.

Un esempio minimo

Per fissare le idee, vediamo un esempio molto semplice e volutamente ridotto. Daniele invia una richiesta verso Matteo. In questo caso non ci interessa ancora l’intero dettaglio del metodo INVITE, ma il fatto che lo User Agent che genera la richiesta la costruisca in modo coerente e che quello che la riceve la controlli secondo le regole comuni della Sezione 8.

INVITE sip:matteo@user.voipvoice.it SIP/2.0
Via: SIP/2.0/UDP pbx.user.voipvoice.it;branch=z9hG4bK-12345
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>

Qui Daniele, come UAC, non si limita a “mandare un INVITE”. Sta costruendo una richiesta che la rete deve poter capire e trattare correttamente. Matteo, o il nodo che agirà come UAS, non dovrà limitarsi a rispondere. Dovrà prima verificare se il metodo è supportato, se la richiesta è rivolta davvero a lui, se gli header centrali sono coerenti e se il contenuto si può gestire.

In questo passaggio molti tracciati SIP vengono letti bene oppure male. Se ci fermiamo al fatto che “c’è un INVITE”, vediamo solo una superficie. Se invece ci chiediamo come il UAC lo abbia costruito e come il UAS lo stia valutando, iniziamo davvero a leggere il comportamento dello User Agent.

Conclusione

In questo capitolo abbiamo visto una cosa semplice: UAC e UAS non sono etichette ferme, ma ruoli che seguono regole precise. Nei tracciati SIP questo aiuta a capire se un nodo costruisce bene una richiesta, la controlla bene o risponde nel modo corretto.

Nel prossimo capitolo entriamo nelle sottosezioni 8.1 e 8.2, cioè nella costruzione e nel trattamento concreto delle richieste SIP.