Due approcci alla latenza nelle conference call con IA: una panoramica tecnica
agenti-per-teleconferenze-IA
Introduzione
Oggi presentiamo due prodotti distinti progettati per distribuire agenti AI in chiamate in conferenza. Uno si integra con Google Meet. L'altro opera su un'infrastruttura nativa appositamente costruita. Questo post illustra il razionale architettonico dietro ciascuno e i criteri per scegliere tra i due.
Durante lo sviluppo della nostra piattaforma AI per le chiamate di business, una domanda è emersa costantemente nelle conversazioni enterprise: "È compatibile con Google Meet?"
La risposta è sì — e abbiamo ora formalizzato questa capacità in un prodotto dedicato. Allo stesso tempo, stiamo rilasciando un secondo prodotto che adotta un approccio fondamentalmente diverso. Questo post fornisce un resoconto tecnico di entrambi, delle decisioni di progettazione dietro ciascuno e un quadro per determinare quale sia più appropriato per un dato caso d'uso.
Nuovo prodotto #1
Callin for Google Meet
Il nostro primo annuncio di oggi è Callin for Google Meet: un livello di traduzione vocale AI che si collega direttamente alle tue chiamate Google Meet esistenti — nessuna modifica al workflow, nessun nuovo strumento da installare, nessuna formazione del team richiesta.
Come funziona
Callin for Google Meet opera come partecipante AI alla chiamata. Si connette tramite l'API di Google Meet, acquisisce l'audio di ciascun interlocutore in tempo reale, esegue trascrizione e traduzione tramite il nostro modello AI e restituisce l'audio tradotto ai partecipanti configurati.
Architettura — Callin for Google Meet
Interlocutore A (EN)──▶Google Meet Server──▶Callin Bot
↕STT → LLM translate → TTS
Interlocutore B (IT)◀──Google Meet Server◀──Callin Bot
* I pacchetti audio transitano attraverso l'infrastruttura di Google prima di raggiungere il bot
Motivazione
Nella maggior parte degli ambienti enterprise, Google Meet è già lo standard consolidato. I processi di approvvigionamento sono stati completati, le policy IT ne impongono l'uso e l'integrazione con Google Workspace è profondamente radicata nei flussi di lavoro quotidiani. Proporre una migrazione di piattaforma come prerequisito per adottare la traduzione AI raramente è una via praticabile, in particolare per le organizzazioni che operano su larga scala.
Callin for Google Meet è progettato per incontrare le organizzazioni dove già operano. Non richiede modifiche all'infrastruttura esistente, nessuna riqualificazione del personale e nessuna interruzione dei flussi di lavoro consolidati delle riunioni. I team continuano a usare Meet; il livello di traduzione AI opera in modo trasparente al suo interno.
Caso d'uso ideale: aziende con team internazionali già su Google Workspace, chiamate regolari con clienti in lingue diverse o negoziazioni commerciali multilingue in cui il cambio di piattaforma non è un'opzione praticabile nel breve termine.
Vincoli architetturali
La trasparenza sui limiti di questa integrazione è centrale nel modo in cui comunichiamo i nostri prodotti. Callin for Google Meet opera entro confini strutturali intrinseci all'infrastruttura di Google e che non possono essere affrontati a livello applicativo.
// Ripartizione della latenza — Callin for Google Meet (misurazioni interne)
Primo salto di rete (client → server Meet) ~80–150 ms
Routing interno di Meet ~40–80 ms
Acquisizione audio del bot + buffering ~60–120 ms
STT (speech-to-text) ~150–250 ms
Traduzione LLM ~80–150 ms
TTS (text-to-speech) + riproduzione ~100–180 ms
Latenza end-to-end (stimata) ~600–900 ms
La principale fonte di latenza non è il modello AI stesso, ma la pipeline audio imposta dall'architettura di Google Meet. Meet non è stato progettato come relay in tempo reale per agenti AI. Il buffering interno, la logica di routing e l'infrastruttura — ottimizzati per la consegna di video di alta qualità tra partecipanti umani — introducono un sovraccarico strutturale che non può essere ridotto da un punto di integrazione esterno.
Nuovo prodotto #2
Callin Voice Engine
Il secondo annuncio rappresenta l'investimento infrastrutturale a più lungo termine intrapreso dal nostro team di ingegneria. Callin Voice Engine è la nostra infrastruttura audio nativa: uno stack in tempo reale progettato da zero per agenti vocali AI in produzione, senza alcuna dipendenza architetturale da piattaforme di videoconferenza di terze parti.
Contesto e motivazione
Google Meet è progettato appositamente per un obiettivo ben definito: fornire video ad alta definizione a partecipanti umani in una sessione condivisa. Affronta efficacemente quel problema. Gli agenti vocali AI, tuttavia, operano sotto un insieme di requisiti sostanzialmente diverso.
Per un agente AI conversazionale, la latenza di risposta non è semplicemente una metrica di performance — è un determinante del fatto che l'interazione appaia naturale o meccanica. Sotto i circa 300 ms, la conversazione risulta fluida e reattiva. Nell'intervallo 400–700 ms, gli utenti iniziano a percepire una pausa innaturale. Oltre i 700 ms, la continuità conversazionale si rompe: gli utenti esitano, si chiedono se l'agente abbia elaborato il loro input e possono ripetersi.
La conseguenza va oltre la qualità dell'esperienza utente. Con latenza elevata, l'affidabilità percepita del prodotto stesso viene compromessa — una considerazione particolarmente significativa nelle implementazioni rivolte ai clienti.
Panoramica architetturale
Callin Voice Engine è costruito su uno stack WebRTC nativo ottimizzato specificamente per i carichi di lavoro della pipeline AI. Le sezioni seguenti descrivono ciascun livello architetturale e il suo contributo alla riduzione della latenza end-to-end.
1 · Trasporto UDP — eliminazione del blocco head-of-line
Callin Voice Engine usa UDP come livello di trasporto di base, abbinato a SRTP (Secure Real-time Transport Protocol) per la crittografia a livello di pacchetto.
TCP — il protocollo alla base di HTTP e WebSocket — impone una consegna ordinata e affidabile. Quando un pacchetto va perso in transito, il buffer di ricezione si blocca fino al completamento della ritrasmissione. Nello streaming audio in tempo reale, questo comportamento è controproducente: un pacchetto audio perso è meno dannoso di uno ritardato. Il codec è progettato per gestire in modo elegante la perdita di pacchetti; non può compensare una pipeline bloccata sulla ritrasmissione TCP.
UDP rinuncia alle garanzie di consegna in favore della continuità. La resilienza viene gestita a livello applicativo dal codec, rimuovendo completamente il blocco strutturale di TCP dal percorso critico per la latenza.
2 · Infrastruttura edge distribuita — primo salto a ~13 ms (P50)
Il ritardo di propagazione di rete è vincolato da limiti fisici: la trasmissione del segnale su fibra ottica viaggia a circa 200.000 km/s, il che stabilisce un limite minimo assoluto per i tempi di andata e ritorno. La leva pratica a disposizione degli ingegneri è la geografia — in particolare, ridurre la distanza tra il client e il primo nodo server.
Callin Voice Engine opera su una rete globale di nodi edge distribuiti, posizionati per ottenere una latenza mediana del primo salto di circa 13 ms tra il client e la nostra infrastruttura. Una volta che il traffico entra nella nostra rete, viene instradato su backbone privati tra datacenter — connessioni dedicate con profili di latenza più bassi e più coerenti rispetto ai percorsi pubblici di Internet, su cui qualsiasi integrazione basata su Meet deve fare affidamento per l'intero percorso end-to-end.
3 · Architettura SFU — sovraccarico di transcoding nullo
Callin Voice Engine opera su un modello Selective Forwarding Unit (SFU), anziché su una Multipoint Control Unit (MCU).
Una MCU decodifica ogni flusso audio in ingresso, mescola i segnali, ricodifica l'output e lo ridistribuisce ai partecipanti. Ogni passaggio del codec introduce latenza aggiuntiva — in genere 60–150 ms per ogni tratto di transcoding. Una SFU, al contrario, esegue un inoltro selettivo dei pacchetti senza decodificare o ricodificare il payload. Il nostro media server instrada i pacchetti audio così come vengono ricevuti; il bitstream non viene mai toccato. Il risultato è un percorso di inoltro senza sovraccarico di transcoding.
4 · Opus ottimizzato per l'AI — frame da 10 ms, DTX, FEC in-band
Il codec audio in Callin Voice Engine è Opus, configurato con parametri specifici per i casi d'uso AI:
Dimensione del frame: 10 ms — dimezza il ritardo algoritmico rispetto al valore predefinito di 20 ms. La qualità percepita del parlato rimane invariata; la latenza di packetization si dimezza.
DTX (Discontinuous Transmission) — non viene trasmesso nulla durante il silenzio. Riduce la banda e il carico della pipeline AI durante le pause naturali nel parlato.
FEC in-band — correzione degli errori Forward Error Correction incorporata nel flusso: se un pacchetto va perso, il successivo contiene informazioni sufficienti per ricostruirlo. Nessun fallback, nessuna richiesta di ritrasmissione.
5 · Buffer jitter adattivo — target 10–20 ms
Il buffer jitter è una fonte comune di latenza nei sistemi audio, spesso sovradimensionata nelle implementazioni generiche. Le configurazioni standard puntano tipicamente a 40–80 ms per mantenere robustezza in condizioni di rete variabili. Callin Voice Engine imposta il target a 10–20 ms, con adattamento dinamico basato sulle misurazioni di jitter in tempo reale osservate.
Questa configurazione è sostenibile perché il traffico opera su una rete edge privata con jitter sostanzialmente inferiore e più costante rispetto ai percorsi pubblici di Internet. Il target ridotto del buffer non è un compromesso accettato — è una conseguenza diretta delle proprietà dell'infrastruttura che la rete è progettata per offrire.
6 · Streaming audio continuo — esecuzione parallela della pipeline
Dal punto di vista della pipeline AI, questa è probabilmente la differenza architetturale più rilevante — e quella meno evidente dai soli valori grezzi di latenza.
In un'integrazione basata su Meet, l'audio viene necessariamente consegnato in blocchi discreti. Il modello STT elabora ogni blocco in sequenza; l'LLM inizia solo una volta che un enunciato completo è stato trascritto; segue la sintesi TTS. Ogni fase deve concludersi prima che la successiva possa iniziare. La pipeline è intrinsecamente seriale.
Callin Voice Engine fornisce l'audio come flusso continuo. Il modello STT inizia la trascrizione sui primi frame in arrivo, mentre l'interlocutore sta ancora parlando. L'LLM riceve progressivamente i token della trascrizione e può avviare la generazione della risposta prima che l'enunciato sia completo. Il modello TTS inizia a sintetizzare i primi token di output prima che l'LLM abbia terminato il completamento.
Le tre fasi vengono eseguite in parallelo anziché in sequenza. La latenza percepita end-to-end è quindi determinata dalla fase più lenta al suo margine — non dalla somma cumulativa di tutte le durate delle fasi.
Pipeline AI — Callin Voice Engine vs approccio seriale
✕ Pipeline seriale (approccio basato su Meet)
Blocco audio→STT completo→LLM completo→TTS completo→Riproduzione
✓ Pipeline in streaming (Callin Voice Engine)
Flusso audio→streaming STT
↕ flusso di token
streaming LLM
↕ flusso di token
streaming TTS→Riproduzione
Confronto diretto: latenza misurata
I valori riportati di seguito provengono da misurazioni interne su sessioni reali. I valori di Google Meet sono misurati su chiamate con partecipanti nell'Europa occidentale; quelli di Callin Voice Engine sono misurati in condizioni di rete comparabili.
Componente | Callin for Meet | Callin Voice Engine | Δ guadagnato |
|---|---|---|---|
Rete primo salto | 80–150 ms | ~13 ms (P50) | −70–140 ms |
Routing / server interno | 40–80 ms | 5–15 ms (SFU) | −35–65 ms |
Buffer jitter | 40–80 ms | 10–20 ms | −30–60 ms |
Sovraccarico di transcoding | 60–150 ms | 0 ms (SFU puro) | −60–150 ms |
Dimensione frame codec | 20 ms (predefinito) | 10 ms | −10 ms |
Pipeline STT → LLM → TTS | seriale ~500 ms | parallelo ~200 ms | ~−300 ms |
End-to-end (stimato) | 600–900 ms | 180–350 ms | ~3× più veloce |
// Ripartizione della latenza — Callin Voice Engine
Primo salto di rete (client → nodo edge) ~13 ms P50
Inoltro SFU (nessun transcoding) ~5–15 ms
Buffer jitter (aggressivo, rete privata) ~10–20 ms
Streaming STT (inizia sui primi frame) ~80–120 ms
LLM (in streaming, in parallelo con STT) ~60–100 ms
TTS (in streaming, in parallelo con LLM) ~40–80 ms
Latenza end-to-end (stimata) ~180–350 ms
Selezione del prodotto appropriato
I due prodotti sono progettati per contesti di distribuzione significativamente diversi. I seguenti criteri hanno lo scopo di supportare una valutazione informata:
Callin for Google Meet è adatto quando:
L'organizzazione è già standardizzata su Google Workspace · La migrazione di piattaforma non è fattibile nell'attuale quadro IT o contrattuale · I volumi di chiamate sono moderati (<50/giorno) · Una latenza end-to-end nell'intervallo 600–900 ms è accettabile per il caso d'uso previsto (riunioni interne, sessioni di formazione, flussi di lavoro multilingue non critici in termini di tempo).
Callin Voice Engine è la scelta appropriata quando:
La distribuzione coinvolge un agente vocale AI in produzione · Il caso d'uso è rivolto ai clienti, dove la latenza ha un impatto diretto e misurabile sull'esperienza utente e sulla retention · È richiesto il pieno controllo programmatico della pipeline audio (configurazione VAD, gestione delle interruzioni, logica personalizzata di turn-taking) · Il sistema deve supportare elevati volumi di chiamate con un'infrastruttura prevedibile e scalabile.
Considerazioni finali
Entrambi i prodotti riflettono un principio sottostante coerente: la soluzione appropriata dipende dai vincoli specifici del problema in questione, non da una singola preferenza architetturale.
Callin for Google Meet riduce al minimo lo sforzo di adozione per le organizzazioni che hanno già investito in quella piattaforma. Callin Voice Engine rimuove i limiti architetturali per i team che operano con requisiti di latenza più stringenti o che costruiscono prodotti rivolti ai clienti in cui la qualità conversazionale è un elemento distintivo.
La distinzione è importante perché la latenza nella voce AI non è una preoccupazione ingegneristica astratta. A 200 ms, una conversazione con un agente AI appare naturale. A 800 ms, il modello di interazione cambia — gli utenti si adattano al ritardo, le risposte sembrano preconfezionate e l'interfaccia ricorda i sistemi telefonici automatizzati di un'epoca precedente piuttosto che un prodotto genuinamente conversazionale.
Per i team che valutano Callin Voice Engine per carichi di lavoro in produzione, il nostro team di ingegneria è disponibile per revisioni architetturali dedicate.
Note metodologiche
Le misurazioni di latenza riportate sopra sono medie di sessioni di test controllate con partecipanti nell'Europa occidentale (Milano, Francoforte, Parigi) su connessioni in fibra consumer (50–200 Mbps). I valori reali variano in base alla geografia, alla qualità della rete e al carico del modello AI. "Callin for Google Meet" riflette il sovraccarico strutturale intrinseco all'architettura di Google Meet, indipendentemente dall'implementazione di Callin. Benchmark completi sono disponibili su richiesta per i clienti enterprise.
