Perché Retell ha creato il proprio gateway SIP e WebRTC

Prima che Retell creasse il proprio gateway, un fornitore leader collegava le chiamate telefoniche e da browser agli agenti IA di Retell. La piattaforma del fornitore ha avuto incidenti ripetuti, e il fornitore impiegava in media dai 50 ai 60 minuti per risolverne ciascuno. Non avevamo modo di risolvere un incidente più rapidamente. Alcune chiamate in entrata non sono mai arrivate a Retell, quindi i nostri sistemi non ne avevano traccia. Venivamo a sapere delle chiamate mancate dai ticket di assistenza clienti.

Volevamo avere il controllo sulla qualità e sulla disponibilità di ogni chiamata, così abbiamo creato il nostro gateway SIP e WebRTC. A ottobre 2026, il gateway gestisce il 100% delle chiamate telefoniche e da browser di Retell.

Il gateway di Retell è il sistema che collega le reti telefoniche e i browser web agli agenti vocali con IA di Retell. Utilizza SIP (Session Initiation Protocol), lo standard con cui i sistemi telefonici avviano e terminano le chiamate, e WebRTC (Web Real-Time Communication), lo standard con cui i browser gestiscono l'audio in tempo reale.

Il gateway avvia ogni chiamata, trasporta l'audio e lo mixa per tutti i partecipanti, e gestisce i trasferimenti, l'ascolto dal vivo (un supervisore ascolta la chiamata mentre si svolge), il subentro (un supervisore o un operatore umano prende il posto dell'agente IA a chiamata in corso) e la chiusura delle chiamate.

Per apportare queste modifiche, abbiamo sostituito il fornitore in tre passaggi.

Risultati principali:

• La latenza dell'infrastruttura è inferiore di circa il 90%, da 50 ms a 0,5 ms.
• Ogni chiamata telefonica arriva prima a Retell, comprese le chiamate che non vanno a buon fine.
• Le funzionalità di chiamata vengono rilasciate secondo il calendario di rilascio di Retell.

Cosa c'è tra chi chiama e un agente IA

Le demo di IA vocale di solito mostrano l'ultimo passaggio di un sistema complesso: il modello che ascolta e risponde. Un agente telefonico in produzione ha bisogno di molto di più. Di solito ci sono diversi livelli prima del modello. Sono questi a decidere se una chiamata si connette, quanto velocemente viaggia l'audio e cosa succede quando qualcosa si guasta.

Una chiamata verso un agente di Retell attraversa i seguenti quattro livelli:

1. La PSTN (public switched telephone network) è la rete telefonica globale. Le chiamate da browser arrivano da un sito web o da una web app.
2. Un session border controller (SBC) è il punto di ingresso sicuro per le chiamate telefoniche. Riceve le chiamate dall'esterno e decide dove instradare ciascuna. Le chiamate da browser saltano l'SBC e si collegano direttamente al gateway.
3. Il livello media. Avvia ogni chiamata, trasporta l'audio in entrambe le direzioni, lo mixa per tutti i partecipanti ed esegue i controlli di chiamata come trasferimenti e chiusure. Le chiamate telefoniche lo raggiungono tramite SIP. Le chiamate da browser lo raggiungono tramite WebRTC. In Retell, il gateway è il livello media.
4. L'infrastruttura IA di Retell. Gestisce la conversazione con chi chiama.

Prima del gateway, il fornitore gestiva i livelli 2 e 3. Retell eseguiva nel mezzo un unico software, chiamato audio relay. L'audio attraversava la rete internet pubblica tra il fornitore e il relay, un salto di circa 50 ms, e il relay lo inoltrava poi all'infrastruttura IA di Retell.

Perché la piattaforma del fornitore non era all'altezza

La piattaforma del fornitore si trovava sul percorso di ogni chiamata, quindi i suoi incidenti ricadevano direttamente sui clienti di Retell.

Il fornitore impiegava in media dai 50 ai 60 minuti per riprendersi da un incidente. Durante alcuni incidenti, le chiamate in entrata non arrivavano mai dal fornitore a Retell. Le chiamate mancate non lasciavano alcun record di chiamata né alcun evento nei nostri sistemi, il che significava che non avevamo modo di rilevare il problema in autonomia.

Affidarsi al fornitore causava anche altri problemi:

• I requisiti dei clienti dipendevano da ciò che il fornitore supportava, quindi non potevamo rilasciare nulla che non fosse supportato.
• I requisiti di sicurezza e conformità erano difficili da soddisfare tramite la piattaforma del fornitore.
• Il salto sulla rete internet pubblica aggiungeva latenza a ogni chiamata.
• La fattura del fornitore ammontava a milioni di dollari all'anno.

Abbiamo valutato anche altri fornitori. Le valutazioni hanno confermato ciò che già pensavamo: per controllare la qualità del prodotto, dovevamo creare il nostro gateway.

Come abbiamo sostituito il fornitore in tre passaggi

Ogni passaggio ha spostato una parte del percorso delle chiamate sull'infrastruttura di Retell.

Mettere i session border controller di Retell davanti al fornitore

Abbiamo distribuito i nostri SBC e vi abbiamo indirizzato tutta la segnalazione SIP. I clienti hanno inviato le loro chiamate telefoniche all'indirizzo di Retell anziché a quello del fornitore. Hanno anche aggiunto gli indirizzi IP di Retell alle loro allowlist, gli elenchi di indirizzi da cui i loro sistemi telefonici accettano chiamate. All'inizio, gli SBC inoltravano ogni chiamata al fornitore.

Avere i nostri SBC ci ha dato il controllo dell'instradamento. Ogni chiamata telefonica arrivava ora prima all'infrastruttura di Retell, dove potevamo vederla indipendentemente dal fatto che si connettesse o meno.

Per un periodo, le chiamate hanno seguito un percorso più lungo. Tra gli SBC di Retell e l'infrastruttura IA di Retell, ogni chiamata usciva dalla nostra rete verso il fornitore e poi rientrava. Lungo il tragitto attraversava due volte la rete internet pubblica. Le chiamate da browser continuavano ad andare direttamente al fornitore.

Spostare le chiamate telefoniche sul gateway per fasi, dall'1% al 100%

Successivamente abbiamo creato il gateway e lo abbiamo distribuito dietro gli SBC, all'interno della rete di Retell. Una volta attivo il gateway, ogni chiamata telefonica poteva seguire uno di due percorsi: attraverso il fornitore o attraverso il gateway.

Gli SBC sceglievano il percorso per le chiamate in entrata. L'infrastruttura IA di Retell lo sceglieva per le chiamate in uscita. Abbiamo aumentato per fasi la quota di chiamate telefoniche gestite dal gateway: 1%, 5%, 10%, 20%, 30%, 50% e infine 100%. Sul percorso del gateway, il salto tra gli SBC e il gateway richiede circa 0,5 ms, perché entrambi si trovano all'interno della rete di Retell.

Spostare le chiamate da browser sul gateway con il WebRTC SDK di Retell

Le chiamate da browser erano le ultime rimaste sul fornitore. Abbiamo creato il nostro WebRTC SDK (software development kit), il codice che un sito web o una web app usa per effettuare chiamate da browser, e abbiamo instradato le chiamate da browser attraverso il gateway.

Una volta spostate le chiamate da browser, abbiamo dismesso il fornitore e l'audio relay. Ora una chiamata resta sulla rete di Retell dal momento in cui arriva fino a quando raggiunge l'infrastruttura IA di Retell.

Perché la migrazione è stata difficile

L'obiettivo era assumere il controllo senza modificare alcun comportamento su cui i clienti facevano affidamento. La parte difficile è stata sostituire il fornitore durante le chiamate in corso senza creare disagi ai clienti. Chiamate in entrata, chiamate in uscita, trasferimenti, chiamate da browser e controlli di chiamata dovevano continuare a funzionare come prima, per tutta la durata della migrazione.

Questo significava preservare quattro aspetti:

• Comportamento del protocollo (come il gateway comunica in SIP con i sistemi all'altro capo della chiamata): gli operatori telefonici e i sistemi telefonici dei clienti dovevano ottenere il comportamento previsto.
• Tempistica dell'audio (quando l'audio arriva su ciascun lato della chiamata): l'audio doveva viaggiare in entrambe le direzioni senza nuove interruzioni o ritardi.
• Permessi dei partecipanti (chi, in una chiamata, può ascoltare, parlare o avviare un subentro): un supervisore che usa l'ascolto dal vivo doveva mantenere gli stessi diritti.
• Semantica del ciclo di vita della chiamata (come una chiamata inizia, cambia e termina): ogni chiamata doveva iniziare, essere trasferita e terminare allo stesso modo, e inviare gli stessi eventi ai sistemi di Retell.

Il rilascio per fasi ci ha permesso di testare ogni comportamento su una piccola quota di chiamate telefoniche reali. Abbiamo ampliato la quota solo dopo aver verificato che il comportamento reggesse.

La lezione principale per noi è che una migrazione del gateway come questa dipende dal controllo dell'instradamento, da una solida osservabilità e da test che coprano l'intero ciclo di vita della chiamata. Osservabilità significa poter vedere cosa sta facendo ogni chiamata mentre si svolge.

Il percorso delle chiamate di Retell oggi: SBC, gateway e WebRTC SDK

Il nostro nuovo percorso delle chiamate ha tre componenti.

Gli SBC di Retell sono rivolti verso l'esterno. Ricevono la segnalazione SIP dagli operatori telefonici e dai sistemi telefonici dei clienti, quindi instradano ogni chiamata.

Il gateway svolge il lavoro che prima faceva il fornitore. Avvia le chiamate, trasporta e mixa l'audio ed esegue i controlli di chiamata. Comunica con l'infrastruttura IA di Retell tramite HTTP e WebSocket, due modalità standard con cui i server si scambiano richieste e trasmettono dati in streaming.

Il WebRTC SDK di Retell permette a siti web e web app di inviare le chiamate da browser direttamente al gateway.

I controlli di sicurezza e conformità fanno parte del design. Includono accesso autenticato, permessi dei partecipanti, gestione dell'audio sensibile e oscuramento delle informazioni sensibili.

Cosa è cambiato con un gateway di proprietà

Avere il controllo del percorso delle chiamate significa rispondere in prima persona di ogni aspetto della qualità di una chiamata.

Non dobbiamo più aspettare un fornitore per sviluppare funzionalità di chiamata. Un cliente del settore assicurativo aveva bisogno di header SIP personalizzati nei messaggi SIP BYE per una delle sue campagne. Gli header SIP sono campi che trasportano informazioni aggiuntive insieme a una chiamata. Un messaggio BYE è il segnale che termina una chiamata. All'epoca il fornitore non supportava header personalizzati nei messaggi BYE, così abbiamo sviluppato la funzionalità nel gateway. Poiché controlliamo il codice e il processo di rilascio, rilasciamo secondo il nostro calendario.

Ora possiamo soddisfare in autonomia i requisiti di sicurezza di un cliente (HIPAA, SOC 2, ecc.). Retell può anche distribuire il gateway in nuove regioni cloud quando i clienti ne hanno bisogno.

Quando costruirlo in proprio è la scelta sbagliata

Un gateway è il progetto sbagliato per un team che non ha la capacità ingegneristica per gestire un'infrastruttura di comunicazione in tempo reale, o i requisiti di prodotto che lo giustifichino.

Il nostro lavoro è proseguito anche dopo il lancio. Gestire un gateway richiede un team qualificato e investimenti continui in:

• Interoperabilità telefonica
• Networking
• Elaborazione dei media
• Sicurezza
• Monitoraggio
• Operazioni di reperibilità

Interoperabilità telefonica significa mantenere il gateway compatibile con i numerosi operatori telefonici e sistemi telefonici a cui si collega.

Avere un gateway di proprietà significa anche farsi carico della risposta agli incidenti, della pianificazione della capacità, della manutenzione e di distribuzioni sicure. Retell ha fatto questo investimento perché qualità delle chiamate, disponibilità, personalizzazione e miglioramento rapido sono al centro del nostro prodotto.

Consigli per i team che vogliono fare lo stesso

Se il tuo team decide di creare un proprio gateway, ecco cosa ha funzionato per noi:

1. Prendi il controllo del tuo punto di ingresso SIP per primo, così puoi gestire l'instradamento e vedere ogni chiamata telefonica prima di sostituire il livello media.
2. Migra le chiamate telefoniche gradualmente costruendo il tuo gateway dietro i tuoi SBC.
3. Tratta le chiamate da browser come un'integrazione completa che include l'SDK, l'autenticazione, l'avvio della connessione e il trasporto dell'audio.
4. Integra fin dall'inizio i controlli di sicurezza e conformità, come abbiamo fatto con il gateway di Retell.
5. Misura latenza, qualità audio e comportamento in caso di errore durante l'intera migrazione, comprese le chiamate che falliscono prima di raggiungere la tua applicazione.

Collega il tuo sistema telefonico a Retell

Se i requisiti di telefonia hanno frenato l'adozione dell'IA vocale, inizia dalla nostra guida alla telefonia personalizzata. Spiega come collegare il tuo sistema telefonico a Retell tramite un SIP trunk (una connessione SIP diretta tra due sistemi telefonici) e quali indirizzi di Retell aggiungere all'allowlist. Per altri contenuti tecnici, consulta i nostri articoli su Real-Time Reliability, Retell Workflows e Retell Memory.

E se gestisci elevati volumi di chiamate o devi rispettare rigidi requisiti di conformità, parla con il nostro team.