RFC 3261: Il DNA del VoIP – Capitolo 1
L’essenza del SIP: perché tutto parte da qui

Benvenuti su VoIP.it. Quella che inizia oggi non è una semplice serie di articoli sul protocollo SIP. È un percorso ragionato dentro l’architettura della segnalazione VoIP moderna, costruito attorno alla RFC 3261, cioè il documento che da oltre vent’anni definisce il comportamento del protocollo più importante dell’intero ecosistema VoIP.

L’idea della collana è semplice da dire e molto meno semplice da realizzare bene: prendere una specifica tecnica che spesso viene consultata solo quando qualcosa non funziona, e trasformarla in una guida leggibile, progressiva e utile per chi lavora davvero sul campo. Non leggeremo la RFC come un testo notarile. La studieremo come si studia un motore, un impianto, uno schema logico: smontando le parti, osservando come lavorano insieme e cercando di capire non solo che cosa dice il protocollo, ma anche perché è stato progettato in quel modo.

In questo capitolo analizzeremo le basi concettuali del SIP partendo dalle prime sezioni della RFC 3261. Vedremo che cosa il protocollo dichiara di essere, quali problemi prova a risolvere e perché questa base è decisiva per leggere bene i capitoli successivi. È qui che il SIP smette di essere una parola ricorrente nelle interfacce dei centralini e comincia a mostrarsi come una logica di rete precisa.

Le sezioni RFC coinvolte, in questa apertura della collana, sono soprattutto la Sezione 1, la Sezione 2, la Sezione 3 e la Sezione 4. Non entreremo ancora nel dettaglio completo di header, transaction e dialog, ma costruiremo il telaio mentale necessario per interpretarli bene quando arriveranno.

Che cos’è davvero SIP

La RFC 3261 presenta SIP come un protocollo di controllo a livello applicativo, cioè di signaling, pensato per creare, modificare e terminare sessioni con uno o più partecipanti. Questo punto è decisivo. Il SIP non nasce per trasportare direttamente la voce. Nasce per governare la logica con cui una comunicazione viene proposta, gestita e chiusa.

“This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.”
“Questo documento descrive il Session Initiation Protocol (SIP), un protocollo di controllo a livello applicativo, cioè di segnalazione, per creare, modificare e terminare sessioni con uno o più partecipanti.”

Qui ci sono già i tre pilastri che reggeranno tutta la collana: application-layer, signaling e sessions. Il SIP lavora al livello applicativo. Coordina il comportamento della comunicazione. E ragiona in termini di sessione, non di semplice chiamata telefonica nel senso tradizionale.

Nel lavoro quotidiano questa distinzione fa la differenza. Quando in un tracciato PCAP vediamo un INVITE, un 100 Trying, un 180 Ringing, un 200 OK e un ACK, stiamo leggendo il piano di segnalazione. Quando invece osserviamo perdita pacchetti, jitter, delay o codec RTP, siamo già su un altro piano. È proprio in questo passaggio che molti tracciati iniziano a essere letti male.

Il problema che il SIP prova a risolvere

La parte iniziale della RFC 3261 nasce da un problema molto concreto: gli utenti non sono statici. Possono spostarsi tra endpoint diversi, essere raggiungibili con più identità, usare media differenti e comparire in rete con posizioni variabili. Il protocollo deve quindi consentire alla comunicazione di nascere in un contesto distribuito e dinamico.

Detto così può sembrare un dettaglio. In realtà non lo è. Nel mondo IP un utente può essere registrato su un telefono da scrivania, su un softphone, su un client mobile o dietro un centralino IP che termina e riapre la segnalazione. Da qui nasce la necessità di funzioni come localizzazione, registrazione, instradamento e decisione di rete.

Nel testo RFC questa esigenza si traduce in una visione molto moderna: l’identità dell’utente resta stabile, mentre la sua raggiungibilità può cambiare nel tempo. È il motivo per cui nella pratica incontriamo componenti come proxy, registrar, location service e meccanismi di inoltro che torneranno spesso nei capitoli successivi.

SIP non è il media

Uno dei malintesi più diffusi, soprattutto nelle prime fasi di studio del VoIP, è pensare che il SIP “trasporti la voce”. Non è così. La voce, nella maggior parte degli scenari reali, viaggia su RTP. Il SIP costruisce il contesto di controllo: stabilisce chi sta tentando di comunicare con chi, quali parametri di sessione vengono proposti e quale esito produce la negoziazione.

Questo punto nella pratica è essenziale anche per il troubleshooting. Una chiamata può essere perfetta dal punto di vista SIP e completamente sbagliata dal punto di vista media. Possiamo avere un flusso di segnalazione formalmente corretto, con setup completato, e tuttavia osservare audio monodirezionale o assenza totale di audio. In Wireshark conviene quindi separare sempre il controllo della sessione dalla verifica del traffico RTP.

SIP non offre servizi finiti: offre primitive

La RFC 3261 chiarisce un aspetto che spesso viene sottovalutato ma che ha un valore architetturale enorme: il SIP non fornisce servizi finiti nel senso in cui li immagina un utente finale. Fornisce meccanismi di base, cioè primitive, con cui servizi diversi possono essere costruiti.

“SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services.”
“SIP non fornisce servizi. Piuttosto, SIP fornisce primitive che possono essere usate per implementare servizi differenti.”

Questo è il punto da fissare bene. Il protocollo mette a disposizione funzioni come localizzare un utente, inoltrare una richiesta, trasportare una descrizione di sessione, negoziare parametri, autenticare soggetti e terminare una sessione. Con queste primitive si possono costruire chiamate punto-punto, instradamenti complessi, trasferimenti, servizi follow-me, deviazioni, logiche PBX e comportamenti introdotti da RFC successive.

Sul campo questo modo di ragionare è molto utile. Quando qualcosa non funziona, conviene chiedersi quale primitiva si è spezzata davvero. Il problema è di raggiungibilità? Di autenticazione? Di negoziazione SDP? Di routing? Di gestione dello stato? Questa lettura è molto più efficace di una diagnosi generica del tipo “la chiamata non parte”.

I cinque aspetti fondamentali della comunicazione SIP

Nella Sezione 2 la RFC 3261 sintetizza il ruolo del SIP attraverso cinque aspetti fondamentali. È una parte didatticamente molto forte, perché condensa la logica del protocollo in un modello operativo leggibile.

User location

Il sistema deve capire dove si trova il destinatario. Una URI come sip:matteo@user.voipvoice.it è un’identità logica, non necessariamente una destinazione IP immediata. La rete deve risolverla verso una o più destinazioni reali.

User availability

Raggiungibilità non significa disponibilità. Il destinatario può essere occupato, non disponibile, irraggiungibile oppure può rifiutare la sessione. Il protocollo deve consentire anche questa lettura dello stato.

User capabilities

Anche quando il destinatario è raggiungibile e disponibile, resta da capire se i due lati siano compatibili. Codec, media supportati, porte, parametri SDP e modalità operative devono poter essere negoziati in modo coerente.

Session setup

La sessione deve essere impostata in maniera ordinata. Qui entrano in gioco richiesta iniziale, risposte provvisorie, risposta finale e conferma. Nei capitoli successivi vedremo come questa meccanica emerga nel call flow SIP.

Session management

Una volta nata, la sessione deve poter essere modificata, aggiornata o terminata. Il SIP, infatti, non governa soltanto l’avvio della comunicazione ma il suo intero ciclo di vita sul piano di signaling.

Nel tracciato SIP questi cinque aspetti non compaiono come etichette teoriche, ma come effetti concreti: lookup, risposte di stato, body SDP, conferme di setup, richieste di modifica e messaggi di chiusura.

Una prima lettura del flusso SIP

La Sezione 4 introduce il funzionamento del protocollo con un esempio ormai classico: il chiamante invia un INVITE, la richiesta attraversa eventuali proxy, il destinatario viene raggiunto, produce risposte provvisorie e poi una risposta finale. È qui che il SIP smette di apparire come definizione e comincia a mostrarsi come una sequenza leggibile di eventi.

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>
Content-Type: application/sdp

Questo messaggio non trasporta ancora una conversazione. Trasporta una proposta di sessione. È una differenza enorme. Il protocollo non crea magicamente una chiamata: avvia una negoziazione strutturata che coinvolge identità, routing, stato e parametri di sessione.

Nel tracciato SIP questo punto si vede bene quando alle richieste iniziali seguono risposte come 100 Trying, 180 Ringing e 200 OK. Ogni messaggio racconta una fase specifica della progressione. Un errore frequente consiste nel leggere tutto come un’unica massa indistinta di pacchetti, perdendo invece il significato progressivo di ogni risposta.

Importanza della parte introduttiva

Le sezioni iniziali della RFC 3261 vengono spesso liquidate come “parte introduttiva”. In realtà qui si gioca una parte importante di tutto il comportamento SIP. Se il tecnico interiorizza subito che il protocollo è signaling applicativo, che lavora per sessioni, che non coincide con il media e che offre primitive riutilizzabili, allora i capitoli successivi acquisiscono un senso diverso..

Al contrario, quando questa base manca, iniziano gli errori classici: si confonde il piano SIP con il piano RTP, si attribuiscono al protocollo funzioni che non ha, si interpreta male il ruolo dei nodi di rete e si leggono i tracciati senza avere le basi per fare alcuna ipotesi.

Conclusione

In questo primo capitolo abbiamo costruito la base logica della nostra collana di articoli. Abbiamo visto che cosa la RFC 3261 dichiara di essere, perché il SIP nasce come protocollo di signaling, quali problemi prova a risolvere e perché non va confuso con il piano media. Abbiamo anche chiarito che il protocollo mette a disposizione primitive e non servizi finiti, e che il suo valore si comprende davvero solo quando si osserva il comportamento reale della rete.

A questo punto possiamo fare un passo in avanti. Nel prossimo capitolo vedremo come il SIP opera davvero quando entra in funzione, cioè come la teoria iniziale si traduce in richieste, risposte e progressione della sessione dentro il flusso della chiamata SIP.