Competenza · Telefonia e contact center
Il livello di telefonia tra il vostro operatore e chi risponde — un uomo o un agente.
Costruiamo la centrale: trunk SIP, regole di instradamento per programma, menu IVR letti dal database, code di attesa, trasferimento a un umano, registrazione e analisi delle chiamate. La chiamata diventa una registrazione con trascrizione e riepilogo, non un ricordo.
Già costruitoTre implementazioni proprie, citate di seguito. (1) Il livello Asterisk nella piattaforma Kallina: 5.522 righe di configurazione di dialplan, script AGI e bridge audio in `asterisk/`, più template di trunk generati automaticamente per numero. (2) `asterisk-manager` — un servizio separato che amministra code, trunk e flusso RTP tramite l’interfaccia di gestione del centralino. (3) Il middleware per il centralino virtuale di un operatore, che è andato in produzione: il commit di riconciliazione del 14 luglio 2026 porta nel repository codice che era già in esecuzione sul server ed era di circa 40 giorni davanti al git. La riserva, detta prima che lo chieda: l’host SIP attraverso cui passano le nostre linee di test non risponde — verificato oggi, 06.09.2026, senza risposta al ping e senza risposta su HTTP. Non presentiamo un numero dimostrativo da chiamare ora, perché non potremmo metterlo su davanti a lei.
Tra il vostro operatore telefonico e chi risponde effettivamente — una persona o un voice agent — deve esserci un livello che prende decisioni. Chi riceve la chiamata alle 23:40. Cosa succede se non risponde nessuno. Dove va la chiamata quando il cliente chiede «un uomo». Cosa resta della conversazione dopo che si è chiusa. Questo livello è una centrale, e noi lo costruiamo perché sia dell’azienda, non del fornitore di voce: se domani cambiate il motore dell’agente, le regole di routing, le code e la cronologia restano vostre.
Concretamente, cosa abbiamo costruito: dodici file di dialplan — produzione, IVR, coda, trasferimento, voicemail, deviazione, chiamate uscenti con agente — quattro script AGI in Python e due bridge audio, in totale 5.522 righe. Il motore IVR non ha i menu scritti nel file: li legge dal database tramite uno script AGI e restituisce una delle sei decisioni — verso un agente, verso un altro menu, verso una coda, trasferimento a un numero esterno, messaggio finale, o chiusura. Le code si chiamano in base al loro identificatore e non hanno membri scritti nella configurazione: vengono aggiunti e rimossi dall’esterno, tramite l’interfaccia di gestione, il che significa che un operatore può entrare o uscire dalla coda senza riavviare la centrale.
Il routing ha regole reali, non un solo «chiama qui»: orari di apertura e fuso orario, orario notturno del tipo 22:00 → 06:00, e corrispondenza per priorità — l’intestazione SIP `Diversion`, che porta il numero originale da cui è stato trasferito il chiamata, poi il proprio numero, poi la regola di riserva. I trunk sono generati per numero, con un nome costruito dal fornitore e dal numero, da una funzione di configurazione — non scritti a mano a ogni nuova riga.
Ciò che esce dalla chiamata è importante quanto la chiamata. Per la linea collegata al centralino virtuale di un operatore abbiamo costruito un middleware in Python che interroga la lista delle registrazioni ogni minuto, con una riconciliazione ampia ogni sei ore affinché un’interruzione di rete non faccia perdere nulla, e una scansione ogni tre minuti delle chiamate perse — quelle non hanno registrazione e altrimenti sarebbero completamente invisibili. Ogni registrazione viene scaricata, trascritta, analizzata e riflessa nell’analisi delle chiamate, e la chiamata persa diventa un alert. L’idempotenza sta in un set Redis, così che la stessa registrazione non venga elaborata due volte.