Nuevos Registros de Datos de Llamadas – Una Inmersión Profunda

Importante actualización del sistema de Registro de Datos de Llamadas (CDR) en 3CX.

Siguiendo con el lanzamiento de ayer de la V20 Update 6 Alfa, este post explica el nuevo sistema de Registros de Datos de Llamadas (CDR) en 3CX, donde hemos simplificado CDR en una sola tabla: cdr_output. Desglosamos la vieja estructura, revelamos el nuevo diseño, y destacamos los logros técnicos que están transformando cómo funcionan los datos de llamadas. Siga leyendo para conocer todos los detalles.

La Configuración Heredada: Un Cuello de Botella Fragmentado

Originalmente, los datos de llamadas / CDR de 3CX estaban divididos en cuatro tablas: cl_calls, cl_participants, cl_party_info y cl_segments. Cada una de ellas almacenaba distintos elementos del ciclo de vida de la llamada: marcas de tiempo, datos de los participantes y detalles de enrutamiento, lo que obligaba a realizar complejas uniones SQL JOIN para reconstruir un registro completo. Este diseño de múltiples tablas aumentaba la sobrecarga de las consultas y reducía el rendimiento a la hora de generar informes. Para el análisis a escala de la nube o la generación de informes en tiempo real, la estructura simplemente no podía seguir el ritmo.

El Nuevo Enfoque: cdr_output

Lo hemos revisado en cdr_output, una solución de tabla única que consolida todos los datos de las llamadas en una tabla eficaz. Fechas, participantes, enrutamiento y resultados: todo está unificado, lo que elimina la necesidad de JOIN. JOIN solo es necesario para los datos de grabación, que ahora están en su propia tabla cdr_recordingsout. En 3CX siempre hemos sido capaces de escalar a miles de usuarios. Esta arquitectura esbelta fortalece aún más nuestra escalabilidad, reduce la complejidad, aumenta la velocidad de consulta, y prepara a 3CX para el análisis en la nube. Es un replanteamiento audaz de la ingeniería de datos, construido para ofrecer precisión y potencia.

Avance #1: Todos sus Datos en una Tabla Inteligente

Heredado: Los JOIN de varias tablas reducían el rendimiento, un verdadero dolor de cabeza para profundizar en la información sobre las llamadas.
Nuevo: cdr_output lo agrupa todo (origen, destino, marcas de tiempo, resultados) en una tabla compacta. Es plana y sencilla, y elimina el desorden relacional para que los analistas de BI puedan seguir fácilmente los flujos de llamadas.

Por qué es Genial:

• Consultas más Rápidas: Olvídese de la complejidad de las tablas múltiples para pasar a la velocidad de las tablas únicas: las consultas se escalan sin problemas, independientemente del tamaño de los datos.
• Listo para la Nube: Se integra directamente en bancos de datos o herramientas de BI, sin necesidad de preparación adicional.
• Gana el Analista: Las rutas de las llamadas son claras y rápidas de rastrear, lo que ahorra horas de trabajo.

Ventaja Tecnológica: Los índices en cdr_id y call_history_id aceleran PostgreSQL para búsquedas ultrarrápidas, incluso con conjuntos de datos masivos. Mantener los enlaces call_history_id en la tabla reduce la sobrecarga de SQL, aumenta la velocidad y recorta la hinchazón de datos.

Avance #2: Cada Fila Cuenta la Historia

Heredado: La escasez de metadatos deja a los analistas de reportes adivinando: ¿Por qué falló una llamada? ¿Dónde está el contexto? ¿Quién transfirió a quién?
Nuevo: cdr_output incorpora un rico conjunto de atributos:

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

Impacto:

• Claridad Total: Cada fila es una historia completa, se acabaron las pistas.
• Información más Inteligente: Impulsa KPI como las tasas de caída o las estadísticas de cola, sin necesidad de trabajo adicional.
• Fin del Juego Explicado: Vea al instante cómo, por qué, cuándo y quién finalizó una llamada.

Ventaja Tecnológica: termination_reason_details alimenta el análisis preciso (piense en SQL GROUP BY de Grafana o PowerBi), mientras que el cdr_id basado en UUID es ahora GUID estándar 00000000-01db-87c1-1bab-07aa0000000d para permitir que las herramientas de BI claven la fecha-hora y el orden de llamada desde el primer momento. Todo está ahí: cómo empezó, se movió y terminó una llamada.

Avance #3: ¿Quién Llama a Quién? Hecho Simple

Heredado: Las funciones de los participantes estaban mal definidas: origen frente a destino requería inferencias entre tablas, conjeturas, operaciones anidadas, JOINS múltiples y acaparamiento de rendimiento.
Nuevo: cdr_output domina los enredos anteriores de SQL JOIN con una serie de funciones de división limpia:

• source_participant_id (utilizado para el seguimiento).
• source_participant_phone_number (por ejemplo, “+1305305305”).
• destination_dn_name (por ejemplo, “Dana White”).
• Indicadores como source_participant_is_incoming y destination_participant_is_already_connected.

Impacto:

• Mapeo de Precisión: La dirección de la llamada es obvia: de origen a destino, listo, lo que agiliza el análisis del flujo.
• Manejo de Escenarios Complejos: Realiza un seguimiento sin fisuras de múltiples flujos de colas, troncales bidireccionales y transferencias multicapa en un único esquema.

Ventaja Tecnológica: Los indicadores de estado booleanos reflejan el modelado dimensional de un almacén de datos, optimizando el rendimiento de la cláusula WHERE. El estándar UUID en los ID de participantes garantiza una integración perfecta con las plataformas de BI, preservando la secuenciación de los tramos de llamada desde el primer momento.

Avance #4: Granularidad de la Marca de Tiempo

Heredado: cl_calls ofrecía tiempos básicos de inicio / fin; cl_segments fragmentaba el resto.
Nuevo: cdr_output proporciona tres marcas de tiempo precisas: cdr_started_at, cdr_ended_at, cdr_answered_at.
Impacto:

• Métricas Precisas: Consigue tiempos precisos de llamada a respuesta: cada segundo cuenta.
• Simplicidad Analítica: Los cálculos de una sola tabla sustituyen a las agregaciones de varias tablas.

Visión Experta: Las marcas de tiempo UTC (+00) garantizan la coherencia entre regiones, algo imprescindible para las instalaciones globales en la nube que se alimentan de herramientas como Snowflake o BigQuery. El cdr_id basado en GUID vincula estas marcas de tiempo a los tramos de llamada, lo que proporciona a las herramientas de BI una comprensión nativa de la secuencia y la duración. No se necesitan ajustes.

Avance #5: Creado para Crecer

Heredado: Las configuraciones multi-tabla eran rígidas – las nuevas características significaban una completa dispersión del esquema.
Nuevo: cdr_output es una tabla única y expandible: agregue una columna y el sistema se adaptará.
Impacto:

• Escala a Prueba del Futuro: Crece con el plan de trabajo de 3CX sin sobrecarga relacional.
• Eficiencia Operativa: Una tabla para indexar, replicar o particionar, diseñada para ser nativa en la nube.

Visión Experta: Los indicadores como processed y migrated agilizan las canalizaciones de datos, lo que permite una integración perfecta con Apache Kafka, AWS Athena o Kinesis y Google BigQuery. El vínculo call_history_id dentro de la tabla acelera las consultas de llamadas relacionadas, manteniendo un rendimiento ajustado y cargas de datos reducidas.

Siguiente Paso – Preparar los Datos para la Nube

Hemos transformado un complejo sistema CDR en una moderna tabla de informes de llamadas escalable. Nuestras pruebas muestran que las consultas son hasta 10 veces más rápidas: menos JOINs, datos más ricos. ¡Feliz Elaboración de Reportes!

Comience con la Actualización 6 Alfa

Para probar estas nuevas funciones, actualice a la V20 Update 6 Alfa.

Únase al debate sobre la V20 en nuestro Foro dedicado a nuestra Central Telefónica. No olvide seguirnos en X y LinkedIn para estar al tanto de las novedades de 3CX.