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.

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.

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.

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.

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.

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.

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.

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.

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.

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.