Especialização · Telefonia e contact center
Construímos a central: trunks SIP, regras de encaminhamento por horário, menus IVR lidos da base de dados, filas de espera, transferência para um humano, gravação e análise das chamadas. A chamada torna-se um registo com transcript e resumo, não uma memória.
Já construídoTrês implementações próprias, citadas abaixo. (1) A camada Asterisk na plataforma Kallina: 5.522 linhas de configuração de dialplan, scripts AGI e pontes de áudio em `asterisk/`, além de modelos de trunk gerados automaticamente por número. (2) `asterisk-manager` — um serviço separado que administra filas, trunks e o fluxo RTP através da interface de gestão da central. (3) O middleware para a central virtual de um operador, que correu em produção: o commit de reconciliação de 14 de julho de 2026 traz para o repositório código que tinha corrido no servidor e estava cerca de 40 dias à frente do git. A reserva, dita antes de perguntar: o anfitrião SIP pelo qual passam as nossas linhas de teste não responde — verificado hoje, 06.09.2026, sem resposta ao ping e sem resposta no HTTP. Não apresentamos um número de demonstração para ligar agora, porque não o poderíamos colocar em funcionamento diante de você.
Entre o seu operador de telefonia e quem responde efetivamente — uma pessoa ou um agente vocal — tem de existir uma camada que toma decisões. Quem recebe a chamada às 23:40. O que acontece se ninguém responder. Para onde vai a chamada quando o cliente pede «uma pessoa». O que fica da conversa depois de ela terminar. Esta camada é uma central, e nós construímo-la para ser da empresa, não do fornecedor de voz: se amanhã mudar o motor do agente, as regras de routing, as filas e o histórico continuam consigo.
Concretamente, o que construímos: doze ficheiros de dialplan — produção, IVR, fila, transferência, voicemail, redirecionamento, chamadas de saída com agente — quatro scripts AGI em Python e duas pontes de áudio, no total 5.522 linhas. O motor de IVR não tem os menus escritos no ficheiro: lê-os da base através de um script AGI e devolve uma de seis decisões — para um agente, para outro menu, para uma fila, transferência para um número externo, mensagem final, ou encerramento. As filas têm o nome do respetivo identificador e não têm membros escritos na configuração: são adicionados e removidos do exterior, através da interface de gestão, o que significa que um operador pode entrar ou sair da fila sem reiniciar a central.
O encaminhamento tem regras reais, não apenas um único «ligue aqui»: horários de funcionamento e fuso horário, funcionamento nocturno do tipo 22:00 → 06:00, e correspondência por prioridade — o cabeçalho SIP `Diversion`, que transporta o número original de onde a chamada foi reencaminhada, depois o próprio número, depois a regra de reserva. Os trunks são gerados por número, com nome construído a partir do fornecedor e do número, por uma função de configuração — não escritos à mão em cada nova linha.
O que sai da chamada é tão importante como a chamada. Para a linha ligada à central virtual de um operador, construí um middleware em Python que consulta a lista de registos a cada minuto, com uma reconciliação ampla a cada seis horas para que uma falha de rede não perca nada, e uma varredura a cada três minutos das chamadas perdidas — essas não têm registo e, de outro modo, seriam completamente invisíveis. Cada registo é descarregado, transcrito, analisado e espelhado na análise de chamadas, e a chamada perdida torna-se um alerta. A idempotência está num conjunto Redis, para que o mesmo registo não seja processado duas vezes.
Qué incluye
Os modelos de trunk são parametrizados e preenchidos por uma função de configuração, com nome formado pelo fornecedor e pelo número. No modelo estão escritos o transporte, os codecs permitidos, o tratamento de NAT, o modo DTMF e a autenticação. A consequência prática: o décimo número liga-se da mesma forma que o primeiro, e as diferenças entre operadores ficam num único lugar.
Horários de funcionamento e fuso horário, funcionamento nocturno do tipo 22:00 → 06:00, correspondência por prioridade: o cabeçalho SIP `Diversion` (o número de onde foi reencaminhada), depois o próprio número, depois a regra de reserva. A procura da regra é feita por um script AGI que pergunta à plataforma durante a chamada, com o seu próprio tempo de espera — portanto, uma regra alterada na interface aplica-se à chamada seguinte, sem reinício.
Para o agente vocal, o áudio passa por uma ponte que converte o codec nos dois sentidos, `g711_ulaw` ↔ `PCM16`. Para as pessoas, a chamada entra numa fila administrada do exterior. E a transferência está ao alcance de quem fala: transferência cega por `##` e transferência assistida por `*2`, com a chamada a aterrar num contexto escrito para isso, que distingue as extensões internas de quatro dígitos dos números externos.
O motor de IVR recebe o identificador do menu e lê-o da base de dados através de um script AGI. O resultado é uma de seis decisões: para um agente, para outro menu (recursivo), para uma fila, transferência externa, mensagem final, encerramento. As mensagens podem ser sintetizadas ou podem ser ficheiros áudio gravados previamente. Alterar um menu significa alterar uma linha na base de dados, não editar um ficheiro de configuração no servidor.
Cada fila leva o nome derivado do seu identificador. Os membros não são persistidos na configuração: são adicionados e removidos durante o funcionamento através da interface de gestão da central, e o posicionamento simultâneo em vários lugares livres está activado. Na prática, um operador entra ou sai da fila sem que a central seja reiniciada e sem que as chamadas em espera sejam afectadas.
Um agente pode telefonar ele próprio para alguém do exterior e voltar com a resposta. O mecanismo é implementado com tabela própria e estados explícitos — a ligar, em curso, a tentar novamente, concluído, falhado, sem resposta, expirado — com no máximo três tentativas e uma pausa de dois minutos entre elas, e o resultado (incluindo o tempo estimado de chegada) volta de forma estruturada para a conversa que o pediu. Não é um conceito: são cinco funções de servidor dedicadas, mais uma varredura das chamadas que ficaram presas.
Um processo agendado lê a lista de registos a cada minuto, com reconciliação ampla a cada seis horas para que uma falha não perca nada. O registo é descarregado em WAV, transcrito, analisado e espelhado na análise de chamadas juntamente com o áudio. Separadamente, a cada três minutos são lidas as chamadas não atendidas — que não têm registo e, de outro modo, não existiriam em lado nenhum — e tornam-se alerta. Uma chamada perdida é um cliente perdido; torná-la visível é a melhoria mais barata num centro de chamadas.
O cliente que fala com a central do operador tem limitador de taxa próprio, com balde de tokens, e tratamento explícito de erros. Não é uma precaução teórica: um middleware que consulta a cada minuto e reconcilia a cada seis horas pode, sem travão, atingir o limite do operador e ser bloqueado precisamente quando precisa dele.
Qué aspecto tiene
Que números existem, em que operadora, quem responde hoje por cada um, em que horário, e o que acontece agora quando ninguém responde. Parece burocracia; é a parte que evita surpresas. Pela nossa experiência, num parque de números há quase sempre linhas em que a base diz uma coisa e a central diz outra — e elas não são descobertas no lançamento, mas sim agora.
O número entra no trunk, e as chamadas recebidas e as efetuadas são testadas como duas coisas distintas, porque se avariam de forma distinta. Temos documentado um caso em que as chamadas recebidas funcionavam perfeitamente durante dias seguidos, enquanto todas as chamadas efetuadas eram rejeitadas pela central da operadora com `403 Forbidden`, sem qualquer alteração da nossa parte. Um único teste “ligou e funcionou” não cobre isto.
As regras de horário e de prioridade, os menus, as filas e os caminhos de transferência são escritos como dialplan e como registos na base, não como entendimento verbal. No final, você sabe exatamente o que acontece com uma chamada às 23:40, ao sábado, quando o agente não entende o pedido.
O resultado da chamada — transcript, resumo, sentimento, endereço da gravação, duração — é enviado em frente por um webhook assinado, e a organização é identificada pelo número de telefone. Onde existe um CRM, a chamada é ligada à ficha e pode alterar automaticamente o estado; sobre esta parte escrevemos na página de CRM e automatização de vendas.
Uma central num único servidor é um único ponto de falha, e nós vivemos exatamente isso: quando o servidor não responde, todas as linhas que passam por ele caem com ele, independentemente de quão bem o agente esteja configurado. A assinatura da falha é clara — a chamada devolve “request timed out” com o identificador de chamada SIP vazio, ou seja, a chamada SIP nunca chegou a estabelecer-se. Por isso, num projeto real, a pergunta “o que acontece quando o servidor cai” é colocada e orçamentada no início: um segundo servidor, monitorização que chama uma pessoa, e um caminho de reserva para números normais.
Os dados
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Un caso
A situação
Num fluxo de análise de conversas, parte das chamadas ia para análise e parte não. O padrão foi o que deu a causa: faltavam exatamente as chamadas longas. Um defeito que é comunicado como «às vezes não funciona» e procurado, erradamente, na transcrição.
Qué construimos
Havia dois caminhos de transcrição e ambos falhavam, por motivos diferentes. O caminho multimodal enviava o ficheiro de áudio completo codificado no corpo do pedido; acima de um certo tamanho, o limite do corpo do servidor intermédio respondia com 413. O caminho de reserva pedia um modelo de transcrição que a chave de acesso já não permitia, por isso respondia com 403. Ambos falhavam, o processo reportava que todos os modelos de transcrição tinham falhado, e a chamada era abandonada. As chamadas curtas ficavam abaixo do limite do corpo, portanto passavam — daí o padrão. A correção foi: saltar o caminho multimodal para ficheiros WAV acima de 12 MB (limiar configurável no ambiente), reutilizar a transcrição já calculada em vez de transcrever uma segunda vez, e a transcrição de última instância foi movida para um modelo permitido.
Qué salió
Verificado na gravação que tinha ficado bloqueada: uma conversa de 21 minutos, ficheiro WAV de 41 MB — o caminho multimodal foi contornado, a transcrição foi obtida, a análise foi gerada, a linha e o áudio chegaram à análise de chamadas, zero falhas. A reconciliação confirmou depois que já não existem outras gravações bloqueadas.
Qué no dice el caso
O limiar de 12 MB é uma propriedade do servidor intermédio, não da chamada. Quando o gateway, a chave ou o modelo mudam, o limiar tem de ser reverificado — por isso tornámo-lo configurável no ambiente, e não escrito no código.
Perguntas
Não hoje, e preferimos dizer isso do que dar um número que toca em vazio. A parte do agente pode ser ouvida na página, imediatamente. A parte do telefone depende de um host SIP, e o host por onde passam as nossas linhas de teste não responde à data de redação — verificado hoje, sem resposta ao ping e sem resposta por HTTP. Para um seu projeto, a telefonia é levantada num host dedicado ao projeto, não no de teste.
Porque as regras de encaminhamento, as filas, a transferência, o voicemail e o histórico das chamadas são do negócio, não do fornecedor de voz. Com uma central própria pode mudar o motor do agente sem reescrever o comportamento do seu telefone, pode encaminhar a mesma chamada ora para um agente, ora para uma pessoa, e pode manter o registo das chamadas consigo. Sem ela, fica preso ao que o fornecedor decide expor.
Caem todas as linhas que passam por ele. Não é hipótese: foi o que vivemos, e a assinatura é fácil de reconhecer — a chamada devolve «request timed out» com o identificador de chamada SIP vazio, portanto não é culpa do agente, do número ou do prompt. A conclusão que tirámos e que agora aplicamos em cada projeto: a continuidade não é uma função da central, é uma decisão de arquitetura e de orçamento, tomada no início. Resolve-se com um segundo host e com uma rota de reserva para números normais, não com uma definição.
Não. São duas coisas diferentes, e o operador pode tratá-las de forma diferente. Temos documentado um caso em que, com a nossa configuração inalterada e com as chamadas recebidas funcionais, a central do operador começou a recusar todas as chamadas efetuadas com `403 Forbidden` — a prova de que era do lado do operador foi que uma segunda conta, com configuração estruturalmente idêntica, continuava a ligar para fora. Por isso não prometemos uma campanha de chamadas efetuadas antes de um teste de saída bem-sucedido no seu número.
Sim, e fizemo-lo: escrevemos um middleware em Python sobre a API de uma central virtual de operador, com cliente próprio, limitador de taxa, descarregamento de gravações, transcrição, análise e alertas, em execução em produção. O que é preciso saber de antemão: o acesso à API alargada é muitas vezes um serviço separado, contratado à parte, e as credenciais podem não funcionar à primeira tentativa — no nosso caso, o ciclo de esclarecimento da especificação e de reposição da palavra-passe com o operador durou meses, com o serviço já faturado. Por isso, numa proposta que dependa da API de um operador, colocamos explicitamente a condição: o trabalho começa depois de a autenticação ter sido demonstrada, não depois de ter sido prometida.
Podem ser gravadas, transcritas e analisadas. Permanecem ligadas ao espaço de trabalho do seu negócio, e o acesso exige autenticação — não existe um depósito comum entre clientes. Quem da sua equipa tem direito de escuta é definido na implementação. O aviso ao interlocutor e a base da gravação são decisões suas como operador de dados; escrevemo-las no сценарio, não as presumimos.
São o caso pior tratado na maioria das empresas, porque não deixam rasto: não há gravação, não há transcrito, existe apenas no registo de chamadas. Para nós, um processo lê o registo a cada três minutos, identifica as chamadas não atendidas e transforma-as em alerta e em linha visível. Para ficar claro de que depende: só as vemos na medida em que o operador as expõe no seu registo.
Sim, e os menus ficam na base, não em ficheiros no servidor. O motor lê a configuração do menu durante a chamada e decide um de seis caminhos: para um agente, para outro menu, para uma fila, transferência para um número externo, uma mensagem final, ou encerramento. As mensagens podem ser sintetizadas ou gravadas de antemão. Na prática, uma alteração de menu não exige intervenção na central.
Por reconciliação, e é uma peça que construímos explicitamente. A consulta rápida tem uma janela de algumas dezenas de horas, e por cima disso corre a cada seis horas uma reconciliação numa janela de uma semana, que relê várias páginas de resultados. Cada registo processado é marcado, portanto a releitura não duplica nada. Sem reconciliação, uma falha de uma hora significa um buraco permanente nos dados — e ninguém o nota.
22 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.
Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.