Nuovi registri dati delle chiamate – Un’analisi più profonda

Importante aggiornamento del sistema dei Call Data Records (CDR) in 3CX.

Dopo il rilascio della V20 Update 6 Alpha release, di ieri, questo post spiega il nuovo sistema di Call Data Records (CDR) in 3CX, dove abbiamo semplificato il CDR in un’unica tabella: cdr_output. Abbiamo smantellato la vecchia struttura, svelato il nuovo design e messo in evidenza i vantaggi tecnici che stanno trasformando il funzionamento dei dati delle chiamate. Continuate a leggere per tutti i dettagli.

La struttura Legacy: Un collo di bottiglia frammentato

In origine, i dati CDR/chiamate di 3CX erano suddivisi in quattro tabelle: cl_calls, cl_participants, cl_party_info e cl_segments. Ciascuna di esse memorizzava elementi distinti del ciclo di vita della chiamata: timestamp, dati dei partecipanti e dettagli di instradamento, costringendo a complesse JOIN SQL per mettere insieme un record completo. Questa struttura a più tabelle aumentava l’overhead delle query e impediva la generazione di report. Per le analisi su scala cloud o per i report in tempo reale, la struttura non era in grado di tenere il passo.

Il nuovo approccio: cdr_output

Abbiamo rielaborato questa struttura in cdr_output, una soluzione a tabella singola che consolida tutti i dati delle chiamate in un’unica tabella efficiente. Timestamp, partecipanti, instradamento ed esiti: tutto è unificato, eliminando la necessità di JOIN. Il JOIN è necessario solo per i dati di registrazione, che ora si trovano nella propria tabella cdr_recordingsout. In 3CX siamo sempre stati in grado di scalare fino a migliaia di utenti. Questa architettura snella rafforza ulteriormente la nostra scalabilità, riduce la complessità, aumenta la velocità delle query e prepara 3CX per l’analisi cloud-ready. Si tratta di un ripensamento audace dell’ingegneria dei dati, costruito per offrire precisione e potenza.

Progresso n. 1: tutti i dati in un’unica tabella intelligente

Legacy: Le JOIN a più tabelle bloccavano le prestazioni, un vero e proprio grattacapo per gli approfondimenti sulle chiamate.
Nuovo: cdr_output racchiude tutto – origine, destinazione, timestamp, esiti – in un’unica tabella compatta. È piatta e semplice, elimina il disordine relazionale e consente agli analisti di BI di seguire facilmente i flussi delle chiamate.

Perché funziona:

• Query più veloci: Abbandona la complessità di più tabelle per la velocità di una singola tabella: le query scalano senza problemi, indipendentemente dalle dimensioni dei dati.
• Pronto per il cloud: Si inserisce direttamente nei data lake o negli strumenti di BI, senza bisogno di ulteriori preparazioni.
• Vittoria per gli analisti: I percorsi delle chiamate sono chiari e veloci da tracciare, risparmiando ore di lavoro.

Vantaggio tecnologico: gli indici su cdr_id e call_history_id potenziano PostgreSQL per ricerche fulminee, anche con insiemi di dati enormi. Mantenere i collegamenti call_history_id all’interno della tabella riduce l’overhead dell’SQL, aumenta la velocità e riduce l’ingombro dei dati.

Progresso n. 2: Ogni riga racconta una storia

Legacy: I metadati sottili lasciavano gli analisti dei report indovinare: perché una chiamata è fallita? Dov’è il contesto? Chi ha trasferito a chi?
Nuovo: cdr_output incorpora un ricco set di attributi:

• termination_reason (e.g., “cancelled”, “dst_participant_terminated”)
• termination_reason_details (e.g., “forward_all”, “completed_elsewhere”)
• creation_method (e.g., “route_to”, “divert”)
• creation_forward_reason (e.g., “polling”, “busy”)
• continuation_reason (e.g., “polling”, “forward_all”)

Impatto:

• Chiarezza totale: Ogni riga è una storia completa: non è più necessario mettere insieme indizi.
• Approfondimenti più intelligenti: Potenzia i KPI come i tassi di abbandono o le statistiche delle code, senza richiedere lavoro aggiuntivo.
• Spiegazione del gioco finale: Per vedere immediatamente come, perché, quando e chi ha terminato una chiamata.

Aspetto tecnico: termination_reason_details alimenta l’analisi puntuale (si pensi a SQL GROUP BY di Grafana o PowerBi), mentre il cdr_id basato su UUID è ora GUID standard 00000000-01db-87c1-1bab-07aa0000000d per consentire agli strumenti di BI di indovinare la data e l’ordine di chiamata direttamente dalla scatola. È tutto lì: come è iniziata, si è spostata e si è conclusa una chiamata.

Progresso n. 3: Chi chiama chi, reso semplice

Legacy: I ruoli dei partecipanti erano mal definiti: fonte e destinazione richiedevano inferenze tra le tabelle, congetture, operazioni annidate, JOIN multipli e problemi di prestazioni.
Nuovo: cdr_output risolve i grovigli delle precedenti JOIN SQL con una serie di funzioni divise in modo pulito:

• source_participant_id (used for tracking)
• source_participant_phone_number (e.g., “+1305305305”)
• destination_dn_name (e.g., “Dana White”)
• Flags like source_participant_is_incoming and destination_participant_is_already_connected