RFC 3261: Il DNA del VoIP – Capitolo 3
La terminologia SIP: il vocabolario del protocollo

Nel capitolo precedente abbiamo osservato il SIP mentre entra in funzione. Abbiamo visto richieste, risposte, progressione della sessione e chiusura ordinata. In altre parole, abbiamo visto il protocollo muoversi. Adesso però dobbiamo fermarci un momento e fare un passaggio fondamentale: capire chi compie le azioni che abbiamo appena osservato.

È qui che entra in gioco la Sezione 6 della RFC 3261. A prima vista può sembrare un semplice glossario. In realtà è molto di più. È il lessico operativo con cui il protocollo descrive i propri attori, i propri ruoli e le proprie responsabilità. Senza questa base, un tracciato SIP resta una sequenza di messaggi. Con questa base, ogni messaggio inizia invece ad avere un posto preciso dentro la logica della rete.

In questo capitolo vedremo proprio questo: perché la terminologia della RFC non coincide con il linguaggio quotidiano dell’infrastruttura, perché il SIP ragiona in termini di entità logiche e non di apparati, e perché questa differenza cambia radicalmente il modo in cui leggiamo un flusso in Wireshark.

Perché la terminologia SIP conta davvero

Nella pratica quotidiana si tende a descrivere il VoIP con il linguaggio dell’hardware e dei prodotti. Si dice: il telefono ha mandato un INVITE, il centralino ha risposto, il provider ha rifiutato la chiamata, il trunk ha mandato un errore. È un linguaggio comprensibile e spesso comodo. Ma non è il linguaggio con cui la RFC descrive il protocollo.

La RFC 3261 adotta un approccio molto più rigoroso. Non parte dal tipo di apparato. Parte dal comportamento. Questa scelta è fondamentale, perché lo stesso dispositivo può assumere ruoli diversi in momenti diversi della stessa comunicazione. Un terminale può generare una richiesta e poco dopo riceverne un’altra. Un nodo intermedio può ricevere un messaggio come server e inoltrarlo comportandosi come client. Un PBX può fare semplice transito in uno scenario e terminare realmente la segnalazione in un altro.

È qui che il vocabolario della RFC diventa prezioso. Se usiamo parole troppo generiche, perdiamo precisione. E quando perdiamo precisione, perdiamo anche capacità diagnostica. La terminologia SIP non è quindi teoria ornamentale. È uno strumento di lettura operativa.

Il SIP ragiona per entità logiche

La prima grande idea della Sezione 6 è proprio questa: il protocollo non descrive la rete con etichette commerciali o fisiche, ma attraverso entità logiche. Questa scelta impedisce di confondere il contenitore con la funzione.

In altre parole, alla RFC non interessa se un messaggio stia passando in un telefono da scrivania, in un softphone, in un SBC, in un PBX o in una piattaforma cloud. Interessa capire quale ruolo quella componente stia assumendo in quel preciso passaggio della comunicazione.

Nel tracciato SIP questa differenza si vede benissimo. Ci sono casi in cui due nodi che, a prima vista, sembrano simili si comportano in modo completamente diverso sul piano protocollare. E ci sono casi in cui lo stesso apparato cambia ruolo durante la stessa chiamata. Se questa distinzione non è chiara, si leggono male i messaggi e si attribuiscono responsabilità al nodo sbagliato.

È proprio per questo che il linguaggio della RFC aiuta così tanto: non semplifica artificialmente la realtà, ma la rende leggibile.

User Agent: il punto in cui il SIP nasce o termina

Uno dei termini più importanti della Sezione 6 è User Agent. La RFC lo definisce come un’entità logica che può agire sia come User Agent Client sia come User Agent Server.

“A user agent is a logical entity that can act as both a user agent client and user agent server.”
“Uno User Agent è un’entità logica che può agire sia come user agent client sia come user agent server.”

La parola decisiva, ancora una volta, è logical entity. La RFC non dice che lo User Agent è un telefono. Non dice che è un softphone. Non dice che coincide per forza con il terminale dell’utente finale. Dice che è un’entità logica. Questo significa che lo User Agent è definito dal ruolo che svolge nel protocollo, non dal contenitore in cui gira.

Nella pratica, uno User Agent può coincidere con un telefono IP, con un client software, con un terminale mobile, con un centralino che termina realmente la segnalazione oppure con una piattaforma di servizio che si comporta come endpoint SIP. Il nome commerciale dell’apparato conta meno della funzione che svolge.

È utile fissare una regola molto semplice: lo User Agent è il punto in cui il SIP viene originato o consumato come logica di segnalazione. Quando un nodo riceve una richiesta, la elabora come destinatario della segnalazione e produce una risposta, non sta solo trasportando traffico. Sta agendo come User Agent.

Perché uno User Agent non coincide sempre con un telefono

Questo è uno dei malintesi più comuni nelle prime fasi di studio. Si tende a immaginare lo User Agent come sinonimo di terminale utente. È una scorciatoia utile all’inizio, ma che molto presto diventa fuorviante.

In molti scenari reali, infatti, un centralino IP, un application server o una piattaforma di servizio si comportano come veri endpoint della segnalazione, pur non essendo il dispositivo da cui l’utente sta materialmente parlando. Nei tracciati SIP questo si riconosce bene: il nodo non si limita a inoltrare, ma termina una richiesta e genera una nuova logica di comunicazione.

Questo cambia molto la qualità della lettura. Se una piattaforma termina una sessione da un lato e ne apre un’altra dall’altro, non sta facendo puro transito. Sta partecipando alla logica del protocollo. Ed è proprio qui che la distinzione tra apparato fisico e ruolo logico diventa indispensabile.

UAC e UAS: ruoli che cambiano durante il flusso

All’interno dello User Agent, la RFC distingue due ruoli centrali: User Agent Client e User Agent Server. Il primo genera una richiesta. Il secondo la riceve e produce una risposta. Detta così sembra semplice, quasi ovvia. Ma è uno dei punti in cui più spesso si sbaglia a leggere il SIP.

L’errore classico consiste nel pensare che il chiamante sia sempre client e il chiamato sia sempre server. La RFC ci dice invece una cosa più precisa: UAC e UAS non sono identità permanenti dei dispositivi. Sono ruoli assunti nel momento in cui viene generata o ricevuta una specifica richiesta.

Prendiamo un esempio molto semplice. Daniele invia un INVITE a Matteo. In quel momento Daniele è UAC, perché genera la richiesta, e Matteo è UAS, perché la riceve e risponde. Ma se più avanti Matteo decide di chiudere la sessione inviando un BYE, i ruoli si invertono: Matteo diventa UAC di quella nuova richiesta, e Daniele diventa UAS della relativa risposta.

Questo è il punto da fissare bene: UAC e UAS sono ruoli del flusso, non etichette permanenti del nodo. Quando questa distinzione non è chiara, si leggono male soprattutto i passaggi successivi al setup iniziale.

Perché UAC e UAS sono decisivi nel troubleshooting

Nel troubleshooting questa distinzione pesa moltissimo. Sul campo si sentono spesso frasi come “il chiamato ha chiuso la chiamata” oppure “il client non ha risposto bene”. In SIP, senza contesto, sono formule troppo vaghe.

Se Matteo invia un BYE, in quel momento non è più soltanto “il chiamato”. È il client di quella nuova richiesta. Se Daniele risponde con 200 OK, in quel momento sta agendo come server di quello specifico scambio. Questo cambia il modo in cui localizziamo il problema. Non dobbiamo guardare solo chi ha iniziato la chiamata in senso narrativo. Dobbiamo guardare chi ha originato quel messaggio e chi aveva il compito di rispondere.

Nel tracciato SIP questo approccio cambia tutto. Si smette di ragionare in termini generici di chiamante e chiamato e si comincia a ragionare in termini di richiesta, risposta e responsabilità operative. È proprio qui che il vocabolario corretto evita molti errori di diagnosi.

Il proxy: il punto in cui la rete prende decisioni

Un altro concetto centrale della Sezione 6 è il proxy. La RFC lo definisce come un’entità intermedia che agisce sia come server sia come client allo scopo di effettuare richieste per conto di altri client.

“A proxy is an intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients.”
“Un proxy è un’entità intermedia che agisce sia come server sia come client allo scopo di effettuare richieste per conto di altri client.”

La cosa essenziale da capire è che il proxy non è il terminale finale della comunicazione. È un nodo intermedio della rete SIP. Riceve una richiesta da un lato e la inoltra dall’altro, ma non si limita a fare da tubo passivo. Interpreta il messaggio e applica una logica di rete.

È proprio qui che il proxy acquista valore architetturale. Può consultare un servizio di localizzazione, applicare policy, decidere una destinazione, scegliere un percorso di inoltro e in generale governare una parte importante del comportamento reale della chiamata SIP. Quando questo passaggio viene capito, il proxy smette di sembrare un relay generico e diventa ciò che è davvero: un punto di decisione.

Perché il proxy non è un semplice relay

Chi proviene da un’idea troppo lineare della rete tende a vedere il proxy come un semplice elemento di passaggio. In SIP non è così. Un relay puro trasporta traffico. Un proxy SIP, invece, interpreta la richiesta e prende decisioni di instradamento.

Da qui derivano molte situazioni reali. Una chiamata può essere accettata da un nodo e rifiutata più avanti, può essere inoltrata verso una destinazione alternativa, può essere gestita con logiche di ricerca multiple oppure bloccata da una policy. Quando questo accade, il problema non è semplicemente tra il telefono di Daniele e quello di Matteo. Il problema è in uno dei nodi logici della rete.

Nel tracciato SIP il sintomo tipico, in questi casi, è che la progressione non segue l’idea intuitiva che il lettore si era costruito. Si vedono risposte intermedie, percorsi diversi, decisioni apparentemente strane ma perfettamente coerenti con il ruolo del proxy. Se questo ruolo non viene riconosciuto, si attribuiscono facilmente al terminale finale problemi che nascono molto prima.

Registrar: la memoria della raggiungibilità

La Sezione 6 introduce anche il concetto di registrar, cioè il server che accetta richieste REGISTER e inserisce le informazioni ricevute nel servizio di localizzazione del dominio. In questo capitolo non entriamo ancora nel dettaglio operativo del metodo REGISTER, ma è importante fissare subito il significato logico del registrar.

Il registrar è il componente che consente alla rete SIP di mantenere il legame tra un’identità logica e una posizione attuale. Se Simone è raggiungibile come sip:simone@user.voipvoice.it, la rete deve sapere dove inviare davvero le richieste dirette a quell’identità in quel momento. Il registrar serve esattamente a questo.

Qui compare uno dei concetti più importanti di tutto il SIP: la separazione tra identità logica e posizione corrente. È una distinzione che spiega benissimo perché il protocollo sia adatto a un mondo in cui gli utenti cambiano terminale, si spostano tra reti diverse e mantengono comunque una raggiungibilità coerente.

Nel lavoro quotidiano molti problemi VoIP nascono proprio qui: registrazioni mancanti, scadute, duplicate o incoerenti. Anche se il capitolo dedicato a REGISTER arriverà più avanti, il ruolo del registrar va capito fin da subito.

Redirect server: quando la rete indica la strada ma non inoltra

Un altro termine importante della Sezione 6 è il redirect server. A differenza del proxy, il redirect server non inoltra direttamente la richiesta. Risponde invece indicando al mittente, o al nodo che lo ha interrogato, quale nuova destinazione debba essere contattata.

Detto in modo semplice, il proxy prende in mano la richiesta e la porta avanti. Il redirect server, invece, indica una nuova strada e lascia che sia il client a ripartire verso quella destinazione. È una differenza architetturale molto importante, perché cambia sia il comportamento della rete sia il modo in cui leggiamo il tracciato.

Nel flusso SIP il sintomo tipico è che non vediamo il nodo intermedio accompagnare la richiesta fino in fondo. Vediamo piuttosto una risposta che restituisce nuove informazioni di destinazione, dopo di che sarà il client a costruire la richiesta successiva. Se questo meccanismo non viene distinto da quello del proxy, la logica del flusso viene facilmente fraintesa.

Stateful e stateless: quando la rete ricorda e quando no

La Sezione 6 introduce anche la distinzione tra stateful proxy e stateless proxy. Il tema verrà approfondito meglio più avanti, quando entreremo nel comportamento delle transazioni e dei proxy. Però è utile fissarlo già qui, perché fa parte integrante del vocabolario del protocollo.

Un proxy stateless inoltra il messaggio senza mantenere memoria dello scambio. È più semplice e più leggero. Un proxy stateful, invece, mantiene informazioni sulla richiesta e sulle risposte collegate. Questo gli permette di correlare meglio i messaggi e di partecipare in modo più attivo alla logica dello scambio SIP.

Detto così può sembrare un dettaglio teorico. In realtà, nei sistemi reali, cambia moltissimo. Un nodo che non mantiene stato non può reagire come uno che lo mantiene. Nel troubleshooting questa differenza incide direttamente sui sintomi osservabili nel tracciato: ritrasmissioni, correlazioni, gestione degli errori e comportamento generale del flusso.

Come cambia la lettura dei tracciati SIP

Arrivati qui, il punto più importante dovrebbe essere chiaro. Quando guardiamo un tracciato SIP senza il vocabolario della RFC, vediamo solo righe di testo: INVITE, 100 Trying, 180 Ringing, 200 OK, BYE. Possiamo intuire una sequenza, ma leggiamo male le responsabilità dei nodi.

Quando invece interiorizziamo concetti come User Agent, UAC, UAS, proxy, registrar, redirect server e distinzione tra stateful e stateless, il tracciato cambia faccia. Non vediamo più solo messaggi. Vediamo chi ha originato la richiesta, chi stava agendo da server in quel passaggio, chi stava inoltrando, chi stava decidendo il percorso e chi stava mantenendo stato.

È qui che il SIP inizia a essere leggibile in modo professionale. Ed è qui che il tecnico smette di descrivere i problemi con formule vaghe e inizia a formulare diagnosi molto più precise. Quando il linguaggio diventa corretto, migliora anche la capacità di analisi.

Non etichette, ma responsabilità

Se dovessimo riassumere questo capitolo in una frase sola, potremmo dire così: la terminologia della RFC 3261 non serve a dare nomi eleganti ai nodi della rete. Serve a distribuire correttamente le responsabilità dentro il protocollo.

Ed è proprio questo che, nella pratica quotidiana, cambia tutto. Un tracciato SIP non va letto come la storia di due telefoni che si parlano. Va letto come un insieme di ruoli logici che, richiesta dopo richiesta, assumono comportamenti precisi. È un cambio di prospettiva che all’inizio richiede un piccolo sforzo, ma che poi rende molto più chiaro sia il comportamento reale della rete sia l’origine dei problemi.

Questo è anche il motivo per cui la Sezione 6 è molto più importante di quanto sembri. Non è una pausa teorica tra un capitolo operativo e un altro. È il capitolo che costruisce il lessico con cui potremo leggere bene tutto ciò che verrà dopo.

Conclusione

In questo capitolo abbiamo costruito il vocabolario di base del SIP. Abbiamo visto perché la RFC ragiona in termini di entità logiche e non di apparati, perché uno User Agent non coincide automaticamente con un telefono, perché UAC e UAS sono ruoli del flusso e non etichette permanenti, e perché nodi come proxy, registrar e redirect server cambiano profondamente il comportamento della chiamata SIP.

A questo punto la progressione della collana può entrare in una fase ancora più concreta. Nel prossimo capitolo vedremo il comportamento degli User Agent nella Sezione 8, cioè il punto in cui il lessico appena costruito diventa comportamento operativo della segnalazione.