RFC 3261: Il DNA del VoIP – Capitolo 8
ACK, conferma finale della sessione

Nei capitoli precedenti abbiamo visto come una sessione SIP prenda forma attraverso una sequenza ordinata di messaggi. Abbiamo osservato la richiesta iniziale, le risposte provvisorie, il momento in cui arriva il 200 OK e la logica generale con cui il protocollo porta due estremi a riconoscersi e a mettersi d’accordo. A questo punto entriamo in un passaggio che, nei tracciati reali, viene spesso sottovalutato ma che nella RFC 3261 ha un ruolo preciso: l’ACK.

Il tema di questo capitolo è la Sezione 13.2.2.4 della RFC 3261, cioè la gestione delle risposte 2xx all’INVITE. Più precisamente, il punto in cui il protocollo richiede che il chiamante invii un ACK per confermare la ricezione della risposta finale positiva.

Questo passaggio, letto in superficie, sembra quasi banale. Si potrebbe pensare che l’ACK sia solo una formalità dopo il 200 OK. In realtà non è così. Nel SIP l’ACK è la conferma finale che chiude correttamente la fase di instaurazione della sessione. Finché non arriva, il dialogo non è passato in modo pulito dalla proposta di sessione alla sessione effettivamente confermata.

Perché l’ACK merita un capitolo a parte

Molti tecnici, soprattutto nelle prime fasi di studio del protocollo, associano la riuscita della chiamata all’arrivo del 200 OK. È comprensibile, perché quel messaggio indica che l’altra parte ha accettato la sessione. Però la RFC è più precisa. L’accettazione da parte del chiamato non basta da sola a chiudere correttamente l’instaurazione della sessione. Serve anche che il chiamante confermi di aver ricevuto quella risposta finale positiva.

Questa conferma è proprio l’ACK.

Detto in modo molto diretto: il 200 OK dice ho accettato la sessione. L’ACK dice ho ricevuto la tua accettazione. È questo scambio a chiudere in modo completo il setup SIP.

Il punto della RFC: 2xx all’INVITE

La Sezione 13.2.2.4 si concentra sulla gestione delle risposte finali positive all’INVITE. Qui la RFC distingue il comportamento delle risposte 2xx da quello delle risposte negative finali. È una distinzione fondamentale, perché nel SIP l’ACK non si comporta sempre nello stesso modo in tutti i casi.

Nel caso che stiamo studiando qui, cioè quando arriva un 200 OK a un INVITE, il chiamante deve generare un ACK. Non è opzionale. Non è una scelta del vendor. È parte del comportamento corretto del protocollo.

Questa è la definizione generale del metodo ACK. Prima ancora delle regole operative, la RFC chiarisce la sua funzione: l’ACK serve a confermare la ricezione della risposta finale all’INVITE.

<blockquote><em>”The ACK request confirms receipt of a final response to an INVITE request.”</em><br><strong>”La richiesta ACK conferma la ricezione di una risposta finale a una richiesta INVITE.”</strong></blockquote>

“The UAC core MUST generate an ACK request for each 2xx received from the transaction layer.”
“Il core UAC deve generare una richiesta ACK per ogni risposta 2xx ricevuta dal transaction layer.”

Questa è la frase centrale della sezione 13.2.2.4. La RFC non lascia spazio a interpretazioni elastiche: dopo una risposta finale positiva all’INVITE, l’ACK non è facoltativo.

Questa precisazione è molto importante anche per il troubleshooting. In un tracciato pcap, vedere il 200 OK senza vedere l’ACK significa che la sessione non si è chiusa correttamente sul piano della segnalazione, anche se a prima vista potrebbe sembrare quasi completata.

Un esempio minimo di chiusura corretta del setup

Il flusso essenziale è questo:

INVITE sip:matteo@voip.it SIP/2.0
...
SIP/2.0 200 OK
...
ACK sip:matteo@voip.it SIP/2.0

Queste tre righe, lette così, sembrano semplici. Ma dentro c’è tutta la logica della chiusura corretta dell’instaurazione della sessione:

1. il chiamante propone la sessione con l’INVITE;
2. il chiamato la accetta con il 200 OK;
3. il chiamante conferma di aver ricevuto quella risposta con l’ACK.

Solo a questo punto la fase di setup può dirsi chiusa in modo corretto.

L’ACK non è una risposta

Questo è uno dei punti che conviene fissare bene. L’ACK non è una risposta al 200 OK nel senso generico con cui si usa la parola risposta. Dal punto di vista SIP, l’ACK è una nuova richiesta.

La differenza non è formale. Ha un significato preciso nel modo in cui il protocollo ragiona. L’INVITE è una richiesta. Il 200 OK è una risposta finale positiva. L’ACK è una nuova richiesta che esiste proprio per completare quella fase del dialogo.

Questo si vede molto bene quando si analizzano i pcap. L’ACK ha una Request-Line propria, ha una destinazione, ha header coerenti con il dialogo già creato. Non è un’eco del 200 OK. È un messaggio autonomo, con una funzione specifica.

Che cosa conferma davvero l’ACK

L’ACK non conferma che il telefono sta già parlando. Non conferma la qualità audio. Non conferma che il percorso RTP sia corretto. Conferma una cosa molto precisa: la ricezione della risposta finale positiva all’INVITE.

Questo è il punto tecnico corretto da tenere a mente. L’ACK chiude la negoziazione di segnalazione che porta all’apertura della sessione. Il media può partire a quel punto, ma il compito dell’ACK non è certificare il media. Il suo compito è chiudere correttamente il setup SIP.

Questa distinzione è utile anche in campo. Una chiamata può avere un flusso INVITE / 200 OK / ACK perfetto e poi soffrire di audio monodirezionale o assente. In quel caso la segnalazione è corretta, ma il problema sta altrove, di solito nel piano RTP o nei dati SDP negoziati.

Perché senza ACK il setup resta incompleto

Quando il chiamato invia un 200 OK, sta dichiarando di accettare la sessione. Però non può sapere con certezza che quel messaggio sia stato ricevuto correttamente dal chiamante finché non arriva l’ACK.

Ecco perché l’ACK è indispensabile. Senza questa conferma, il lato chiamato resta in una situazione non chiusa del tutto. Dal suo punto di vista la sessione è stata accettata, ma manca la prova che l’altro lato abbia ricevuto quell’accettazione.

Nei sistemi reali questo si traduce in comportamenti molto riconoscibili. Il terminale o il PBX che ha inviato il 200 OK può ritrasmetterlo più volte, proprio perché non ha ancora ricevuto l’ACK. Dal punto di vista del tracciato, questo è uno dei segnali più chiari di un problema nella chiusura della fase di instaurazione.

Il caso pratico più comune: il 200 OK c’è, ma l’ACK non arriva

Questa è una delle situazioni più frequenti nei pcap reali. Si vede l’INVITE, si vede il percorso corretto delle risposte provvisorie, si vede il 200 OK, ma poi manca l’ACK. Oppure l’ACK viene generato ma non raggiunge la destinazione giusta.

Quando succede, i sintomi operativi possono essere molto vari:

• la chiamata sembra rispondere e poi cade dopo pochi secondi;
• il chiamato continua a ritrasmettere il 200 OK;
• uno dei due lati considera la sessione aperta, mentre l’altro non la considera ancora chiusa correttamente;
• l’utente percepisce una risposta anomala o una chiamata che non si stabilizza.

In questi casi, attribuire il problema genericamente al provider o al centralino porta spesso fuori strada. Il punto vero è verificare dove si interrompe il percorso dell’ACK e perché.

Dove nasce spesso il problema

Nella pratica il mancato arrivo dell’ACK dipende spesso da problemi di indirizzamento o di instradamento del messaggio finale. È qui che il protocollo, letto bene, diventa molto concreto.

Le cause tipiche sono queste:

• Contact errato o non raggiungibile, che porta l’ACK verso una destinazione sbagliata.
• Riscritture SIP incoerenti lungo il percorso.
• Record-Route o route set non coerenti, se la chiamata doveva restare in dialogo attraverso nodi intermedi.
• Interoperabilità imperfetta tra apparati che costruiscono male il messaggio o ne interpretano in modo errato la destinazione.

Firewall, layer 7 e SIP ALG/helper

Su questo punto conviene soffermarsi bene, perché è uno dei casi più frequenti e più sottovalutati nelle installazioni reali. Quando in mezzo al traffico SIP c’è un firewall next generation con ispezione a livello applicativo, il problema non è solo aprire o chiudere una porta. Quel dispositivo può leggere la segnalazione SIP, applicare controlli di conformità, aprire pinhole dinamici per i flussi attesi, riscrivere indirizzi contenuti nei messaggi oppure interferire con il modo in cui il dialogo viene mantenuto. È esattamente qui che un flusso apparentemente corretto può interrompersi nel passaggio finale che porta al ACK. La documentazione tecnica di Palo Alto Networks, Fortinet, Cisco e MikroTik descrivono proprio questo tipo di comportamento.

Qui però va fatta una distinzione importante. Dire che il firewall può ispezionare SIP, aprire pinhole dinamici, fare NAT degli indirizzi presenti nei messaggi e, in alcuni scenari, interferire con la segnalazione invece di aiutarla, significa una cosa molto concreta: in scenari legacy o limite, il SIP ALG o il SIP helper può anche risultare utile. Può succedere, per esempio, quando si ha a che fare con apparati datati, terminali poco flessibili o ambienti in cui il traversal SIP è gestito male a monte. In questi casi il dispositivo intermedio prova a compensare, leggendo e modificando la segnalazione per facilitare l’attraversamento di NAT e firewall.

Nella maggior parte delle installazioni moderne, però, accade il contrario. Proprio perché entra nel contenuto applicativo del messaggio SIP, l’ALG/helper finisce spesso per interferire più che aiutare. Può riscrivere indirizzi che non dovrebbe toccare, interpretare male il Contact, alterare il percorso del dialogo, aprire pinhole non coerenti con la logica reale della sessione oppure impedire la consegna corretta dell’ACK. Il risultato è il classico scenario in cui l’INVITE passa, il 200 OK torna indietro, ma la chiamata poi non si stabilizza correttamente.

Il caso più insidioso è proprio questo: il dispositivo di sicurezza lascia passare l’INVITE, lascia tornare il 200 OK, ma poi manipola il contenuto del dialogo, interpreta male la destinazione del messaggio successivo o non mantiene in modo coerente la logica di attraversamento del traffico. In quel momento l’ACK può essere inviato verso un indirizzo errato, bloccato, non tradotto correttamente o semplicemente non consegnato al nodo che ha generato il 200 OK. Per l’utente il risultato è spesso una chiamata che sembra rispondere e poi cade. Per il tecnico, invece, il segnale chiaro è la ritrasmissione del 200 OK senza la conferma finale attesa.

Dentro questo quadro rientra anche il tema del SIP ALG. In teoria nasce per aiutare il traffico SIP che attraversa NAT e firewall, aprendo pinhole dinamici e riscrivendo gli indirizzi presenti nei messaggi. In pratica, però, proprio perché entra dentro la segnalazione e la modifica, può diventare una fonte di problemi di interoperabilità. La documentazione dei vendor lo dice in modo molto chiaro: in alcuni ambienti VoIP moderni il SIP ALG va valutato con grande attenzione e, in certi scenari, può essere opportuno disabilitarlo per evitare che interferisca con sessioni che hanno già una propria intelligenza NAT o una propria logica di attraversamento.

La regola pratica che mi sento di consigliare oggi è questa: su PBX moderni, centrali VoIP attuali e soprattutto su infrastrutture provider che lavorano con SBC evoluti e logiche di helper lato centrale, conviene in linea di massima intervenire disattivando gli ALG/helper SIP sui dispositivi intermedi. In questi ambienti il traversal, le riscritture corrette e il controllo del dialogo vengono già gestiti in modo più affidabile dagli elementi SIP progettati per farlo. Lasciare attivo anche un ALG nel firewall significa spesso introdurre una seconda intelligenza sullo stesso flusso, e due intelligenze che riscrivono SIP raramente migliorano la stabilità della chiamata.

Tradotto in chiave operativa: quando l’ACK manca, non basta controllare se la porta SIP è aperta. Bisogna chiedersi se qualche dispositivo intermedio stia facendo ispezione layer 7, riscrittura applicativa, gestione dinamica dei pinhole o funzioni SIP ALG/helper che alterano il comportamento atteso del dialogo. Qui si vede molto bene perché l’ACK non è solo un concetto teorico. È un punto reale di possibile interruzione del flusso e di guasto per molte installazioni SIP.

ACK e dialogo SIP

L’ACK arriva in un punto molto delicato del protocollo, perché il 200 OK all’INVITE contribuisce alla costruzione del dialogo. In pratica, quando leggiamo questo passaggio in continuità con la logica della RFC, vediamo che il SIP sta chiudendo il setup e allo stesso tempo sta fissando la relazione logica tra i due user agent.

Per questo l’ACK non è mai un dettaglio marginale. È uno dei messaggi che rendono coerente il passaggio da una proposta di sessione a una sessione davvero stabilita sul piano della segnalazione.

Dal punto di vista didattico, è utile pensarla così: il 200 OK apre la porta dal lato del chiamato, ma l’ACK è il gesto finale con cui il chiamante attraversa quella porta in modo esplicito e protocollo-compatibile.

Perché la RFC separa bene questo caso

La RFC dedica una sottosezione specifica a questo comportamento perché il trattamento delle risposte 2xx all’INVITE non è un dettaglio secondario. Ha implicazioni dirette sulla stabilità del dialogo, sulla chiusura del setup e sulla capacità dei due estremi di condividere lo stesso stato della comunicazione.

Questo è uno dei casi in cui il protocollo mostra bene la propria maturità: non si limita a dire che una sessione è stata accettata. Definisce anche come quella accettazione debba essere confermata dall’altro lato. È una forma di disciplina del dialogo, e senza questa disciplina molti scenari reali diventerebbero fragili o ambigui.

Approfondimenti finali dalla RFC

Prima di chiudere il capitolo, aggiungo alcuni dettagli tecnici della RFC 3261 che non cambiano il concetto principale, ma lo completano bene. Li lascio qui come approfondimenti finali, in modo che l’articolo possa mantenere una doppia funzione: una più lineare e operativa nella parte principale, e una seconda più tecnica e accademica per chi non vuole perdere nemmeno un dettaglio. Li dispongo anche in ordine cronologico, seguendo ciò che può accadere dopo la ricezione della prima 2xx.

1. Più risposte 2xx: il caso del forking

Un primo dettaglio importante è che a un singolo INVITE possono arrivare anche più risposte finali positive. Questo accade, per esempio, in scenari di forking, quando la richiesta è stata inoltrata verso più destinazioni contemporaneamente e più di un ramo risponde con una 2xx.

Qui la RFC è molto chiara: ogni risposta 2xx crea un dialogo distinto, identificato anche dal tag nel campo To. Questo significa che il UAC deve generare un ACK per ogni risposta 2xx ricevuta. È un dettaglio tecnico, ma molto importante, perché mostra che l’ACK non è solo la chiusura di un flusso elementare uno-a-uno. Questo non significa mantenere attivi tutti i rami: significa confermare correttamente ogni dialogo accettato e poi chiudere con BYE quelli che non si intende proseguire.

2. Dialogo confermato e route set ricalcolato

Quando arriva una risposta 2xx, la RFC prevede anche che il dialogo passi allo stato confirmed. Non è solo una sfumatura teorica. Significa che il rapporto logico tra i due user agent entra in una fase stabile e che il route set del dialogo va ricalcolato sulla base delle informazioni presenti nella risposta.

Questo dettaglio rafforza una cosa già emersa nel capitolo: il 200 OK non rappresenta solo un sì alla sessione, ma contribuisce a fissare in modo corretto il percorso logico dei messaggi successivi. L’ACK, quindi, si inserisce in un dialogo che in quel momento non è solo accettato, ma anche strutturato in modo più completo.

3. Come si costruisce davvero l’ACK

Un altro punto interessante è che l’ACK non è una richiesta costruita in modo arbitrario. La RFC specifica che va generato come una richiesta interna al dialogo, ma con alcune regole molto precise.

“The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE.”
“Il numero di sequenza del campo CSeq deve essere lo stesso dell’INVITE che si sta confermando, ma il metodo nel CSeq deve essere ACK. Inoltre, l’ACK deve contenere le stesse credenziali dell’INVITE.”

La più importante è questa: il campo CSeq dell’ACK deve usare lo stesso numero dell’INVITE che si sta confermando, ma con metodo ACK. Inoltre, la RFC richiede che l’ACK porti le stesse credenziali dell’INVITE. È uno di quei dettagli che raramente si ricordano a memoria, ma che mostrano bene quanto la RFC sia precisa nel definire la coerenza del dialogo.

4. Se l’offer arriva nella 2xx, l’answer va nell’ACK

Questo è forse il dettaglio più tecnico e più interessante da aggiungere come seconda lettura. Se la risposta 2xx contiene l’offer SDP, allora l’ACK deve portare l’answer. In altre parole, in certi casi l’ACK non serve solo a confermare il 200 OK, ma chiude anche lo scambio offer/answer sul piano SDP.

La RFC aggiunge un dettaglio ancora più interessante: se l’offer contenuta nella 2xx non è accettabile, il UAC deve comunque inviare nell’ACK un answer valido e poi chiudere subito il dialogo con un BYE. Questo passaggio fa capire molto bene quanto l’ACK sia inserito in una logica rigorosa di chiusura del setup, non in una semplice conferma meccanica.

5. L’ACK per 2xx non è gestito come quello delle risposte negative

Infine, c’è una distinzione architetturale importante. La RFC separa nettamente l’ACK generato per una risposta 2xx da quello generato per risposte finali non positive. Nel caso delle 2xx, l’ACK è generato dal UAC core e viene passato direttamente al transport layer. Non è il semplice prolungamento della normale client transaction.

Questo spiega anche perché, se il chiamato ritrasmette la risposta 2xx, il UAC deve ritrasmettere l’ACK. È un dettaglio da specifica, ma molto utile per capire alcuni pcap che altrimenti sembrano ripetitivi o ambigui.

6. Il dettaglio del timer: 64*T1 dopo la prima 2xx

“The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response.”
“Il core UAC considera completata la transazione INVITE 64*T1 secondi dopo la ricezione della prima risposta 2xx.”

Qui aggiungo solo un dettaglio importante, che merita però un articolo dedicato per essere trattato bene. Dopo la ricezione della prima risposta 2xx, la RFC prevede una finestra temporale di 64*T1 entro cui il UAC può ancora gestire eventuali altre risposte 2xx, come può accadere nei casi di forking. Scaduta questa finestra, il protocollo considera chiusa quella fase della gestione dell’INVITE. È un punto molto da RFC, utile per completare il quadro, ma lo riprenderò più avanti con il dettaglio che merita.

Conclusione

L’ACK è la conferma finale della fase di instaurazione della sessione SIP. Non è un riempitivo e non è un dettaglio minore dopo il 200 OK. È il messaggio con cui il chiamante dichiara di aver ricevuto la risposta finale positiva all’INVITE, chiudendo correttamente il setup sul piano della segnalazione.

Capire questo punto cambia il modo di leggere molti problemi reali. Quando il 200 OK c’è ma l’ACK manca, oppure non arriva dove dovrebbe, la chiamata non è chiusa correttamente dal punto di vista SIP. Ed è proprio qui che nascono molti guasti che sul campo sembra