Novos Registros de Dados de Chamadas – Análise Completa

Grande atualização do sistema de registros de dados de chamadas (CDR) na 3CX.

Após o lançamento do V20 Update 6 Alpha recentemente, este post explica o novo sistema de registros de dados de chamadas (CDR) no 3CX, onde simplificamos o CDR em uma única tabela: cdr_output. Desmembramos a estrutura antiga, revelamos o novo design e destacamos os ganhos técnicos que estão transformando o funcionamento dos dados de chamadas. Continue lendo para obter todos os detalhes.

A Configuração Legada: Um Gargalo Fragmentado

Originalmente, os dados de CDR/chamadas da 3CX eram divididos em quatro tabelas: cl_calls, cl_participants, cl_party_info e cl_segments. Cada uma delas armazenava elementos distintos do ciclo de vida da chamada: registros de data e hora, dados dos participantes e detalhes de encaminhamento, o que forçava a realização de SQL JOINs complexos para reunir um registro completo. Esse design de várias tabelas aumentava a sobrecarga de consultas e prejudicava o desempenho na geração de relatórios. Para análises em escala de nuvem ou relatórios em tempo real, a estrutura simplesmente não conseguia acompanhar o ritmo.

A Nova Abordagem: cdr_output

Nós reformulamos isso no cdr_output, uma solução de tabela única que consolida todos os dados de chamadas em uma tabela eficiente. Registros de data e hora, participantes, encaminhamento e resultados – tudo está unificado, eliminando a necessidade de JOINs. O JOIN é necessário apenas para os dados de registro, que agora estão em sua própria tabela cdr_recordingsout. Na 3CX, sempre fomos capazes de escalonar para milhares de usuários. Essa arquitetura enxuta fortalece ainda mais nossa escalabilidade, reduz a complexidade, aumenta a velocidade de consulta e prepara a 3CX para análises prontas para a nuvem. Trata-se de uma reformulação ousada da engenharia de dados, desenvolvida para oferecer precisão e potência.

Avanço nº 1: Todos Os Seus Dados Em Uma Tabela Inteligente

Legado: JOINs de várias tabelas reduziam o desempenho – uma verdadeira dor de cabeça para obter informações sobre as chamadas.
Novo: o cdr_output reúne tudo – origem, destino, registros de data e hora, resultados – em uma tabela compacta. Ela é plana e simples, eliminando a desordem relacional para que os analistas de BI possam acompanhar facilmente os fluxos de chamadas.

Por Que É O Máximo:

Consultas mais rápidas: Abandona a complexidade de várias tabelas em favor da velocidade de uma única tabela – as consultas são escalonadas sem problemas, independentemente do tamanho dos dados.
Pronto para a nuvem: Desliza diretamente para data lakes ou ferramentas de BI – sem necessidade de preparação adicional.
Ganho do analista: Os caminhos das chamadas são claros e rápidos de rastrear, poupando horas de incômodo.

Tecnologia de Ponta: os índices em cdr_id e call_history_id turbinam o PostgreSQL para pesquisas extremamente rápidas, mesmo com conjuntos de dados enormes. Manter os links call_history_id na tabela reduz a sobrecarga de SQL, aumenta a velocidade e reduz o inchaço dos dados.

Avanço nº 2: Cada Linha Conta Uma História

Legado: Metadados rasos deixavam os analistas de relatórios em dúvida – por que uma chamada falhou? Onde está o contexto? Quem transferiu para quem?
Novo: o cdr_output incorpora um rico conjunto de atributos:

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

Impacto:

• Clareza Total: Cada linha é uma história completa – não é mais necessário juntar pistas.
• Insights Mais Inteligentes: Potencializa KPIs como taxas de drop ou estatísticas de fila, sem necessidade de trabalho extra.
• Fim do Jogo Explicado: Veja instantaneamente como, por que, quando e quem encerrou uma chamada.

Tecnologia de Ponta: termination_reason_details alimenta a análise pontual (pense em SQL GROUP BY do Grafana ou PowerBi), enquanto o cdr_id baseado em UUID agora é o padrão GUID 00000000-01db-87c1-1bab-07aa0000000d para permitir que as ferramentas de BI identifiquem a data-hora e a ordem da chamada imediatamente. Está tudo lá – como uma chamada começou, se moveu e terminou.

Avanço nº 3: Quem Está Ligando Para Quem, De Forma Simples

Legado: As funções dos participantes eram mal definidas – origem vs. destino exigiam inferência entre tabelas, adivinhação, operações aninhadas, JOINS múltiplos e problemas de desempenho.
Novo: o cdr_output domina os emaranhados de SQL JOIN anteriores com uma série de recursos de divisão limpa:

• source_participant_id (usado para rastreamento)
• source_participant_phone_number (por exemplo, “+1305305305”)
• destination_dn_name (por exemplo, “Dana White”)
• Sinalizadores como source_participant_is_incoming e destination_participant_is_already_connected