RFC3261 Capitolo 9:

1, Set 2026 | Guida alla RFC3261 - IL DNA DEL VOIP, VOIP E PROTOCOLLO SIP

RFC 3261: Il DNA del VoIP – Capitolo 9
BYE e CANCEL: chiudere o interrompere una chiamata SIP

Dopo aver visto come nasce una sessione SIP e come viene confermata con ACK, possiamo affrontare un passaggio che nei tracciati pcap genera spesso qualche dubbio. Prima di entrare in CANCEL e BYE, conviene però fissare tre concetti che ci serviranno per leggere tutto il resto con più ordine.

Transaction, dialog e sessione avranno più avanti uno spazio tutto loro. Qui li teniamo volutamente semplici. Ci basta capire che cosa rappresentano e come riconoscerli quando abbiamo davanti un tracciato pcap.

Tre definizioni da fissare subito

Transaction, in modo semplice, è lo scambio tra una richiesta SIP e le risposte che appartengono a quella richiesta.

Dialog, sempre in modo semplice, è la relazione SIP che si crea tra due lati della comunicazione e che resta valida per un certo tempo, permettendo di scambiare richieste all’interno di quello stesso contesto.

Sessione è invece la comunicazione reale che il SIP sta cercando di instaurare, modificare o chiudere, per esempio una chiamata voce.

Quando le spiego in aula, cerco sempre di separarle subito. Sembrano vicine, ma descrivono tre livelli diversi della stessa comunicazione.

La transaction guarda il singolo scambio di segnalazione.
Il dialog guarda la relazione SIP che tiene insieme più messaggi coerenti tra loro.
La sessione guarda la comunicazione nel suo significato operativo, per esempio la chiamata tra due utenti.

Come distinguerli empiricamente in un tracciato pcap

Quando apro un tracciato pcap, per riconoscere una transaction parto da una richiesta precisa: INVITE, BYE, CANCEL o un altro metodo. Poi seguo le risposte che appartengono proprio a quella richiesta.

Per il dialog il ragionamento cambia. Qui seguo soprattutto Call-ID e tag di From e To. Se questi elementi restano coerenti nel tempo, sto osservando una relazione SIP che continua oltre la singola transaction.

La sessione la leggo invece dall’insieme: chi chiama chi, quando la chiamata viene accettata, quando parte il media e quando la comunicazione viene chiusa. È il livello che più assomiglia a ciò che, nella pratica, chiamiamo semplicemente chiamata.

Possiamo distinguerli anche così:

se guardi un singolo INVITE con le sue risposte, stai guardando soprattutto una transaction
se guardi la continuità tra INVITE, ACK, eventuale re-INVITE e BYE, stai guardando soprattutto un dialog
se guardi l’intera chiamata come evento comunicativo, stai guardando la sessione

Questa distinzione, qui presentata in modo volutamente semplice, ci basta per leggere bene il resto del capitolo. Nei capitoli dedicati a dialog e transaction layer torneremo su questi concetti con il livello di dettaglio completo previsto dalla RFC 3261.

CANCEL e BYE: due fasi diverse

Con queste tre definizioni in mente, possiamo finalmente entrare nel tema del capitolo.

CANCEL e BYE sono due metodi che servono a fermare una chiamata, ma in fasi diverse. CANCEL si usa quando il tentativo di chiamata è ancora pendente. BYE si usa quando la chiamata è già stata accettata e deve essere chiusa.

In termini più tecnici, CANCEL agisce su una richiesta ancora in corso, tipicamente un INVITE che non ha ancora ricevuto una risposta finale. BYE agisce invece all’interno di un dialog e termina la sessione associata.

Le sezioni di riferimento sono la Sezione 9, dedicata a CANCEL, e la Sezione 15, dedicata a BYE.

Quando leggo un tracciato pcap, la prima domanda che mi faccio è molto semplice: in quale fase della chiamata siamo? Siamo ancora prima della risposta finale? Abbiamo già un 200 OK? È arrivato l’ACK? Da questa risposta dipende la lettura corretta di CANCEL e BYE.

Che cosa dice la RFC sul CANCEL

“The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request.”
La richiesta CANCEL, come suggerisce il nome, viene usata per annullare una richiesta precedente inviata da un client. In modo specifico, chiede al lato UAS di interrompere l’elaborazione della richiesta e di generare una risposta di errore per quella richiesta.

Tradotto sul campo, CANCEL non chiude una sessione già attiva. Chiede al sistema remoto di interrompere l’elaborazione di una richiesta precedente. Se il telefono di Matteo sta ancora squillando e Daniele riaggancia, CANCEL è il messaggio con cui quel tentativo viene fermato prima della risposta finale.

La RFC aggiunge anche un altro punto decisivo: CANCEL non ha effetto se il lato UAS ha già generato una risposta finale. Questo significa che non esiste alcun potere retroattivo del metodo. Se la risposta finale è già partita, il CANCEL arriva troppo tardi per cambiare l’esito di quella transaction.

Per questo la RFC spiega che CANCEL è particolarmente utile per INVITE, cioè per richieste che possono restare aperte più a lungo delle altre. Un OPTIONS o un REGISTER, in condizioni normali, vengono gestiti molto più in fretta. Con un INVITE, invece, il terminale può squillare, l’utente può esitare, il proxy può fare forking, e la finestra temporale diventa molto più ampia.

Controllo del metodo

La RFC è molto chiara anche su un altro punto: un CANCEL non dovrebbe essere usato per annullare metodi diversi da INVITE. La ragione è pratica. Le richieste non-INVITE ricevono in genere una risposta immediata, quindi l’invio di un CANCEL creerebbe quasi sempre una corsa inutile tra messaggi.

Nel tracciato pcap la verifica è abbastanza immediata. Se la transaction originale è ancora in attesa di una risposta finale, CANCEL ha senso. Se invece la risposta finale è già arrivata, il CANCEL non può più cambiare quel risultato.

Un altro dettaglio importante è il modo in cui il CANCEL viene correlato alla richiesta originale. La RFC richiede che Request-URI, Call-ID, To, la parte numerica di CSeq e From siano identici a quelli della richiesta da annullare. Anche il Via deve corrispondere al top Via della richiesta originale. Cambia però il metodo nel CSeq, che diventa CANCEL.

Questo serve a un obiettivo molto concreto: il server deve poter capire con precisione quale richiesta precedente il CANCEL sta cercando di fermare, pur restando una transaction separata.

Quando può partire il CANCEL

La RFC aggiunge una regola che nel tracciato pcap è facile da trascurare: il client non deve inviare CANCEL prima di aver ricevuto almeno una risposta provvisoria alla richiesta originale.

Immaginiamo che Daniele invii l’INVITE e riagganci quasi subito. Se non è ancora arrivata neppure una risposta 1xx, il suo User Agent deve aspettare prima di trasmettere il CANCEL. Il motivo è molto pratico: senza questa regola, in alcune condizioni di rete il CANCEL potrebbe arrivare al server prima dello stesso INVITE che dovrebbe annullare.

Se invece nel frattempo è già arrivata una risposta finale all’INVITE, il CANCEL non va più inviato, perché non avrebbe alcun effetto sull’esito già prodotto.

Stesso percorso della richiesta originale

Anche la costruzione del CANCEL segue alcune regole precise. Se l’INVITE originale contiene un header Route, gli stessi valori devono essere riportati nel CANCEL. Inoltre destinazione, porta e protocollo di trasporto devono essere gli stessi usati per inviare la richiesta originale.

La RFC specifica anche che CANCEL non deve contenere gli header Require o Proxy-Require. Sono dettagli che riprenderemo quando parleremo in modo più completo di routing e proxy, ma vale la pena conoscerli già adesso perché aiutano a capire perché un CANCEL non viene costruito come una richiesta completamente indipendente.

Che cosa succede quando arriva il CANCEL

Se il lato UAS riceve un CANCEL valido per un INVITE ancora pendente, la RFC si aspetta un comportamento preciso. Il lato server risponde con un 200 OK al CANCEL per confermare la ricezione della richiesta di annullamento. Poi deve ancora chiudere correttamente l’INVITE originario, tipicamente con 487 Request Terminated.

Nei corsi insisto spesso su questo passaggio: il 200 OK al CANCEL non dice che la chiamata è definitivamente chiusa. Dice soltanto che il CANCEL è stato ricevuto e accettato come transaction autonoma.

L’INVITE originario deve comunque avere la sua conclusione. E la conclusione più tipica, quando il CANCEL arriva in tempo, è proprio 487 Request Terminated.

Daniele                         Matteo
   |                                |
   |------ INVITE ----------------->|
   |<----- 180 Ringing -------------| |------ CANCEL ----------------->|
   |<----- 200 OK (CANCEL) ---------|
   |<----- 487 Request Terminated --| |------ ACK -------------------->|
   |                                |

In questo schema il significato dei messaggi è molto preciso.

l’INVITE è partito correttamente
il terminale remoto ha iniziato a squillare con 180 Ringing
il chiamante ha deciso di interrompere il tentativo con CANCEL
il lato remoto ha confermato il CANCEL con 200 OK
l’INVITE è stato chiuso con 487 Request Terminated
il chiamante ha mandato ACK alla risposta finale non-2xx dell’INVITE

Per leggerlo bene dobbiamo quindi tenere separati i due livelli: la transaction del CANCEL e la conclusione dell’INVITE originale.

Quando il CANCEL non trova la richiesta

Il server deve anche riuscire a collegare il CANCEL alla transaction che si vuole interrompere. Se non trova una transaction corrispondente, la risposta prevista è 481 Call/Transaction Does Not Exist.

Se invece la transaction originale esiste, il CANCEL viene gestito come una transaction propria. Quando l’INVITE è ancora pendente, il comportamento che ci aspettiamo è quello già visto: 200 OK al CANCEL e, normalmente, 487 Request Terminated all’INVITE.

C’è poi un limite temporale. Se dopo il CANCEL non arriva alcuna risposta finale alla richiesta originale entro 64*T1, il client può considerare cancellata la transaction originaria e rimuoverne lo stato. Qui non entriamo ancora nei valori dei timer: T1, 64*T1 e le relative macchine a stati verranno ripresi nel capitolo dedicato al transaction layer.

CANCEL e proxy

CANCEL ha anche una caratteristica importante: viene trattato come richiesta hop-by-hop. Uno stateful proxy che riceve un CANCEL risponde direttamente a quel CANCEL e, quando serve, genera a sua volta i CANCEL verso le transaction aperte a valle.

Questo significa che in un tracciato con più proxy non dobbiamo immaginare il CANCEL come un unico messaggio che attraversa la rete senza essere gestito dai nodi intermedi. Il dettaglio completo appartiene al capitolo sui proxy, ma questa distinzione aiuta già a leggere meglio i flussi con più hop.

⚠ I CONSIGLI DI VOIP.IT

Quando vedi un CANCEL, non fermarti mai al suo 200 OK. Controlla sempre anche come si chiude l’INVITE originale.

Se trovi 487 Request Terminated, il tentativo di chiamata è stato interrotto prima della sessione confermata.
Se trovi invece un 2xx all’INVITE, il CANCEL è arrivato troppo tardi per fermare l’accettazione. A quel punto la chiusura richiede un BYE.
In Wireshark conviene correlare sempre Call-ID, CSeq, tag e direzione dei messaggi prima di concludere che la chiamata sia davvero terminata.

Che cosa dice la RFC sul BYE

Con BYE cambia proprio il livello di lettura. Con CANCEL stavamo ancora cercando di fermare una richiesta pendente. Con BYE lavoriamo invece dentro un dialog che esiste già e dobbiamo terminare la sessione associata.

Per questo la regola RFC sul BYE richiama concetti come early dialog, confirmed dialog e, più avanti, anche il completamento corretto del setup con ACK. Li chiariremo subito dopo la citazione, così la sequenza resta lineare.

“A UA MUST NOT send a BYE outside of a dialog. The caller’s UA MAY send a BYE for either confirmed or early dialogs, and the callee’s UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs.”
Un User Agent non deve inviare un BYE fuori da un dialog. Il lato chiamante può inviare un BYE sia per dialog confirmed sia per dialog early, mentre il lato chiamato può inviare un BYE sui dialog confirmed, ma non deve inviarlo sui dialog early.

Questo passaggio è importante perché mostra quanto BYE sia legato alla nozione di dialog. Diversamente da CANCEL, che agisce su una richiesta ancora in corso, BYE è un messaggio che vive dentro una relazione SIP già identificata dai suoi elementi di dialog.

La prima regola è netta: BYE non si invia fuori da un dialog. Quindi non è il metodo giusto per provare a fermare un INVITE iniziale che non ha ancora generato il contesto corretto. La RFC ha voluto esplicitamente separare questo caso, affidandolo a CANCEL.

La seconda regola richiede ancora più attenzione. Il lato chiamante può inviare BYE anche su un early dialog. Il lato chiamato, invece, non può farlo. Può inviare BYE solo su un dialog confirmed.

Questa differenza non è casuale. Dipende dal modo in cui il protocollo fa nascere e consolidare il dialogo tra le due parti.

Early dialog e confirmed dialog, spiegati in modo semplice

Qui ci basta una lettura pratica. Il capitolo dedicato ai dialoghi entrerà molto più in profondità; per ora ci interessa capire quando un dialog è ancora early e quando diventa confirmed.

Un dialog è la relazione SIP che si forma tra due lati della comunicazione e che viene identificata da elementi come Call-ID, tag locale e tag remoto. Questa relazione non nasce tutta in un colpo solo. Ha una fase iniziale e una fase confermata.

Un early dialog è un dialog che ha già iniziato a prendere forma, ma che non è ancora arrivato alla risposta finale di successo che conferma davvero la sessione.

Un confirmed dialog è invece un dialog che ha già ricevuto una risposta finale 2xx all’INVITE ed è quindi entrato nella fase confermata della comunicazione.

Detto in modo semplice:

early dialog, la chiamata è avviata ma non ancora accettata in modo definitivo
confirmed dialog, la chiamata è stata accettata con risposta finale di successo

Esempio pratico di early dialog

Immaginiamo che Daniele chiami Matteo.

Daniele                         Matteo
   |                                |
   |------ INVITE ----------------->|
   |<----- 180 Ringing -------------|
   |                                |

Matteo non ha ancora accettato la chiamata. Il suo terminale sta semplicemente dicendo che sta squillando. Se in questa fase si è già formato il dialog, siamo davanti a un early dialog: la relazione SIP esiste, ma la sessione non è ancora stata accettata in modo definitivo.

Che cosa significa operativamente? Significa che la chiamata è in corso di instaurazione, ma non è ancora arrivata al punto in cui possiamo dire che la sessione sia davvero confermata.

È proprio per questo che la RFC separa bene i comportamenti dei due lati. Il chiamante, in alcune condizioni, può ancora decidere di chiudere quel ramo con BYE. Il chiamato, invece, non deve usare BYE su un early dialog. Prima della conferma, il protocollo vuole mantenere separato il piano del tentativo di chiamata da quello della sessione ormai accettata.

Esempio pratico di confirmed dialog

Adesso prendiamo lo stesso caso e portiamolo un passo avanti.

Daniele                         Matteo
   |                                |
   |------ INVITE ----------------->|
   |<----- 180 Ringing -------------|
   |<----- 200 OK ------------------| |------ ACK -------------------->|
   |                                |

Con il 200 OK il quadro cambia. L’INVITE è stato accettato e il dialog diventa confirmed. Quando arriva anche l’ACK, il setup della segnalazione è completato. Da quel momento siamo nel caso più comune di chiamata attiva che, quando deve terminare, viene chiusa con BYE.

Questo è il contesto tipico del BYE. Quando la chiamata è arrivata qui, se una delle due parti vuole terminarla, la richiesta corretta è BYE, seguita da 200 OK.

Se è il chiamato a rifiutare

Fin qui abbiamo guardato soprattutto il comportamento del chiamante che decide di rinunciare al tentativo. Dal lato chiamato la logica è diversa.

Se Matteo non ha ancora accettato l’INVITE e decide di rifiutare la chiamata, non deve inviare CANCEL, perché non è lui ad aver generato la richiesta originale. E non può usare BYE su un early dialog. Deve invece chiudere l’INVITE con una risposta finale non-2xx adatta al motivo del rifiuto.

La Sezione 15 cita, come esempio legato all’interfaccia utente, anche 403 Forbidden per esprimere il rifiuto prima della risposta. Il codice concreto dipende dal motivo e dal comportamento del sistema, ma la regola da ricordare è semplice: prima dell’accettazione, il chiamato rifiuta l’INVITE con una risposta finale; non termina la chiamata con BYE.

Il lato UAC

Dal punto di vista del lato che invia il BYE, la RFC tratta il metodo come una normale richiesta in-dialog. Una volta costruito il messaggio, il lato UAC crea una nuova non-INVITE client transaction e lo invia.

C’è però una regola operativa molto forte: il lato che invia BYE deve considerare la sessione terminata immediatamente, cioè dal momento in cui passa il BYE alla client transaction. In pratica, deve smettere di inviare e ricevere media subito, senza aspettare il 200 OK finale.

Questo è un dettaglio utile anche in diagnostica. Se un terminale continua a tenere attivo il media molto oltre l’invio del BYE, il comportamento va guardato con attenzione, perché la logica RFC è diversa.

La RFC chiarisce anche un caso che sul campo può creare dubbi. Se il BYE riceve un 481 Call/Transaction Does Not Exist, un 408 Request Timeout oppure non riceve alcuna risposta, il lato UAC deve comunque considerare terminati sia la sessione sia il dialog.

Quindi l’assenza del classico 200 OK al BYE non significa che il terminale debba mantenere attiva la chiamata. Dal punto di vista del lato che ha inviato il BYE, la sessione è già terminata.

Il lato UAS

Quando il lato UAS riceve un BYE, deve prima verificare che il messaggio corrisponda a un dialog esistente. Se non trova un dialog valido, la risposta corretta è normalmente 481 Call/Transaction Does Not Exist.

Se invece il dialog esiste, il lato UAS deve elaborare il BYE e poi rispondere con una risposta 2xx, in pratica quasi sempre 200 OK. Dopo questo passaggio la sessione viene considerata terminata e il media si ferma.

Nel tracciato pcap, una chiusura pulita della chiamata si presenta quindi in modo molto lineare.

Matteo                          Daniele
   |                                |
   |------ BYE -------------------->|
   |<----- 200 OK ------------------|
   |                                |

Qui il tracciato è leggibile senza ambiguità. Il dialog esiste già. Uno dei due lati decide di chiudere la sessione. L’altro conferma con 200 OK. Non serve alcun ACK, perché ACK ha una logica speciale legata all’INVITE, non ai metodi non-INVITE.

Dopo il BYE

La ricezione di un BYE valido non fa sparire automaticamente le altre richieste che erano già pendenti sullo stesso dialog. Il UAS deve ancora rispondere a quelle richieste e la RFC raccomanda, in questi casi, una risposta 487 Request Terminated.

È un dettaglio utile nei tracciati più complessi, dove un BYE può incrociarsi con una richiesta già in corso. Vedere un 487 dopo il BYE non significa necessariamente che il BYE sia fallito: può appartenere a un’altra transaction che era ancora aperta sul dialog.

La RFC contempla anche un caso particolare per le sessioni multicast. In quel contesto un UAS può scegliere di continuare la propria partecipazione al media anche dopo il BYE dell’altro lato, pur dovendo comunque rispondere 2xx al BYE. È uno scenario poco comune nel VoIP Business e non lo approfondiamo qui.

Il vincolo sul lato chiamato

Ora che la differenza tra early dialog e confirmed dialog è chiara, possiamo leggere meglio la regola più delicata del BYE.

Il lato chiamato non deve inviare BYE su un dialog confirmed finché non ha ricevuto l’ACK al proprio 2xx, oppure finché non termina la server transaction.

La ragione è semplice: con il 200 OK il dialog è già confirmed, ma il passaggio INVITE–200 OK–ACK non è ancora completo. Il chiamato deve quindi lasciare al protocollo il tempo di ricevere l’ACK. Se l’ACK non arriva, entreranno in gioco i timer previsti dalla RFC.

Tra 200 OK e ACK

C’è una fase molto breve ma importante da distinguere. Matteo ha già accettato l’INVITE con 200 OK, quindi il dialog è confirmed, ma non ha ancora ricevuto l’ACK.

Daniele                         Matteo
   |                                |
   |------ INVITE ----------------->|
   |<----- 180 Ringing -------------|
   |<----- 200 OK ------------------|
   |                                |

In questa finestra il lato chiamato non deve ancora inviare BYE. Deve prima attendere l’ACK oppure la scadenza prevista dal protocollo. Questo passaggio spiega perché un dialog può essere già confirmed mentre il setup dell’INVITE non è ancora completato dal punto di vista della segnalazione.

Che cosa significa timeout in questo contesto

Il timeout, in questo passaggio, va letto in modo molto concreto: il lato chiamato non può aspettare per sempre un ACK che potrebbe non arrivare.

Se dopo il 200 OK il chiamato non riceve l’ACK entro il tempo previsto dal protocollo, la server transaction conclude che il completamento del setup non è avvenuto come atteso. A quel punto non ha più senso restare sospesi in quella fase intermedia.

Nel capitolo dedicato al transaction layer vedremo in dettaglio timer, stati e macchine a stati della RFC 3261. Qui basta fissare l’idea pratica: il timeout è il limite oltre il quale il protocollo smette di aspettare l’ACK come evento ancora plausibile.

Nel tracciato pcap questo scenario si riconosce abbastanza bene: il 200 OK all’INVITE viene ritrasmesso più volte, ma l’ACK non compare. In quel caso non sto cercando un problema di chiusura della chiamata. Sto ancora cercando perché il setup non si è completato correttamente.

Come leggere questa regola in pratica

Possiamo quindi tradurre la regola RFC così:

prima del 200 OK, siamo ancora nella fase di instaurazione
dopo il 200 OK, il dialog entra nella fase confermata, ma il lato chiamato deve ancora attendere l’ACK
solo dopo l’ACK, oppure dopo il timeout previsto se l’ACK non arriva, il lato chiamato può chiudere con BYE senza creare incoerenze nel setup

Questa lettura è molto utile perché evita due errori frequenti:

pensare che il 200 OK da solo basti sempre a considerare il setup completamente chiuso
pensare che il BYE sia un metodo generico da usare in qualsiasi punto della chiamata

Cosa succede se il CANCEL arriva troppo tardi

Questo è uno di quei casi che in Wireshark vale la pena leggere con calma. Daniele invia CANCEL mentre l’INVITE è ancora pendente, ma quasi nello stesso momento Matteo accetta la chiamata con 200 OK.

Se il 200 OK all’INVITE è già stato generato, il CANCEL non può annullarlo retroattivamente. Daniele deve riconoscere quella risposta con ACK e, se non vuole proseguire la chiamata, chiudere poi la sessione con BYE.

Daniele                         Matteo
   |                                |
   |------ INVITE ----------------->|
   |<----- 180 Ringing -------------| |------ CANCEL ----------------->|
   |<----- 200 OK (CANCEL) ---------|
   |<----- 200 OK (INVITE) ---------| |------ ACK -------------------->|
   |------ BYE -------------------->|
   |<----- 200 OK ------------------|
   |                                |

La lettura corretta è quindi questa: il CANCEL è stato ricevuto, ma è arrivato troppo tardi per impedire l’accettazione dell’INVITE. Il 200 OK al CANCEL conferma soltanto la ricezione del CANCEL; il 200 OK all’INVITE crea invece un esito diverso, che richiede ACK e, se la chiamata va chiusa, BYE.

Quando lo vediamo in un tracciato pcap non dobbiamo quindi pensare subito a un errore. È una conseguenza possibile della temporizzazione dei messaggi SIP.

Consigli pratici per Wireshark

Quando analizzi una chiusura o un’interruzione di chiamata, evita di partire dal singolo pacchetto. Ricostruisci prima il flusso completo e poi verifica a quale transaction appartiene ogni risposta.

Un metodo pratico è questo:

parti dal Call-ID per isolare i messaggi della chiamata
controlla il CSeq per capire a quale metodo appartiene una risposta, soprattutto quando nello stesso flusso compaiono più 200 OK
verifica la direzione dei messaggi e i tag di From e To quando devi seguire il dialog
se trovi un CANCEL, cerca sempre anche la risposta finale all’INVITE
se trovi 487 Request Terminated, verifica che sia seguito dall’ACK previsto per la risposta finale non-2xx all’INVITE
se trovi un 200 OK all’INVITE dopo il CANCEL, cerca l’ACK e l’eventuale BYE successivo
se trovi un CANCEL, verifica che prima sia arrivata almeno una risposta provvisoria all’INVITE originale
un 481 in risposta al CANCEL indica che il server non ha trovato la transaction da cancellare
con più proxy, ricorda che CANCEL è hop-by-hop e può essere gestito e rigenerato dagli stateful proxy
se un BYE riceve 481, 408 o va in timeout, il lato che lo ha inviato considera comunque sessione e dialog terminati

Wireshark mette a disposizione anche filtri utili per restringere rapidamente l’analisi:

sip.Method == "CANCEL"
sip.Method == "BYE"
sip.Status-Code == 487
sip.CSeq.method == "INVITE"
sip.CSeq.method == "CANCEL"
sip.Call-ID == "valore-del-call-id"

Il filtro sul CSeq è particolarmente utile quando compaiono due risposte 200 OK vicine: una può riferirsi al CANCEL e l’altra all’INVITE. Guardare solo il codice di risposta non basta; bisogna leggere il metodo indicato nel CSeq.

Se invece vedi più 200 OK all’INVITE e nessun ACK, concentra l’analisi sul percorso dell’ACK e sulla raggiungibilità del lato che ha generato il 200 OK. Le ritrasmissioni, da sole, non dicono ancora dove sia il problema, ma indicano che il completamento del setup non è avvenuto come previsto.

Per una vista d’insieme può essere utile anche il flusso VoIP di Wireshark, così da verificare rapidamente ordine, direzione e tempi dei messaggi prima di entrare nel dettaglio dei singoli pacchetti.

Per i nomi aggiornati dei campi puoi fare riferimento alla Display Filter Reference SIP di Wireshark.

Perché la RFC separa così nettamente i due metodi

La separazione tra i due metodi serve a mantenere ordinati i diversi livelli del protocollo. CANCEL lavora su una richiesta ancora in corso. BYE lavora su una sessione che vive già dentro un dialog. Tenere distinti questi due casi rende più semplice anche il troubleshooting.

Per questo la RFC 3261 chiarisce anche che, rispetto a RFC 2543, CANCEL e BYE non devono più essere mescolati. L’INVITE originario va sempre chiuso correttamente. Se il chiamante vuole fermarsi prima della risposta finale usa CANCEL. Se invece un dialog è stato già accettato, la chiusura corretta passa da BYE.

È una distinzione che, una volta interiorizzata, rende molto più naturale la lettura dei flussi SIP reali.

Conclusione

In questo capitolo abbiamo chiarito una distinzione fondamentale della RFC 3261. CANCEL non chiude una sessione già accettata. Ferma una richiesta ancora pendente e prova a far chiudere l’INVITE con una risposta finale non-2xx, in genere 487 Request Terminated. BYE, invece, vive dentro un dialog e termina la sessione associata.

Quando analizziamo un tracciato pcap, quindi, non fermiamoci mai al 200 OK del CANCEL. Seguiamo sempre anche l’INVITE originale e verifichiamo come si chiude. Se nel frattempo è arrivato un 2xx, potrebbe essere nato un dialog che richiede poi un BYE.

Dopo aver chiarito come una chiamata SIP può essere interrotta o terminata, nel prossimo capitolo vedremo OPTIONS. Sarà il passaggio giusto per capire come il protocollo usa una richiesta diversa da INVITE per interrogare capacità e disponibilità, senza entrare ancora nei capitoli più avanzati su dialoghi, transaction layer e proxy.

VoIP oltre il SIP: le RFC fondamentali per media, DTMF e NAT traversal

16, Lug 2026 | VOIP E PROTOCOLLO SIP

Nel precedente articolo abbiamo costruito una mappa completa delle RFC del protocollo SIP, concentrandoci sulla segnalazione: metodi, header, dialoghi, routing e logiche operative. È però importante fermarsi un attimo e fare un passo in più. Perché chi lavora davvero con il VoIP sa che il SIP, da solo, non basta a spiegare cosa succede durante una chiamata.

Il SIP decide come instaurare, modificare e terminare una sessione. Ma la voce, i toni DTMF, la qualità audio, i problemi legati al NAT e alla rete non passano dal SIP: viaggiano su protocolli diversi, regolati da altre RFC. È proprio in questa separazione tra piano di segnalazione e piano media che si trovano molti dei problemi reali che incontriamo ogni giorno su PBX, SBC, gateway e terminali.

In questo articolo andremo quindi a completare il quadro, analizzando le principali RFC che, pur non essendo SIP in senso stretto, sono fondamentali per capire il funzionamento reale del VoIP. L’obiettivo è collegare i concetti già visti con il comportamento effettivo del Voice over IP

DTMF: quando la segnalazione incontra il piano media

Uno dei casi più classici è la gestione dei toni DTMF. Chi ha fatto troubleshooting su IVR, gateway o centralini sa quanto questo tema sia critico. Dal punto di vista SIP, i DTMF vengono semplicemente negoziati tramite SDP. Ma il loro trasporto reale avviene a livello RTP.

La prima RFC che ha standardizzato questo comportamento è la RFC 2833, poi aggiornata dalla RFC 4733, oggi riferimento principale. In questo modello, i toni non vengono inviati come audio, ma come eventi codificati all’interno del flusso RTP, tipicamente con il payload “telephone-event”.

Accanto a questo approccio esistono altre due modalità: l’invio in banda audio (inband) e l’uso del metodo SIP INFO. Ed è proprio qui che nascono molti problemi di interoperabilità. Apparati diversi possono supportare modalità diverse o configurazioni non allineate, generando malfunzionamenti difficili da diagnosticare se non si ha chiara la distinzione tra segnalazione e media.

RTP e RTCP: dove viaggia davvero la voce

Se il SIP costruisce la chiamata, è l’RTP a trasportare la voce. Il riferimento principale è la RFC 3550, che definisce il Real-time Transport Protocol, affiancata dalla RFC 3551 che specifica i profili per audio e video.

RTP introduce concetti fondamentali come timestamp, sequence number e sincronizzazione dei flussi. Accanto a RTP troviamo RTCP, utilizzato per fornire statistiche sulla qualità della trasmissione: jitter, perdita di pacchetti, latenza. Questi parametri sono spesso invisibili a livello SIP, ma sono determinanti per la qualità percepita dall’utente.

Capire RTP significa anche comprendere perché una chiamata può risultare silenziosa, monodirezionale o disturbata pur avendo una segnalazione SIP perfettamente corretta.

SDP e negoziazione dei codec

Il ponte tra SIP e RTP è rappresentato dal protocollo SDP, definito nella RFC 4566. È all’interno dell’SDP che vengono negoziati codec, porte, indirizzi IP e parametri del flusso media.

Il modello di negoziazione è descritto nella RFC 3264, basato sul meccanismo offer/answer. È qui che si decide, ad esempio, se una chiamata utilizzerà G.711, G.729 o altri codec, e con quali parametri.

Molti problemi reali derivano proprio da questa fase: codec non compatibili, payload type dinamici interpretati in modo diverso, porte RTP non raggiungibili. Anche in questo caso, il SIP fa solo da contenitore: il comportamento reale è determinato da ciò che viene negoziato nell’SDP.

NAT traversal: il vero problema del VoIP moderno

Uno dei temi più critici nel VoIP è la gestione del NAT. Il SIP, per sua natura, include indirizzi IP e porte nei messaggi. Quando questi attraversano dispositivi NAT, le informazioni possono diventare incoerenti, causando problemi di audio o di raggiungibilità.

Per affrontare questo problema sono state definite diverse tecnologie. La RFC 5389 descrive STUN, utilizzato per scoprire l’indirizzo pubblico e il tipo di NAT. La RFC 5766 introduce TURN, che consente di fare relay del traffico media quando la comunicazione diretta non è possibile.

Il modello più completo è definito dalla RFC 8445, che descrive ICE. ICE combina STUN e TURN per testare diversi percorsi e selezionare automaticamente quello funzionante.

Accanto a queste tecnologie troviamo meccanismi di keep-alive, spesso implementati tramite messaggi SIP o CRLF, fondamentali per mantenere aperte le associazioni NAT. Anche qui, la distinzione tra segnalazione e media è centrale: il problema nasce nella rete, ma si manifesta come sintomo SIP.

QoS e qualità della voce

La qualità di una chiamata VoIP non dipende solo dai protocolli, ma anche dal comportamento della rete. Le RFC 2474 e 4594 introducono il modello DiffServ, che consente di classificare e prioritizzare il traffico.

Nel caso della voce, viene spesso utilizzata la classe EF (Expedited Forwarding), che garantisce bassa latenza e jitter ridotto. Senza una corretta gestione della QoS, anche una configurazione SIP perfetta può risultare in una qualità audio scadente.

La sicurezza del flusso media

Un altro aspetto fondamentale è la sicurezza. Se il SIP può essere protetto tramite TLS, il traffico RTP deve essere cifrato separatamente. La RFC 3711 definisce SRTP, il protocollo per la cifratura del flusso audio.

Meccanismi come quelli descritti nella RFC 4568 e nella RFC 5764 permettono di negoziare le chiavi e proteggere la comunicazione end-to-end. Anche in questo caso, il SIP trasporta le informazioni, ma la sicurezza reale si applica al media.

Fax over IP e i limiti pratici

Un caso particolare, ma ancora molto diffuso, è quello del fax su IP. La RFC 3362 descrive le problematiche legate al trasporto fax su reti IP.

Il trasporto diretto via audio (G.711) può fallire a causa di perdita di pacchetti o jitter. Per questo motivo è stato introdotto il protocollo T.38, che converte il fax in un flusso dati più robusto. È un esempio perfetto di come il comportamento reale del VoIP dipenda da fattori che vanno ben oltre il SIP.

Mettere insieme i pezzi: il VoIP come sistema

A questo punto dovrebbe essere chiaro un aspetto fondamentale: il VoIP non è il SIP. È un sistema composto da più livelli, ciascuno regolato da protocolli e RFC differenti. Il SIP costruisce la chiamata, l’SDP negozia i parametri, l’RTP trasporta la voce, STUN e ICE risolvono i problemi di rete, SRTP protegge i dati, e la QoS determina la qualità finale.

È proprio nell’interazione tra questi elementi che si gioca la vera complessità del VoIP. Ed è per questo che, quando si analizza un problema, limitarsi alla segnalazione SIP raramente è sufficiente. Serve una visione completa, capace di collegare le RFC tra loro e di interpretare il comportamento dell’intero sistema.

Se non hai ancora approfondito il funzionamento del protocollo SIP e delle sue RFC principali, ti consiglio di partire da questo articolo, dove ho costruito una mappa completa della segnalazione VoIP:

Le RFC del protocollo SIP: guida completa ai documenti core

Fonti utili per approfondire

Per chi volesse approfondire gli argomenti trattati, ecco alcune fonti online utili:

RFC 4733 – RTP Payload for DTMF

Le RFC del protocollo SIP: come leggere, capire e usare davvero i documenti fondamentali

16, Lug 2026 | VOIP E PROTOCOLLO SIP

Chi lavora da anni con il VoIP sa bene che, a un certo punto, la configurazione non basta più. Arriva sempre il momento in cui bisogna capire perché un terminale si registra in un certo modo, perché un proxy risponde con una determinata logica, perché un trasferimento va a buon fine su un sistema e fallisce su un altro, oppure perché un comportamento apparentemente anomalo è in realtà perfettamente conforme allo standard. È in quel momento che si torna alle RFC.

Nel mondo SIP, le RFC non sono un semplice apparato teorico. Sono la documentazione tecnica che definisce il protocollo, ne spiega i meccanismi, ne chiarisce le estensioni e, soprattutto, fornisce un riferimento autorevole quando bisogna fare analisi, troubleshooting o progettazione. Il problema è che parlare di “RFC del SIP” al singolare è quasi fuorviante. In realtà esiste un insieme molto ampio di documenti: alcuni sono davvero centrali, altri sono estensioni importanti, altri ancora riguardano aspetti più verticali come la presenza, le conferenze, l’identità, la mobilità o l’attraversamento del NAT.

Per questo motivo, in questo articolo ho voluto costruire una guida ordinata e leggibile. L’obiettivo non è solo elencare tutte le RFC SIP core e le estensioni Standards Track più rilevanti, ma anche aiutare il lettore a capire come leggerle, da dove iniziare e quali documenti meritino davvero attenzione prioritaria. L’idea, in altre parole, è quella di trasformare un elenco numerico in una mappa tecnica utile per chi lavora ogni giorno con centralini IP, SBC, trunk SIP, softphone e infrastrutture multi-vendor.

Oltre alle RFC Fondamentali esistono tuttavia anche RFC strettamente correlate al mondo VoIP, ma non direttamente parte del protocollo SIP, come quelle relative al trasporto RTP (ad esempio per i DTMF), alla gestione dei media e del NAT Traversal che verranno trattate separatamente per mantenere chiara la distinzione tra piano di segnalazione e piano media.

Cosa sono le RFC e perché sono così importanti nel protocollo SIP

La sigla RFC significa Request for Comments. È una denominazione storica che risale alle origini di Internet, ma che oggi identifica i documenti tecnici pubblicati dall’IETF per definire protocolli, estensioni, procedure e standard di rete. Non tutte le RFC hanno lo stesso peso: alcune sono informative, altre descrivono buone pratiche, altre ancora rientrano nel percorso normativo vero e proprio. Nel caso di SIP, molte delle RFC più importanti appartengono alla categoria Standards Track, cioè documenti pensati per descrivere in modo normativo il comportamento delle implementazioni.

Per chi fa formazione, progettazione o assistenza tecnica su piattaforme VoIP, il valore delle RFC è enorme. Significa poter distinguere tra un comportamento realmente errato e uno che invece è coerente con lo standard, anche se magari inatteso. Significa comprendere perché esistano metodi come INVITE, UPDATE, REFER o INFO, perché alcuni header siano critici per il routing e altri per l’identità, e perché certi problemi di interoperabilità nascano non tanto da bug evidenti, quanto da interpretazioni incomplete o parziali delle specifiche.

La RFC 3261, che rappresenta il riferimento principale del SIP moderno, definisce il protocollo come un meccanismo di segnalazione a livello applicativo per creare, modificare e terminare sessioni multimediali. Ma già da sola, questa definizione lascia intuire una cosa importante: SIP non è stato progettato come un blocco monolitico. È un protocollo estendibile, stratificato, evoluto nel tempo attraverso documenti aggiuntivi. Ed è proprio questa evoluzione ad aver generato il vasto ecosistema di RFC che oggi vale la pena conoscere.

Perché non basta conoscere solo la RFC 3261

Molti tecnici, soprattutto nelle prime fasi di studio, identificano SIP quasi esclusivamente con la RFC 3261. È comprensibile, perché quella RFC è il cuore del protocollo. Definisce la sintassi dei messaggi, i metodi principali, la logica delle transazioni, i dialoghi, il comportamento di proxy, registrar e user agent. Tuttavia, nella pratica quotidiana, lavorare con SIP significa quasi sempre andare oltre quel solo documento.

Basta pensare a quante funzioni operative dipendano da RFC aggiuntive: la gestione affidabile delle risposte provvisorie, l’uso del DNS per localizzare i server, il meccanismo UPDATE, gli header legati a identità e privacy, il Path per le registrazioni non adiacenti, il Service-Route, il supporto agli eventi, la presenza, il transfer, i Session Timer, la mobilità, il riuso delle connessioni, l’uso dei certificati di dominio, le correzioni legate a IPv6 e i chiarimenti sul comportamento di re-INVITE e target refresh.

In altre parole, la RFC 3261 è il fondamento, ma il SIP reale che troviamo nei sistemi in produzione è il risultato dell’interazione tra molti documenti. Ignorare questa stratificazione significa rischiare una comprensione incompleta del protocollo. Per questo è utile distinguere tra RFC veramente core, RFC di estensione ad alta frequenza pratica e RFC più specialistiche, da consultare in base al contesto applicativo.

Le RFC SIP core da conoscere subito

Se dovessi costruire un primo percorso di studio serio, partirei da un gruppo ristretto di documenti che considero essenziali. In cima c’è ovviamente la RFC 3261, che definisce il SIP nella sua forma moderna. Accanto a lei metterei subito la RFC 3262, indispensabile per capire le provisional response affidabili, e la RFC 3263, fondamentale per comprendere come si localizzano i server SIP attraverso DNS e quindi come si costruisce davvero il routing lato rete.

Subito dopo entrano in gioco documenti che ogni tecnico VoIP incontra prima o poi in un tracciato reale: la RFC 3311 per UPDATE, la RFC 3325 per l’identità asserted nei trusted network, la RFC 3326 per il Reason header, la RFC 3327 per il Path, la RFC 3581 per il symmetric response routing e la RFC 3608 per il Service-Route.

Quando poi si passa ai problemi di sessione e servizi avanzati, diventano importanti la RFC 3891 per Replaces, la RFC 3903 per PUBLISH, la RFC 4028 per i Session Timer, la RFC 5626 e la RFC 5627 per connessioni persistenti e GRUU, la RFC 5922 e la RFC 5923 per certificati e riuso delle connessioni, la RFC 6086 per il framework moderno di INFO, la RFC 6141 per re-INVITE e target-refresh e la RFC 6665 per il framework aggiornato degli eventi SIP.

Le origini del protocollo: dalle prime specifiche alla definizione del SIP moderno

1999-2002: il passaggio dalla RFC storica al vero core operativo

La storia del SIP, dal punto di vista documentale, inizia con la RFC 2543 del 1999. È la prima formulazione completa del protocollo, il documento da cui tutto parte. Oggi è obsoleta, ma rimane importante dal punto di vista storico e didattico, perché permette di capire quanto SIP sia maturato nel passaggio verso la versione formalizzata nella RFC 3261.

Già nei primi anni Duemila si vede chiaramente che il protocollo non resterà confinato a una semplice segnalazione base. La RFC 2976 introduce INFO, anticipando il bisogno di trasportare informazioni applicative all’interno del dialogo SIP. Nello stesso periodo compaiono anche documenti come la RFC 3050 e la RFC 3087, segnali di un ecosistema che inizia già a specializzarsi.

Il 2002 è l’anno decisivo. Con la RFC 3261 nasce il SIP che ancora oggi studiamo e utilizziamo come riferimento. Nello stesso periodo arrivano documenti chiave come la RFC 3262, la RFC 3263, la RFC 3265, la RFC 3311, la RFC 3323, la RFC 3325, la RFC 3326 e la RFC 3327. È il momento in cui la teoria di base diventa finalmente un’architettura articolata, pronta per il mondo reale.

Elenco completo delle RFC SIP dal 1999 al 2005

1999

RFC 2543: SIP: Session Initiation Protocol – OBSOLETA, sostituita da RFC 3261 e RFC 3263

2000

RFC 2848: Extensions for IP Access to Telephone Call Services

RFC 2976: The SIP INFO Method – OBSOLETA, sostituita da RFC 6086

2001

RFC 3050: Common Gateway Interface for SIP

RFC 3087: Control of Service Context using SIP Request-URI

2002

RFC 3261: SIP: Session Initiation Protocol

RFC 3262: Reliability of Provisional Responses in SIP

RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers

RFC 3265: SIP-Specific Event Notification – OBSOLETA, sostituita da RFC 6665

RFC 3311: The Session Initiation Protocol (SIP) UPDATE Method

RFC 3312: Integration of Resource Management and SIP

RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP)

RFC 3324: Short Term Requirements for Network Asserted Identity

RFC 3325: Private Extensions to SIP for Asserted Identity within Trusted Networks

RFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP)

RFC 3327: SIP Extension Header Field for Registering Non-Adjacent Contacts

RFC 3361: DHCP-for-IPv4 Option for SIP Servers

RFC 3372: SIP for Telephones (SIP-T): Context and Architectures

RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to SIP Mapping

RFC 3428: Session Initiation Protocol (SIP) Extension for Instant Messaging

2003

RFC 3313: Private SIP Extensions for Media Authorization

RFC 3319: Dynamic Host Configuration Protocol (DHCPv6) Options for SIP Servers

RFC 3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP)

RFC 3455: Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP

RFC 3515: The Session Initiation Protocol (SIP) Refer Method

RFC 3578: Mapping ISUP Overlapped Signalling to SIP

RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

RFC 3608: Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration

RFC 3680: A Session Initiation Protocol (SIP) Event Package for Registrations

2004

RFC 3840: Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)

RFC 3841: Caller Preferences for the Session Initiation Protocol (SIP)

RFC 3842: A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)

RFC 3856: A Presence Event Package for the Session Initiation Protocol (SIP)

RFC 3857: A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)

RFC 3891: The Session Initiation Protocol (SIP) “Replaces” Header

RFC 3892: The Session Initiation Protocol (SIP) Referred-By Mechanism

RFC 3893: Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format

RFC 3903: Session Initiation Protocol (SIP) Extension for Event State Publication

RFC 3911: The Session Initiation Protocol (SIP) “Join” Header

RFC 3959: The Early Session Disposition Type for the Session Initiation Protocol (SIP)

RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)

2005

RFC 4028: Session Timers in the Session Initiation Protocol (SIP)

RFC 4092: Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) – OBSOLETA, sostituita da RFC 5245

RFC 4235: An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)

RFC 4244: An Extension to the Session Initiation Protocol (SIP) for Request History Information

La maturazione del protocollo: identità, eventi, conferenze, NAT e mobilità

2006-2012: il SIP si consolida come ecosistema completo

A partire dal 2006, il SIP entra in una fase di maturazione più avanzata. Le RFC non si limitano più a definire il comportamento di base della segnalazione, ma intervengono per correggere casi limite, aggiungere nuove capacità e rendere il protocollo più robusto nei contesti reali. Compaiono così documenti su preemption, priorità delle comunicazioni, identità autenticata, eventi di conferenza, liste di risorse, presenza avanzata, servizi multi-destinatario, misurazione delle prestazioni, supporto alla mobilità e robustezza delle connessioni.

Questo è anche il periodo in cui il SIP diventa sempre più vicino ai problemi che i tecnici incontrano davvero sul campo. Pensiamo al NAT traversal, al riuso delle connessioni TCP/TLS, alla gestione corretta di Record-Route, all’uso dei certificati di dominio, al supporto IPv6, ai keep-alive, alle problematiche di transfer, alle correzioni sul comportamento di re-INVITE e target refresh. Chi guarda questo insieme di RFC non dovrebbe vederlo come una semplice appendice della 3261, ma come la prova concreta che SIP è stato progettato per adattarsi a una realtà operativa complessa e in continua evoluzione.

Elenco completo delle RFC SIP dal 2006 al 2012

2006

RFC 4320: Actions Addressing Identified Issues with the Session Initiation Protocol (SIP) Non-INVITE Transaction

RFC 4411: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events

RFC 4412: Communications Resource Priority for the Session Initiation Protocol (SIP)

RFC 4474: Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

RFC 4479: A Data Model for Presence

RFC 4483: A Mechanism for Content Indirection in the Session Initiation Protocol (SIP)

RFC 4488: Suppression of the Session Initiation Protocol (SIP) REFER Method Implicit Subscription

RFC 4508: Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method

RFC 4575: A Session Initiation Protocol (SIP) Event Package for Conference State

RFC 4662: A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists

RFC 4730: A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)

2007

RFC 4780: Management Information Base for the Session Initiation Protocol (SIP)

RFC 4904: Representing Trunk Groups in tel: and sip: Uniform Resource Identifiers (URIs)

RFC 4916: Connected Identity in the Session Initiation Protocol (SIP)

RFC 4967: Dial String Parameter for the Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)

RFC 4975: The Message Session Relay Protocol (MSRP)

RFC 4976: Relay Extensions for the Message Session Relay Protocol (MSRP)

RFC 5079: Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)

2008

RFC 5196: A Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)

RFC 5239: A Framework for Centralized Conferencing

RFC 5263: Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information

RFC 5264: Publication of Partial Presence Information

RFC 5362: The Session Initiation Protocol (SIP) Pending Additions Event Package

RFC 5363: Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services

RFC 5365: Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)

RFC 5366: Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)

RFC 5367: Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)

RFC 5368: Referring to Multiple Resources in the Session Initiation Protocol (SIP)

RFC 5370: The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model

RFC 5373: Requesting Answering Modes for the Session Initiation Protocol (SIP)

RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies

2009

RFC 5478: IANA Registration of new Session Initiation Protocol (SIP) Resource-Priority Namespaces

RFC 5509: Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for SIP

RFC 5552: SIP Interface to VoiceXML Media Services

RFC 5589: Session Initiation Protocol (SIP) Call Control – Transfer

RFC 5621: Message Body Handling in the Session Initiation Protocol (SIP)

RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)

RFC 5627: Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)

RFC 5628: Session Initiation Protocol (SIP) PUBLISH Extension for Request-Contained Resource Lists

RFC 5629: A Framework for Application Interaction in the Session Initiation Protocol (SIP)

RFC 5630: The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

RFC 5631: Session Initiation Protocol (SIP) Session Mobility

RFC 5658: Addressing Record-Route Issues in the Session Initiation Protocol (SIP)

2010

RFC 5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols – OBSOLETA, sostituita da RFC 8445

RFC 5688: A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes

RFC 5768: Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)

RFC 5839: An Extension to the Session Initiation Protocol (SIP) Events for Conditional Event Notification

RFC 5875: An XML Configuration Access Protocol (XCAP) Diff Event Package for SIP

RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)

RFC 5923: Connection Reuse in the Session Initiation Protocol (SIP)

RFC 5954: Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261

RFC 6035: Session Initiation Protocol (SIP) Event Package for Voice Quality Reporting

2011

RFC 6072: Certificate Management Service for the Session Initiation Protocol (SIP)

RFC 6076: Basic Telephony Session Initiation Protocol (SIP) End-to-End Performance Metrics

RFC 6080: A Framework for Session Initiation Protocol (SIP) User Agent Profile Delivery

RFC 6086: Session Initiation Protocol (SIP) INFO Method and Package Framework

RFC 6140: Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)

RFC 6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)

RFC 6157: IPv6 Transition in the Session Initiation Protocol (SIP)

RFC 6223: Indication of Support for Keep-Alive

RFC 6228: Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog

RFC 6230: Media Control Channel Framework

RFC 6442: Location Conveyance for the Session Initiation Protocol (SIP)

2012

RFC 6446: Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control

RFC 6447: Filtering Location Notifications in the Session Initiation Protocol (SIP)

RFC 6665: SIP-Specific Event Notification – nuova versione che rende obsoleta la RFC 3265

Una tabella pratica per non perdere di vista le RFC davvero centrali

RFC	Funzione principale	Perché è importante
3261	Core SIP	Definisce metodi, transazioni, dialoghi, routing e struttura generale del protocollo
3262	Provisional response affidabili	È essenziale per comprendere PRACK e la gestione corretta delle risposte provvisorie
3263	Localizzazione server SIP	Spiega come DNS, NAPTR, SRV e A/AAAA partecipano al routing SIP
3311	Metodo UPDATE	Importante per modificare parametri di sessione senza attendere la risposta finale
3325	Asserted Identity	Fondamentale nei trusted network e nei servizi carrier-grade
3326	Reason Header	Molto utile in analisi e troubleshooting dei BYE e dei CANCEL
3327	Path	Rilevante per registrazioni non adiacenti e architetture con proxy intermedi
3581	Symmetric Response Routing	Aiuta a comprendere molte logiche operative in presenza di NAT
3608	Service-Route	Importante per il routing post-registrazione e i servizi di rete
3891	Replaces	È una RFC chiave per comprendere transfer assistiti e logiche di sostituzione dialogo
3903	PUBLISH	È centrale nei sistemi presence e nei modelli di pubblicazione stato
4028	Session Timer	Molto importante per chiamate lunghe, refresh di sessione e scenari con NAT
5626	Client-initiated connections	Fondamentale per dispositivi dietro NAT e connessioni persistenti
5627	GRUU	Importante per identificare istanze specifiche di user agent
5922	Domain Certificates	Rilevante per sicurezza TLS e validazione dell’identità di dominio
5923	Connection Reuse	Molto utile per capire architetture con trunk TLS e riuso delle connessioni
6086	INFO framework	Rimette ordine nell’uso del metodo INFO e ne limita gli abusi applicativi
6141	re-INVITE e target-refresh	Chiarisce comportamenti spesso critici nelle modifiche di sessione
6665	Event notification aggiornata	Sostituisce la 3265 ed è il riferimento moderno per SUBSCRIBE/NOTIFY

Come leggere questo insieme di documenti senza perdersi

Davanti a un elenco così ampio, il rischio è quello di vedere solo una sequenza di numeri. In realtà, la chiave per orientarsi è ragionare per famiglie funzionali. Ci sono le RFC che definiscono la segnalazione e il routing di base. Ci sono quelle che regolano dialoghi e sessioni. Ci sono quelle dedicate a eventi, presenza e conferenze. Poi c’è il gruppo che riguarda identità, privacy e sicurezza, e infine tutto il blocco legato a NAT, connessioni persistenti, IPv6 e mobilità.

Da un punto di vista didattico, il consiglio è semplice: iniziare dal cuore del protocollo e solo dopo passare alle estensioni. Studiare bene la 3261 senza leggere almeno la 3262 e la 3263 significa lasciare fuori una parte troppo importante del funzionamento reale. Allo stesso modo, affrontare la presenza o le conferenze senza aver prima assimilato dialoghi, routing, Path, Service-Route, Session Timer o Replaces rischia di creare conoscenze frammentarie.

Il valore di questa mappa, quindi, non sta solo nella completezza. Sta soprattutto nel fatto che permette di costruire un percorso. E in un protocollo stratificato come SIP, avere un percorso è spesso la differenza tra una conoscenza mnemonica delle sigle e una vera comprensione tecnica del sistema.

Perché studiare ancora oggi le RFC SIP ha un valore concreto

Qualcuno potrebbe pensare che un articolo del genere appartenga soprattutto alla storia del VoIP. Io credo invece che sia esattamente il contrario. Più le piattaforme diventano astratte, cloud-based e integrate in ecosistemi sempre più complessi, più diventa preziosa la capacità di tornare ai fondamenti. E nel caso del SIP, i fondamenti sono scritti nelle RFC.

Chi progetta reti VoIP, analizza tracciati con Wireshark, lavora su SIP trunk multioperatore, mette in produzione SBC o integra sistemi PBX con servizi esterni continua a confrontarsi, in modo diretto o indiretto, con questi documenti. Le RFC restano il punto in cui il protocollo si spoglia delle interpretazioni commerciali e torna a essere ciò che è davvero: una grammatica tecnica condivisa. Per questo, ancora oggi, leggerle non è un esercizio da archivio. È una forma di competenza operativa.

Se vuoi completare davvero il quadro, è importante ricordare che il SIP rappresenta solo il piano di segnalazione. Tutto ciò che riguarda voce, qualità audio, DTMF e problemi di rete è regolato da altre RFC, legate al piano media. Ne ho parlato nel dettaglio in questo approfondimento dedicato al VoIP oltre il SIP.

Leggi l’articolo: VoIP oltre il SIP – le RFC fondamentali per media, RTP e NAT traversal

Fonti utili per approfondire

Per chi volesse approfondire gli argomenti trattati, ecco alcune fonti online utili:

RFC 3261 – SIP: Session Initiation Protocol

RFC 5411 – A Hitchhiker’s Guide to the Session Initiation Protocol (SIP)

RFC 6665 – SIP-Specific Event Notification

RFC 6086 – SIP INFO Method and Package Framework

Indice Packetizer/goffinet delle RFC SIP

RFC 3261 Capitolo 8: ACK, conferma finale della sessione

9, Giu 2026 | EVIDENZA, Guida alla RFC3261 - IL DNA DEL VOIP, VOIP E PROTOCOLLO SIP

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>”The ACK request confirms receipt of a final response to an INVITE request.” ”La richiesta ACK conferma la ricezione di una risposta finale a una richiesta INVITE.”</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.

I CONSIGLI DI VOIP.IT

Quando in un tracciato pcap vedi uno o più 200 OK ripetuti allo stesso INVITE, la prima domanda non è se il chiamato abbia risposto davvero. La prima domanda è: dove sta andando l’ACK? Controlla subito il Contact del 200 OK, il percorso di dialogo, gli eventuali header Record-Route e la presenza di NAT o riscritture. Poi fai un controllo in più: verifica se lungo il percorso ci sono firewall next generation con ispezione layer 7 o funzioni SIP ALG. Sono proprio questi meccanismi che, leggendo e manipolando la segnalazione SIP, possono alterare gli indirizzi contenuti nei messaggi, aprire o chiudere pinhole in modo non coerente o impedire la consegna corretta dell’ACK. In molte installazioni moderne, anche se nel Contact compare un IP privato, centrali e SBC possono gestirlo comunque tramite meccanismi come received, rport o riscritture lato server. Il problema quindi non è l’IP privato in sé, ma se il sistema riesce davvero a instradare l’ACK verso la destinazione corretta senza che un dispositivo intermedio lo alteri.

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

Collegare un AI Voice Agent al PBX: SIP trunk, WebSocket e integrazione AI

27, Mag 2026 | EVIDENZA, VOIP E PROTOCOLLO SIP

Collegare un AI Voice Agent al PBX aziendale: SIP trunk, WebSocket e ruolo del PBX

Gli AI Voice Agent stanno entrando rapidamente nelle architetture telefoniche aziendali. Fino a poco tempo fa il mondo VoIP sembrava abbastanza stabile: trunk SIP, PBX, codec, NAT, SBC e troubleshooting erano temi ormai consolidati. Oggi, invece, l’arrivo dell’intelligenza artificiale sta rimettendo tutto in movimento.

Negli ultimi mesi mi capita di vedere installatori e tecnici VoIP impegnati a integrare PBX e AI Voice Agent. i clienti iniziano a chiedere assistenti vocali, trascrizioni automatiche, instradamenti intelligenti e integrazioni realtime con modelli AI.

Ed è probabilmente anche questo uno degli aspetti più interessanti della fase che stiamo vivendo: RTP, SDP, codec, trunk SIP, realtime, interoperabilità e qualità audio stanno tornando improvvisamente al centro delle discussioni tecniche. Dopo anni in cui molte installazioni erano diventate quasi routine, il mondo AI sta riaprendo spazi enormi per progettazione, troubleshooting, sperimentazione e divulgazione tecnica.

Allo stesso tempo, però, vedo anche molta fretta. Molte criticità attribuite genericamente all’intelligenza artificiale nascono in realtà da aspetti molto più tradizionali: REGISTER non supportati, SDP incompatibili, gestione RTP errata, numerazioni E.164 non normalizzate oppure aspettative non realistiche sul comportamento SIP di un AI Agent.

È quindi importante chiarire subito un punto: un AI Voice Agent non è automaticamente un PBX e non è automaticamente un provider VoIP. Utilizza SIP, RTP, API, WebSocket e LLM, ma spesso con logiche diverse da quelle tipiche della mondo VoIP tradizionale.

Va però detto che questa distanza tra mondo SIP e piattaforme AI si sta riducendo rapidamente. I PBX iniziano a integrare funzioni realtime e WebSocket, alcuni provider stanno lavorando a trunk SIP più adatti agli scenari AI e le piattaforme vocali stanno migliorando velocemente il supporto alle logiche SIP tradizionali.

Per orientarsi meglio conviene quindi distinguere alcuni scenari tecnici ricorrenti: PBX con AI integrata, AI Voice Agent esterni collegati via trunk SIP, architetture SIP più WebSocket e integrazioni API verso sistemi aziendali e LLM.

Primo scenario: quando l’AI è integrata direttamente nel PBX

Il primo scenario da considerare è quello in cui le funzioni AI sono già integrate nel PBX. È una realtà sempre più frequente: alcune piattaforme PBX software stanno introducendo servizi di trascrizione, riassunto, analisi e automazione basati su intelligenza artificiale.

In questo scenario l’azienda non collega necessariamente il centralino a un AI Voice Agent esterno tramite un nuovo trunk SIP. È il PBX stesso che acquisisce l’audio della chiamata, della registrazione o della voicemail e lo invia a un motore AI per ottenere trascrizione, riassunto, analisi o supporto alla gestione della chiamata.

Il vantaggio principale è la semplicità operativa. Chi non ha grande esperienza di integrazione SIP, API, WebSocket o media gateway può attivare una funzione già prevista dal centralino. Il PBX conosce già gli interni, le code, i gruppi, gli utenti, le registrazioni, gli orari, le rotte e i permessi. Non deve “imparare” come funziona la telefonia aziendale, perché ne è già il punto di controllo.

Il flusso tipico può essere descritto così:

In molti casi il PBX non “contiene” realmente tutto il modello di intelligenza artificiale. Più spesso integra un connettore verso un servizio esterno. L’amministratore inserisce nel pannello del centralino una API key, cioè una chiave di accesso, e il PBX la usa per autenticarsi verso il motore AI. Da quel momento il centralino può inviare audio o testo a servizi esterni come OpenAI, Google Gemini, Anthropic Claude, Microsoft Azure OpenAI o altri modelli compatibili.

Questo approccio è diverso dal collegare un agente vocale esterno via SIP. Nel modello con AI integrata nel PBX, la chiamata resta governata dal centralino. L’intelligenza artificiale lavora come funzione aggiuntiva: trascrive una registrazione, produce un riassunto, identifica gli interlocutori, analizza il sentiment, prepara note per il CRM o supporta scenari di risposta automatica già previsti dal sistema.

Dal punto di vista tecnico, il PBX può elaborare l’audio in due modi. Nel primo caso lavora su una registrazione già conclusa: la chiamata viene registrata, il file audio viene inviato al motore di trascrizione e il risultato viene salvato nei report o nella scheda della chiamata. Nel secondo caso lavora su una chiamata live: l’audio viene gestito durante la conversazione e può contribuire a funzioni più avanzate, come assistenti vocali, routing intelligente o generazione di risposte in tempo reale.

La differenza è importante. La trascrizione post-chiamata tollera qualche secondo o minuto di elaborazione. Una funzione live, invece, deve rispettare tempi molto più stretti. Se il sistema deve rispondere al chiamante, riconoscere un’intenzione o instradare una chiamata mentre la conversazione è in corso, la latenza diventa un parametro critico.

Per chi installa PBX, questa strada può essere più semplice rispetto alla costruzione di un’integrazione esterna completa. Non è necessario progettare subito un trunk dedicato verso un agente AI, un media bridge RTP-WebSocket o un’orchestrazione applicativa complessa. Si parte da una funzione del PBX: trascrizione, riassunto, analisi o agente integrato.

Esiste però anche una situazione intermedia che sta diventando sempre più interessante. Alcuni PBX moderni non si limitano a usare servizi AI interni o a collegarsi a piattaforme AI tramite trunk SIP tradizionale. Possono anche integrare funzioni realtime basate su WebSocket, inviando direttamente flussi audio o eventi verso motori AI esterni.

In pratica il PBX continua a governare la telefonia, ma invece di trattare l’AI come un semplice trunk SIP può aprire una sessione WebSocket sicura verso un servizio AI esterno. Questo approccio permette di lavorare in modo più naturale con trascrizioni live, assistenti vocali realtime, suggerimenti all’operatore, analisi della conversazione durante la chiamata e interazioni a bassa latenza.

È importante capire che in questi scenari il SIP continua a esistere, ma cambia il punto in cui il media viene elaborato. La chiamata può arrivare normalmente al PBX tramite SIP e RTP, mentre il PBX stesso inoltra audio, eventi o trascrizioni verso il motore AI tramite WebSocket sicuro (WSS).

Questa architettura può essere più semplice da gestire rispetto a un AI Agent SIP completamente esterno, soprattutto quando l’obiettivo è aggiungere funzionalità AI al centralino senza modificare troppo il dialplan o la logica telefonica esistente. Allo stesso tempo richiede che il PBX supporti realmente streaming realtime, gestione media e integrazione WebSocket verso servizi AI compatibili.

Questo è uno dei segnali più interessanti della convergenza in corso. Il PBX non è più soltanto il punto di controllo della telefonia, ma può diventare anche il punto in cui la voce viene resa disponibile a servizi AI realtime, mantenendo però il governo di utenti, code, gruppi, orari, permessi e instradamenti.

Naturalmente questa semplicità ha anche dei limiti. Le funzioni integrate dipendono dalle scelte del produttore del PBX, dai modelli supportati, dalle licenze disponibili, dai costi di utilizzo del servizio AI, dalla posizione geografica in cui vengono trattati i dati e dalla possibilità di personalizzare realmente i flussi. Se l’azienda ha bisogno di un agente molto specializzato, collegato a più sistemi aziendali o indipendente dal PBX, una piattaforma AI esterna può rimanere più flessibile.

I CONSIGLI DI VOIP.IT

Per aziende che vogliono iniziare senza progettare subito un’integrazione complessa, le funzioni AI native del PBX possono essere un buon primo passo. Trascrizione, riassunti e analisi delle chiamate sono spesso più semplici da gestire quando il PBX controlla già registrazioni, utenti, code e permessi.

Prima di attivarle, però, verificate sempre dove viene inviato l’audio, quale motore AI viene utilizzato, quali chiavi API sono richieste, quanto costa l’elaborazione, quali dati vengono conservati e se il trattamento è compatibile con le policy privacy dell’azienda.

Questo è quindi il primo scenario: l’AI lavora come funzione del PBX. È un modello più semplice da governare, perché il centralino mantiene il controllo della chiamata e usa l’intelligenza artificiale come servizio aggiuntivo.

Non sempre, però, questa strada è sufficiente. Se l’azienda ha bisogno di un agente conversazionale più specializzato, di una piattaforma AI esterna, di integrazioni avanzate con sistemi aziendali o di un motore realtime basato su WebSocket, allora si passa a un secondo scenario: il PBX deve collegarsi a un AI Voice Agent esterno.

Ed è qui che torna centrale il mondo SIP. Ma attenzione: il trunk SIP verso un AI Voice Agent esterno non deve essere interpretato automaticamente come il trunk SIP di un provider VoIP tradizionale.

Secondo scenario: quando l’AI Agent è esterno

Nel mondo VoIP tradizionale siamo abituati a collegare un PBX a un provider tramite un trunk SIP. Il trunk può essere basato su registrazione oppure su relazione peer. Quando la destinazione è una piattaforma AI esterna, però, il comportamento atteso può essere diverso.

Nel modello REGISTER il PBX invia periodicamente un messaggio SIP REGISTER al server del provider. In questo modo comunica la propria posizione di rete e si autentica con credenziali, normalmente tramite autenticazione Digest. È il modello più comune nelle installazioni SMB italiane, perché funziona bene anche in presenza di connettività non dedicata, IP dinamici o centralini dietro NAT, purché la configurazione di rete sia corretta.

Nel modello Peer Trunk, invece, non c’è necessariamente una registrazione SIP. I due endpoint si riconoscono tramite indirizzo IP, dominio, ACL, credenziali applicate all’INVITE oppure una combinazione di questi elementi. Questo modello è frequente nelle interconnessioni tra carrier, nei collegamenti tra PBX e SBC, oppure nei trunk professionali con indirizzamento statico.

Spesso il problema non è l’account SIP o il provider: dal tracciato emerge semplicemente che il REGISTER non è supportato oppure che la piattaforma AI lavora esclusivamente come peer trunk.

È importante ricordare che questo scenario sta evolvendo rapidamente. Alcune piattaforme AI stanno già ampliando il supporto SIP e non è affatto escluso che nei prossimi mesi vedremo implementazioni più complete del metodo REGISTER, della gestione delle autenticazioni e delle logiche RFC tradizionali.

Molti AI Voice Agent lavorano più spesso nel secondo modo. Non supportano il metodo REGISTER, non mantengono una registrazione persistente del PBX e non si comportano come un classico server SIP di accesso. Espongono invece una terminazione SIP verso cui il PBX deve inviare la chiamata, spesso tramite un dominio dedicato, un URI SIP specifico oppure un set di IP autorizzati.

Questo aspetto cambia immediatamente il progetto. Se il PBX è stato pensato solo per trunk REGISTER, l’integrazione può diventare più delicata. Potrebbe essere necessario configurare una rotta SIP statica, forzare il dominio di destinazione nel Request-URI, controllare il Contact, gestire correttamente il From e verificare se la piattaforma AI richiede autenticazione sull’INVITE oppure whitelist IP.

Perché è sconsigliabile collegare direttamente il trunk SIP del provider all’AI Agent

In alcuni scenari viene proposta una scorciatoia apparentemente semplice: collegare il trunk SIP del provider direttamente all’AI Voice Agent, evitando il PBX. In teoria la chiamata arriva dal provider e viene consegnata direttamente alla piattaforma AI. In pratica, questa architettura è spesso sconsigliabile.

Vedo spesso tentativi di collegare direttamente il trunk del provider all’agente AI perché sembra la strada più veloce. In pratica è anche quella che genera più incompatibilità, più troubleshooting e più difficoltà nel capire dove finisca il problema SIP e dove inizi invece il comportamento applicativo della piattaforma AI.

Il primo motivo è la sicurezza. Il trunk del provider è il punto di ingresso e uscita verso la rete telefonica pubblica. Collegarlo direttamente a una piattaforma AI significa rinunciare a una parte importante delle policy normalmente gestite dal PBX o dall’SBC: controllo delle rotte, limitazione delle destinazioni, validazione del Caller ID, regole antifrode, fasce orarie, deviazioni controllate, log centralizzati e separazione tra rete telefonica e applicazioni cloud.

Il secondo motivo è la compatibilità SIP. Un provider VoIP nazionale ragiona come un’infrastruttura telefonica. Si aspetta dall’altra parte un PBX, un SBC o comunque un apparato capace di interpretare correttamente una gamma ampia di comportamenti SIP: risposte provvisorie, re-INVITE, session timer, DTMF, trasferimenti, early media, privacy, P-Asserted-Identity, Diversion, gestione dei codici di errore e continuità del dialogo SIP.

Un AI Voice Agent, invece, spesso non interpreta il protocollo SIP con la stessa completezza di un PBX o di un provider. Tende a implementare un sottoinsieme funzionale, orientato soprattutto ad accettare una chiamata, aprire un media stream e consegnare l’audio al motore AI. Questo è sufficiente per molti casi d’uso, ma può diventare fragile quando la chiamata arriva direttamente da un provider con logiche carrier-grade.

Il terzo motivo è l’operatività. Se la chiamata entra direttamente nell’AI Agent, diventa più difficile applicare logiche telefoniche aziendali. Pensiamo agli orari di apertura, alle code, al fallback verso operatori umani, alla registrazione centralizzata, al CDR, alla reportistica, al routing per reparti, al disaster recovery o alla possibilità di escludere temporaneamente l’agente AI senza modificare la configurazione del provider.

La soluzione più ordinata è quasi sempre mantenere il PBX come punto di governo della telefonia aziendale. Il provider nazionale resta collegato al PBX tramite il trunk SIP principale. Il PBX decide quando e come inviare una chiamata all’agente vocale AI attraverso un secondo trunk dedicato, preferibilmente di tipo peer, protetto da ACL e con regole di routing molto precise.

In scenari più complessi, soprattutto quando sono coinvolti più provider, contact center, numerazioni pubbliche, flussi inbound/outbound o requisiti di sicurezza elevati, è ancora meglio inserire un SBC. L’SBC può stare tra provider e PBX, tra PBX e AI Agent, oppure in entrambi i punti, a seconda dell’architettura.

I CONSIGLI DI VOIP.IT

Evitate, salvo casi molto controllati, il collegamento diretto tra trunk SIP del provider e AI Agent. È preferibile usare il PBX come elemento di governo: un trunk verso il provider nazionale e un trunk separato verso l’agente vocale. In questo modo il PBX mantiene il controllo su dialplan, sicurezza, fallback, code, trasferimenti, CDR e gestione operativa.

Quando l’ambiente è più complesso, l’SBC diventa il punto ideale per separare la rete telefonica aziendale dalla piattaforma AI, normalizzare SIP/SDP e applicare policy di sicurezza più robuste.

Il SIP dell’AI Agent è spesso un SIP essenziale

SIP, secondo la definizione dello standard, è un protocollo di segnalazione usato per creare, modificare e terminare sessioni multimediali. In una telefonata VoIP, SIP non trasporta la voce: si occupa della segnalazione. La descrizione della sessione viene inserita tramite SDP e il flusso audio viaggia poi in RTP.

Un provider VoIP professionale implementa una quantità elevata di funzionalità SIP. Deve gestire autenticazione, routing, interoperabilità PSTN, risposte provvisorie, early media, failover, trasferimenti, deviazioni, privacy del chiamante, gestione dei codec, fax, sicurezza e compatibilità con centralini molto diversi.

Un AI Voice Agent ha un obiettivo differente. Deve soprattutto ricevere una chiamata, ottenere un flusso audio stabile, convertirlo in testo, inviarlo a un motore AI e restituire una risposta vocale. Per questo motivo molte piattaforme AI implementano solo il sottoinsieme SIP necessario a instaurare e mantenere la sessione audio.

In genere possiamo aspettarci un supporto corretto dei metodi fondamentali come INVITE, ACK, BYE e CANCEL. Non sempre, invece, troviamo una gestione completa di PRACK, UPDATE, REFER, Re-INVITE complessi, Session Timer, Diversion, History-Info, T.38 o scenari avanzati di early media.

Questo non significa necessariamente che la piattaforma sia progettata male. Significa che non nasce per sostituire un operatore telefonico. Nasce per accedere all’audio della conversazione e collegarlo a un motore di elaborazione linguistica.

Il punto critico: capire dove termina il VoIP e dove inizia l’AI

In una normale chiamata SIP tra PBX e provider, il troubleshooting si concentra su segnalazione SIP, SDP, RTP, NAT, codec, DTMF e routing. Con un AI Voice Agent questi elementi rimangono fondamentali, ma non sono più sufficienti.

Una chiamata può essere tecnicamente perfetta dal punto di vista SIP e comunque produrre una pessima esperienza utente. Il PBX può inviare l’INVITE corretto, ricevere il 200 OK, aprire RTP in modo bidirezionale e non avere alcun packet loss. Tuttavia l’agente può rispondere in ritardo, interrompere male l’interlocutore, non riconoscere una frase o generare una risposta incoerente.

In quel caso il problema non è necessariamente SIP. Può essere nel motore Speech-To-Text, nella latenza del modello LLM, nel Text-To-Speech, nella connessione WebSocket, in un sistema gestionale lento o in una logica conversazionale non ottimizzata.

Piano tecnico	Responsabilità principale	Problemi tipici
SIP / SDP	Instaurazione, modifica e chiusura della chiamata	401, 403, 404, 488, Request-URI errato, codec non accettato
RTP / DTMF / NAT	Trasporto audio e toni	audio monodirezionale, jitter, packet loss, DTMF non riconosciuti
AI / WebSocket / livello applicativo	Trascrizione, ragionamento, risposta vocale e accesso ai dati	latenza, timeout, risposta errata, barge-in non naturale

Il formato E.164: un dettaglio che diventa spesso bloccante

Molte piattaforme AI internazionali richiedono numerazioni in formato E.164. In pratica si aspettano numeri con prefisso internazionale completo, ad esempio +390212345678 per una numerazione fissa italiana.

Questo requisito è naturale per piattaforme cloud globali, ma non è sempre compatibile con le abitudini dei PBX italiani. Molti centralini continuano a lavorare con dialplan storici, prefissi di uscita, numerazioni brevi, formati nazionali senza +39 oppure Caller ID presentati in modo differente a seconda della rotta utilizzata.

Il problema non riguarda solo il numero chiamato. In un INVITE verso un AI Voice Agent possono essere analizzati più campi: Request-URI, To, From, Contact, P-Asserted-Identity, Diversion e, in alcuni casi, anche header proprietari usati dalla piattaforma per associare la chiamata a un tenant o a un agente specifico.

In Italia occorre inoltre prestare attenzione ai numeri geografici. Nel formato internazionale italiano il prefisso geografico mantiene lo zero. Un numero di Milano, quindi, non diventa +392…, ma rimane nel formato +3902…. Questo dettaglio viene spesso gestito male da dialplan importati da logiche internazionali dove lo zero iniziale è considerato solo un trunk prefix da rimuovere.

La normalizzazione E.164 deve quindi essere applicata con precisione. Non basta aggiungere +39 davanti a qualunque numero. Occorre distinguere numeri geografici, mobili, numerazioni verdi, numerazioni speciali, interni, codici brevi e numerazioni aziendali presentate come CLI.

Molte piattaforme AI nascono pensando a mercati dove E.164 è già utilizzato in modo rigoroso. Con la crescita delle integrazioni nel mondo PBX europeo e italiano, il supporto completo alle numerazioni normalizzate sta diventando sempre più importante.

Un esempio pratico di normalizzazione SIP

Immaginiamo un PBX italiano che deve inviare una chiamata a un AI Agent con Caller ID aziendale 0212345678. Se il PBX invia il campo From come:

From: "Azienda" <sip:0212345678@pbx.local>

la piattaforma AI potrebbe non riconoscere correttamente il chiamante o rifiutare la chiamata se pretende un’identità internazionale valida. Una normalizzazione più adatta potrebbe essere:

From: "Azienda" <sip:+390212345678@sip.ai-platform.example>
P-Asserted-Identity: <sip:+390212345678@sip.ai-platform.example>

Il punto non è solo estetico. Alcune piattaforme usano il numero chiamante per associare la sessione a un account, a una campagna, a una policy di sicurezza o a un flusso conversazionale. Un formato incoerente può generare problemi che sembrano SIP ma in realtà sono problemi di identificazione applicativa.

Codec: G.711 rimane spesso la scelta più sicura

Nel collegamento tra PBX e AI Agent è consigliabile partire da una configurazione codec molto conservativa. In molti casi il codec più affidabile rimane G.711 A-law per il mercato italiano, con pacchettizzazione a 20 ms e DTMF in RTP secondo RFC 4733.

Il motivo è semplice. Molti motori STT lavorano internamente con audio PCM lineare o formati derivati. Se la piattaforma AI riceve G.711, può convertirlo in un formato adatto al riconoscimento vocale con una catena relativamente semplice. Codec compressi come G.729 possono ridurre la banda, ma introducono compressione e peggiorano la qualità del segnale in ingresso al motore di trascrizione.

Il codec Opus può essere molto interessante in scenari WebRTC o in architetture native realtime, ma non è sempre disponibile nei PBX tradizionali o nei trunk SIP verso piattaforme AI. Per questo, nella maggior parte delle integrazioni PBX-SIP, G.711A rappresenta ancora una scelta prudente.

La banda va comunque dimensionata in modo realistico. Una chiamata G.711 non pesa solo 64 kbit/s di payload audio. Considerando overhead IP, UDP, RTP e livello di accesso, è corretto stimare circa 80-100 kbit/s per direzione, soprattutto quando si dimensionano più chiamate contemporanee.

DTMF: verificare sempre cosa supporta davvero l’AI Agent

Un altro punto da verificare con attenzione riguarda i DTMF, cioè i toni generati dalla tastiera telefonica. Nel VoIP tradizionale i metodi principali sono stati storicamente tre: toni in audio, eventi RTP secondo RFC 2833/RFC 4733 e SIP INFO.

Nelle integrazioni moderne, però, non conviene più dare per scontato SIP INFO. In molti scenari il riferimento pratico resta il trasporto degli eventi DTMF nel flusso RTP, cioè il classico telephone-event negoziato nell’SDP. È il metodo più coerente con molte architetture SIP/RTP e riduce il rischio di separare troppo la segnalazione telefonica dal media.

m=audio 20000 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Con gli AI Voice Agent bisogna però fare un ragionamento in più. Alcune piattaforme non espongono il DTMF come farebbe un PBX tradizionale, ma lo gestiscono come funzione applicativa dell’agente oppure come evento interno generato durante la chiamata.

Per questo motivo la domanda corretta non è soltanto “supporta i DTMF?”, ma come li supporta: tramite RTP telephone-event, come tono audio, come evento applicativo oppure attraverso funzioni interne della piattaforma AI.

Nei test reali conviene quindi verificare sempre tre aspetti: la negoziazione SDP del payload telephone-event, l’effettiva ricezione dei toni durante la chiamata e il modo in cui l’AI Agent li interpreta o li genera. Questo è particolarmente importante negli scenari IVR ibridi, nei trasferimenti o quando l’agente AI deve interagire con sistemi telefonici esterni.

SIP + WebSocket: il ponte verso l’AI realtime

Il modello più interessante nelle piattaforme moderne è SIP con in aggiunta WebSocket. Qui è importante chiarire bene il concetto.

WebSocket è una connessione bidirezionale persistente sopra TCP. A differenza del modello HTTP classico, dove il client invia una richiesta e riceve una risposta, con WebSocket la connessione rimane aperta e client e server possono scambiarsi dati in entrambe le direzioni per tutta la durata della sessione.

Questo comportamento è molto utile per le applicazioni vocali realtime. L’audio può essere inviato in piccoli blocchi continui, la trascrizione può arrivare progressivamente, il motore AI può restituire eventi e risposte parziali, e l’applicazione può gestire interruzioni, silenzi, barge-in e cambio di stato durante la chiamata.

In una tipica architettura PBX-AI, il PBX non parla direttamente WebSocket. Il PBX continua a parlare SIP e RTP. È la piattaforma AI, oppure un media gateway intermedio, che riceve RTP e lo converte in un flusso WebSocket verso il motore AI realtime.

PBX e piattaforme AI stanno rapidamente convergendo: i primi imparano a lavorare con realtime e WebSocket, mentre le piattaforme AI migliorano rapidamente il supporto SIP tradizionale.

Questo modello è molto diverso da una richiesta applicativa tradizionale, nella quale un sistema chiede un’informazione e attende una risposta. Il WebSocket è più adatto allo streaming realtime: audio che entra, audio che esce, eventi di trascrizione, segnali di interruzione, marcatori temporali e stato della conversazione.

Attenzione a non fare confusione

Nel mondo VoIP esiste anche il concetto di SIP over WebSocket. È un uso diverso del WebSocket, standardizzato per trasportare messaggi SIP su una connessione WebSocket, molto comune nei softphone web e negli scenari WebRTC. Quando parliamo di AI Voice Agent, però, spesso non stiamo parlando di SIP over WebSocket. Stiamo parlando di un media bridge che prende l’audio RTP di una telefonata SIP e lo inoltra a un motore AI tramite WebSocket. Nel primo caso WebSocket è un trasporto per SIP. Nel secondo caso WebSocket è il canale applicativo e media verso l’intelligenza artificiale.

Come lavora una chiamata AI realtime

In questo tipo di architettura la voce del chiamante non viene elaborata direttamente dal modello linguistico. Prima deve attraversare alcuni passaggi fondamentali.

Il flusso audio RTP proveniente dal PBX viene normalmente inviato a un motore STT (Speech To Text), cioè un sistema che trasforma la voce in testo. A quel punto il contenuto testuale può essere elaborato dal modello linguistico AI, che genera la risposta.

La risposta testuale viene poi inviata a un motore TTS (Text To Speech), che riconverte il testo in audio sintetizzato da reinviare nella chiamata SIP.

Questi passaggi oggi avvengono spesso in realtime, ma introducono inevitabilmente nuove variabili rispetto al VoIP tradizionale: latenza, tempi di elaborazione, qualità della trascrizione, velocità del motore TTS e sincronizzazione tra audio e logica conversazionale.

Una chiamata AI realtime può essere descritta in questo modo. Il chiamante arriva sul PBX oppure su un provider SIP. Il PBX instrada la chiamata verso un trunk AI. La piattaforma AI accetta l’INVITE, negozia codec e porte RTP tramite SDP, e inizia a ricevere audio.

Da quel momento l’audio viene suddiviso in piccoli frame e inviato al motore STT o direttamente a un modello realtime multimodale. Il motore produce trascrizioni parziali o finali. Il modello LLM genera una risposta. Il motore TTS produce audio. La piattaforma reinietta l’audio nella chiamata RTP verso il PBX.

Il ciclo deve essere estremamente rapido. La latenza percepita dall’utente non è data solo dal ping verso il provider SIP. È la somma di più tempi: trasporto RTP, buffering, conversione audio, riconoscimento vocale, elaborazione LLM, generazione TTS e ritorno audio.

Per questo motivo una piattaforma AI vocale deve essere valutata non solo sulla compatibilità SIP, ma anche sui tempi di risposta end-to-end. Una conversazione naturale richiede che il sistema inizi a rispondere in tempi molto contenuti e che sappia gestire le interruzioni dell’utente.

Knowledge base interna e RAG: due approcci diversi per aiutare l’agente AI a rispondere

Non tutti gli AI Voice Agent recuperano le informazioni nello stesso modo. Alcuni utilizzano una knowledge base interna, cioè una raccolta già organizzata di FAQ, procedure, documentazione o risposte standard precaricate nella piattaforma.

In questo scenario l’agente consulta direttamente contenuti già disponibili, riducendo la latenza e mantenendo la conversazione più fluida. Questa tipologia di applicazione è funzionale per picole realtà e quando la mole di dati sulla quale eseguire la ricerca è limitata a pochi documenti statici

Altri sistemi utilizzano invece un modello RAG (Retrieval-Augmented Generation). In pratica l’agente cerca informazioni pertinenti in documenti, CRM, database o archivi aziendali e passa poi quel contesto al modello linguistico, che genera la risposta.

Il vantaggio del RAG è la possibilità di utilizzare dati aggiornati e documentazione reale aziendale. Lo svantaggio è che tutto deve avvenire abbastanza velocemente da non introdurre ritardi percepibili durante la conversazione.

I CONSIGLI DI VOIP.IT

Quando valutate un AI Voice Agent, chiedete sempre come recupera le informazioni: knowledge base interna, RAG oppure entrambe le soluzioni. Nel realtime telefonico anche pochi secondi di ritardo possono peggiorare sensibilmente l’esperienza utente.

Barge-in, silenzio e interruzioni: aspetti non tipici del trunk SIP classico

Nel VoIP tradizionale siamo abituati a considerare una chiamata come un flusso bidirezionale continuo. Con gli AI Agent entra in gioco un comportamento più complesso: l’utente può interrompere l’agente mentre sta parlando, cambiare argomento, sovrapporsi alla voce sintetica o restare in silenzio.

Il barge-in è la capacità del sistema di interrompere la riproduzione della voce AI quando il chiamante ricomincia a parlare. Tecnicamente richiede rilevamento vocale, gestione del buffer TTS, cancellazione o interruzione dell’audio già preparato e aggiornamento dello stato conversazionale.

Questi aspetti non vengono risolti dal SIP. SIP mantiene la chiamata. RTP trasporta l’audio. Ma la gestione dell’interruzione è una funzione applicativa della piattaforma AI, spesso coordinata tramite eventi WebSocket.

Leggere i tracciati è fondamentale per capire il comportamento dell’AI Agent

Molti problemi attribuiti genericamente all’AI nascono in realtà nei primi messaggi SIP o nella negoziazione SDP. È uno dei motivi per cui la lettura dei tracciati continua a essere fondamentale anche nelle integrazioni AI più moderne.

Con gli AI Voice Agent diventa ancora più importante saper leggere i tracciati SIP/RTP. Non basta verificare che la chiamata “passi”. Bisogna capire come l’agente interpreta davvero il dialogo SIP e dove termina la sua competenza telefonica.

Questo è particolarmente vero se si collega direttamente un provider SIP a un AI Agent. Un AI Agent, nella maggior parte dei casi, non ragiona come un PBX e non ragiona come un provider VoIP. Non è progettato per interpretare tutte le sfumature del protocollo SIP con la stessa profondità di un B2BUA, di un SBC o di una piattaforma carrier-grade.

Il suo comportamento è spesso orientato alla gestione minima della chiamata: accettare l’INVITE, negoziare un codec, ricevere RTP, inviare audio di risposta e chiudere la sessione. Quando entrano in gioco scenari più complessi, come early media, PRACK, re-INVITE, UPDATE, REFER, Session Timer, Diversion, History-Info, DTMF non standard o header SIP non canonici, la piattaforma può ignorare alcuni elementi, interpretarli in modo semplificato oppure rifiutare la chiamata.

Per questo il tracciato non serve solo a “trovare l’errore”. Serve a capire il profilo SIP reale dell’agente AI che stiamo utilizzando.

Un buon tracciato dovrebbe permettere di osservare almeno questi aspetti: Request-URI effettivo, dominio di destinazione, From, To, Contact, P-Asserted-Identity, codec offerti e accettati, payload DTMF, indirizzi e porte RTP annunciate nell’SDP, eventuali 401 o 407, codici di errore, BYE di chiusura e motivo della terminazione.

Nel caso degli agenti AI bisogna poi correlare il tracciato SIP con i log applicativi della piattaforma. Il Call-ID SIP dovrebbe idealmente essere collegato all’identificativo della sessione AI, al transcript, ai tempi STT, alla risposta del modello, al TTS e agli eventi WebSocket.

Solo così possiamo distinguere tre casi molto diversi: problema SIP, problema media RTP o problema AI/applicativo. Senza questa distinzione si rischia di attribuire al provider un problema di latenza del modello, oppure di attribuire all’AI un problema di audio monodirezionale generato dal NAT.

I CONSIGLI DI VOIP.IT

Quando testate un AI Voice Agent, salvate sempre almeno un tracciato SIP/RTP completo e confrontatelo con i log della piattaforma AI. Il solo messaggio “la chiamata è fallita” non basta. Occorre sapere se l’errore nasce nella segnalazione SIP, nel media RTP, nella normalizzazione delle numerazioni, nel DTMF, nella WebSocket session o nella risposta del modello linguistico.

In particolare, se state collegando direttamente un provider SIP a un AI Agent, ricordate che l’agente potrebbe non interpretare il protocollo con la completezza di un PBX o di un provider VoIP. La lettura del tracciato è il modo più concreto per verificare cosa supporta davvero.

Architetture consigliate

La soluzione più semplice, quando disponibile, è usare le funzioni AI già integrate nel PBX. In questo caso non si aggiunge subito un nuovo trunk verso una piattaforma esterna: il centralino continua a gestire le chiamate e usa l’AI come servizio interno o connesso tramite chiave API. È una strada adatta per iniziare con trascrizioni, riassunti, analisi delle conversazioni e funzioni di supporto alla gestione delle chiamate.

La seconda soluzione è collegare il PBX al trunk SIP dell’AI Agent. Può funzionare in ambienti piccoli, con PBX moderno, IP statico, dialplan semplice e piattaforma AI ben documentata. È però uno scenario che richiede maggiore attenzione su sicurezza, compatibilità SIP, codec, DTMF, NAT e gestione del fallback.

Lo scenario più robusto prevede che il provider nazionale termini sul PBX, mentre l’AI Agent venga raggiunto con un trunk separato. Il PBX continua a governare la telefonia aziendale e l’agente AI diventa una destinazione applicativa specializzata, non il sostituto del centralino.

Quando l’infrastruttura cresce, l’inserimento di un SBC permette di separare i domini di responsabilità. Il provider parla con l’SBC o con il PBX secondo regole telefoniche consolidate. L’AI Agent riceve soltanto il traffico che il PBX decide di inviargli, già normalizzato, filtrato e coerente con i suoi requisiti.

Lo scenario più evoluto è quello con media gateway SIP-RTP verso WebSocket. In questo modello il PBX non vede direttamente il motore AI realtime. Il gateway riceve la chiamata SIP, gestisce RTP, converte l’audio e mantiene una sessione WebSocket verso il modello AI o verso una piattaforma di orchestrazione.

Questo approccio è più complesso, ma offre maggiore controllo su latenza, barge-in, logging, integrazione con sistemi esterni e gestione degli eventi applicativi.

Dove posizionare l’SBC

In un progetto professionale, l’SBC diventa spesso il punto più importante dell’architettura. Non serve solo per “mettere in sicurezza il SIP”. Serve per adattare un mondo telefonico tradizionale a una piattaforma cloud con requisiti molto specifici.

L’SBC può normalizzare numerazioni, riscrivere header, applicare policy sul Caller ID, forzare codec, controllare SDP, gestire NAT traversal, limitare gli IP autorizzati, terminare TLS, applicare SRTP, inviare OPTIONS di keep-alive e proteggere il PBX da traffico non previsto.

In molti casi è preferibile non esporre direttamente il PBX verso la piattaforma AI, soprattutto se il centralino è on-premise, datato o già collegato a più provider. L’SBC diventa il punto di separazione tra rete telefonica aziendale e servizi AI cloud.

I CONSIGLI DI VOIP.IT

Quando l’AI Agent richiede formato E.164 rigido, IP statici, TLS/SRTP o codec specifici, è consigliabile inserire un SBC tra PBX e piattaforma AI. Questo evita di modificare pesantemente il dialplan del centralino e permette di gestire in un unico punto sicurezza, normalizzazione e interoperabilità.

NAT e RTP: i problemi storici del VoIP diventano ancora più evidenti

L’AI non elimina i problemi classici del VoIP. Li rende più visibili. Un motore di trascrizione vocale lavora bene solo se riceve audio pulito, continuo e con bassa latenza. Packet loss, jitter elevato, audio monodirezionale o clipping iniziale della frase possono peggiorare sensibilmente la qualità del riconoscimento.

Le verifiche NAT rimangono quindi fondamentali. Bisogna controllare che l’SDP non annunci indirizzi privati verso la piattaforma cloud, che le porte RTP siano realmente raggiungibili, che eventuali SIP ALG siano disattivati, che il firewall non riscriva in modo imprevedibile le porte e che le ACL non blocchino IP secondari utilizzati dalla piattaforma AI.

Il parametro rport, l’utilizzo di RTP simmetrico e un corretto static port mapping possono aiutare in molti scenari, ma non devono essere considerati una soluzione universale. In presenza di NAT simmetrici o firewall molto restrittivi, l’SBC resta spesso la scelta più stabile.

Autenticazione: IP ACL, Digest e URI dedicati

Molti servizi cloud SIP supportano più modalità di autenticazione. Le più comuni sono IP ACL e Credential/Digest Authentication.

L’autenticazione basata su IP è semplice, ma richiede attenzione. Funziona bene quando il PBX o l’SBC hanno IP pubblico statico e quando la piattaforma AI fornisce un dominio o un URI di terminazione univoco per il cliente. In ambienti cloud condivisi, l’autenticazione solo IP può diventare ambigua se più clienti usano lo stesso endpoint SIP.

La Digest Authentication sull’INVITE è più simile a quanto conosciamo nei trunk SIP tradizionali, ma non deve essere confusa con il REGISTER. Una piattaforma può non accettare REGISTER e richiedere comunque credenziali durante l’invio dell’INVITE.

Modalità	Comportamento	Attenzione tecnica
REGISTER	Il PBX si registra periodicamente	Non sempre supportato dagli AI Agent
Peer IP	Il traffico è accettato da IP autorizzati	Richiede IP statici, ACL precise e spesso URI dedicati
Digest su INVITE	L’INVITE viene sfidato con 401/407 e reinviato con credenziali	Non implica necessariamente supporto REGISTER

Trasferimento verso operatore: REFER, re-instradamento o controllo applicativo?

Un AI Voice Agent non deve quasi mai essere progettato come un vicolo cieco. Deve poter trasferire la chiamata a un operatore umano quando non comprende la richiesta, quando il cliente lo chiede esplicitamente o quando la procedura richiede un’escalation.

Il trasferimento può avvenire in modi diversi. Il metodo più telefonico è il SIP REFER, dove l’AI Agent chiede al sistema remoto di trasferire la chiamata verso una nuova destinazione. Non tutte le piattaforme AI lo supportano in modo completo e non tutti i provider lo accettano senza configurazione specifica.

Un secondo modello è il re-instradamento lato PBX o SBC. L’AI Agent chiude o mette in attesa la sessione e il PBX gestisce una nuova rotta verso il gruppo operatori.

Un terzo modello è applicativo: l’agente invia una richiesta alla piattaforma di contact center e chiede il passaggio della chiamata a una coda. In questo caso il trasferimento non è solo SIP, ma dipende dall’orchestrazione della piattaforma.

Prima di mettere in produzione un AI Agent è quindi fondamentale testare l’handoff verso operatore, non solo la risposta automatica iniziale.

Diagnostica: il solo PCAP non basta più

Per analizzare un’integrazione AI Voice Agent servono almeno due fonti di verità: la traccia SIP/RTP e i log applicativi della piattaforma AI.

Il PCAP rimane indispensabile per verificare INVITE, risposte SIP, SDP, porte RTP, codec, DTMF e qualità del flusso. Ma non mostra cosa accade dentro il motore AI. Non mostra il tempo di trascrizione, la latenza del modello LLM, i timeout dei sistemi esterni, gli eventi WebSocket o i ritardi del TTS.

Un buon troubleshooting deve correlare il Call-ID SIP con l’identificativo sessione della piattaforma AI. Idealmente bisogna misurare alcuni timestamp: arrivo dell’INVITE, 200 OK, primo pacchetto RTP, inizio parlato utente, fine parlato utente, trascrizione disponibile, prima risposta del modello, primo audio TTS inviato verso la chiamata.

Solo così possiamo capire se il ritardo percepito è causato dal VoIP, dal cloud AI o da un sistema aziendale esterno.

I CONSIGLI DI VOIP.IT

Durante i test non limitatevi alla classica domanda “la chiamata passa?”. Preparate uno scenario di collaudo con chiamata entrante, DTMF, trasferimento a operatore, silenzio prolungato, interruzione dell’agente mentre parla e accesso a un sistema gestionale lento. Sono questi casi a far emergere le criticità reali.

Sicurezza: non esporre il PBX come se fosse un servizio web

Un’integrazione AI Voice Agent espone spesso il PBX o l’SBC verso servizi cloud esterni. Questo richiede un approccio molto rigoroso alla sicurezza.

Non è consigliabile aprire genericamente la porta 5060 verso Internet. È preferibile lavorare con IP ACL, trasporto TLS quando supportato, SRTP per il media, credenziali robuste, limitazione delle rotte abilitate, blocco delle destinazioni internazionali non necessarie e monitoraggio delle chiamate anomale.

Lo stesso principio vale per le integrazioni con sistemi esterni. L’AI Agent deve poter fare solo ciò che serve realmente: leggere un ordine, aprire un ticket, prenotare uno slot o trasferire una chiamata. Non deve avere accesso indiscriminato a tutto il gestionale aziendale.

Un altro tema importante è la protezione dei dati personali. Le conversazioni vocali possono contenere dati sensibili, informazioni commerciali, dati identificativi e contenuti registrati. Prima della produzione occorre valutare regione di trattamento, conservazione dei log, registrazioni, trascrizioni, accessi amministrativi e policy GDPR.

API e AI Voice Agent: cosa fanno davvero nelle integrazioni vocali

Nel mondo VoIP siamo abituati a pensare al SIP come al protocollo che gestisce la chiamata. Ed è corretto: SIP crea, modifica e chiude la sessione telefonica, mentre RTP trasporta l’audio.

Nelle integrazioni AI moderne, però, questo non basta più. L’agente vocale deve anche poter accedere a dati esterni, eseguire azioni, interrogare sistemi aziendali e orchestrare il comportamento della conversazione. È qui che entrano in gioco le API.

Un’API, in modo semplificato, è un’interfaccia che permette a due applicazioni di scambiarsi dati o richieste operative. Nel contesto degli AI Voice Agent, le API non trasportano la chiamata SIP, ma permettono all’agente di interagire con servizi esterni durante la conversazione.

Per esempio, durante una chiamata l’agente AI potrebbe:

leggere informazioni da un CRM;
aprire un ticket di assistenza;
verificare lo stato di un ordine;
prenotare un appuntamento;
interrogare un database aziendale;
richiedere una risposta a un modello linguistico esterno.

È importante distinguere chiaramente i ruoli:

SIP gestisce la sessione telefonica;
RTP trasporta l’audio;
WebSocket può trasportare audio realtime ed eventi conversazionali;
API permettono all’agente AI di accedere a dati e funzioni esterne.

In molte piattaforme moderne le API diventano parte integrante della logica conversazionale. L’agente non si limita a “parlare”, ma prende decisioni in base ai dati ottenuti durante la chiamata.

Per esempio:

se il CRM segnala un cliente premium, la chiamata può essere trasferita direttamente a un reparto dedicato;
se un ordine risulta spedito, l’agente può comunicarne automaticamente lo stato;
se il gestionale non restituisce dati validi, l’agente può chiedere ulteriori informazioni al chiamante oppure passare la chiamata a un operatore umano.

Questo è uno dei punti più importanti da comprendere: in molte architetture moderne l’intelligenza dell’agente non dipende solo dal modello linguistico, ma dall’orchestrazione tra SIP, audio realtime, API aziendali e logica applicativa.

Per questo motivo il troubleshooting non può più limitarsi al solo tracciato SIP. Una chiamata può essere perfetta dal punto di vista RTP e SIP, ma diventare inutilizzabile a causa di timeout API, risposte lente del CRM, errori di autenticazione o logiche applicative errate.

Il consiglio per installatori VoIP e tecnici

Negli ultimi mesi sempre più tecnici VoIP si stanno avvicinando al mondo degli AI Voice Agent. È un passaggio naturale: telefonia e intelligenza artificiale stanno convergendo rapidamente.

Allo stesso tempo, però, continuo a vedere quanto sia importante non perdere le basi. Molti problemi attribuiti genericamente all’AI nascono ancora da SDP errati, RTP mal gestiti, codec incompatibili, trunk SIP configurati male o aspettative non realistiche sul comportamento SIP delle piattaforme AI.

Per questo motivo, prima di parlare di LLM, WebSocket o RAG, resta fondamentale saper leggere bene un INVITE, capire come lavora un peer trunk e interpretare correttamente un tracciato SIP/RTP.

Il settore sta evolvendo molto rapidamente. I PBX stanno imparando a lavorare con realtime AI, mentre le piattaforme AI migliorano rapidamente il supporto SIP, le autenticazioni e la gestione delle numerazioni.

Gli AI Voice Agent non sostituiscono il mondo SIP, lo estendono. Ed è proprio per questo che le competenze VoIP tradizionali continueranno a fare la differenza anche nelle integrazioni AI dei prossimi anni.

Fonti tecniche di riferimento per approfondimenti

« Post precedenti

RFC3261 Capitolo 9:

RFC 3261: Il DNA del VoIP – Capitolo 9 BYE e CANCEL: chiudere o interrompere una chiamata SIP

Tre definizioni da fissare subito

Come distinguerli empiricamente in un tracciato pcap

CANCEL e BYE: due fasi diverse

Che cosa dice la RFC sul CANCEL

Controllo del metodo

Quando può partire il CANCEL

Stesso percorso della richiesta originale

Che cosa succede quando arriva il CANCEL

Quando il CANCEL non trova la richiesta

CANCEL e proxy

Che cosa dice la RFC sul BYE

Early dialog e confirmed dialog, spiegati in modo semplice

Esempio pratico di early dialog

Esempio pratico di confirmed dialog

Se è il chiamato a rifiutare

Il lato UAC

Il lato UAS

Dopo il BYE

Il vincolo sul lato chiamato

Tra 200 OK e ACK

Che cosa significa timeout in questo contesto

Come leggere questa regola in pratica

Cosa succede se il CANCEL arriva troppo tardi

Consigli pratici per Wireshark

Perché la RFC separa così nettamente i due metodi

Conclusione

VoIP oltre il SIP: le RFC fondamentali per media, DTMF e NAT traversal

DTMF: quando la segnalazione incontra il piano media

RTP e RTCP: dove viaggia davvero la voce

SDP e negoziazione dei codec

NAT traversal: il vero problema del VoIP moderno

QoS e qualità della voce

La sicurezza del flusso media

Fax over IP e i limiti pratici

Mettere insieme i pezzi: il VoIP come sistema

Fonti utili per approfondire

Le RFC del protocollo SIP: come leggere, capire e usare davvero i documenti fondamentali

Cosa sono le RFC e perché sono così importanti nel protocollo SIP

Perché non basta conoscere solo la RFC 3261

Le RFC SIP core da conoscere subito

Le origini del protocollo: dalle prime specifiche alla definizione del SIP moderno

1999-2002: il passaggio dalla RFC storica al vero core operativo

Elenco completo delle RFC SIP dal 1999 al 2005

La maturazione del protocollo: identità, eventi, conferenze, NAT e mobilità

2006-2012: il SIP si consolida come ecosistema completo

Elenco completo delle RFC SIP dal 2006 al 2012

Una tabella pratica per non perdere di vista le RFC davvero centrali

Come leggere questo insieme di documenti senza perdersi

Perché studiare ancora oggi le RFC SIP ha un valore concreto

Fonti utili per approfondire

RFC 3261 Capitolo 8: ACK, conferma finale della sessione

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

Perché l’ACK merita un capitolo a parte

Il punto della RFC: 2xx all’INVITE

Un esempio minimo di chiusura corretta del setup

L’ACK non è una risposta

Che cosa conferma davvero l’ACK

Perché senza ACK il setup resta incompleto

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

Dove nasce spesso il problema

Firewall, layer 7 e SIP ALG/helper

ACK e dialogo SIP

Perché la RFC separa bene questo caso

Approfondimenti finali dalla RFC

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

2. Dialogo confermato e route set ricalcolato

3. Come si costruisce davvero l’ACK

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

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

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

Conclusione

Collegare un AI Voice Agent al PBX: SIP trunk, WebSocket e integrazione AI

Collegare un AI Voice Agent al PBX aziendale: SIP trunk, WebSocket e ruolo del PBX

Primo scenario: quando l’AI è integrata direttamente nel PBX

I CONSIGLI DI VOIP.IT

Secondo scenario: quando l’AI Agent è esterno

Perché è sconsigliabile collegare direttamente il trunk SIP del provider all’AI Agent

I CONSIGLI DI VOIP.IT

RFC 3261: Il DNA del VoIP – Capitolo 9
BYE e CANCEL: chiudere o interrompere una chiamata SIP

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

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

3. Come si costruisce davvero l’`ACK`

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

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

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