12 coisas que o contact center resolve no discador e deveria resolver no SBC

Detecção de caixa postal, rotação de CallerID, bloqueio dinâmico, failover de operadora, gravação e transferência. Tudo isso é configuração de borda, não integração de discador, e o SipPulse SBC entrega os doze itens no mesmo servidor.

O problema quase nunca está no discador

Um contact center bem montado tem discador, CRM, gravador, plataforma de URA, ferramenta de monitoria e, cada vez mais, um agente de voz com IA. Cada um desses sistemas foi comprado para fazer bem uma coisa. Entre todos eles e a operadora existe uma camada que quase ninguém trata como produto: a borda de voz. É por ela que passa 100% das chamadas, em ambos os sentidos, antes de qualquer outra coisa acontecer.

Quando essa camada não faz o trabalho dela, o trabalho não desaparece, ele é empurrado para cima. Vira um detector de secretária eletrônica embutido no discador, que ninguém confia e todo mundo desliga. Vira uma planilha de números de origem que alguém rotaciona na mão toda segunda-feira. Vira um script no PABX que reescreve o número porque a operadora nova quer com o zero e a antiga queria sem. Vira um gravador por sistema, porque cada plataforma grava do seu jeito. Vira um chamado aberto na operadora que ninguém consegue provar, porque o CDR do discador e o CDR da operadora contam histórias diferentes.

Nada disso é problema de discador. É problema de borda resolvido no lugar errado, e o preço aparece em três lugares: tempo de agente desperdiçado, taxa de atendimento em queda e uma topologia com mais caixas do que a operação consegue monitorar.

Este artigo percorre doze funções que o SipPulse SBC executa na borda, na ordem em que uma chamada as encontra. Todas são configuração de tela, ligadas por rota, e todas rodam no mesmo servidor.

Sete de cada dez atendimentos não têm ninguém do outro lado

Numa operação real analisada pela SipPulse, 7 de cada 10 chamadas atendidas não tinham uma pessoa do outro lado. Caixa postal, anúncio gravado, URA de operadora, número inválido. O agente ouve, entende que não é ninguém, desliga e disca de novo. Vinte, trinta, quarenta segundos por vez, dezenas de vezes por dia.

O CPA, de Call Progress Analysis, é a análise que decide, pelo áudio, se quem atendeu é uma pessoa. O modelo é próprio da SipPulse, treinado com chamadas reais de operação brasileira, e acerta 94% na identificação de caixa postal usando só o áudio, sem depender do código de causa da operadora, número que passa de 99% quando a sinalização entra na conta. Ele distingue seis situações, não duas, e cada uma abre uma ação diferente: conectar o agente, deixar recado com callback, encerrar e registrar, ou marcar o número como inválido e limpar a base na primeira tentativa.

Para este artigo, o que importa é onde ele roda: dentro do SBC, no caminho da chamada, aproveitando o áudio que já passa por ali. Não é um contêiner à parte, não é um balanceador na frente, não é stream de áudio saindo da rede do cliente. É um perfil vinculado à rota, ligado na campanha de prospecção fria, desligado no tronco de carteira, sem tocar no discador. E o comportamento em falha é sempre fail-open: se a análise ficar indisponível ou estourar o timeout, a chamada conecta.

A história completa do CPA já está contada em outro artigo: o benchmark de mil análises simultâneas em 8 vCPU, a tabela de leads interrompidos por modo de operação, a diferença entre os modos passivo e ativo, e por que a arquitetura anterior exigia um contêiner a cada 20 chamadas. Leia em Novo CPA, de um contêiner a cada 20 chamadas para mil análises em 8 vCPU.

O bloqueio que aprende com o resultado da própria chamada

Lista de bloqueio todo mundo tem. O diferencial está na lista que se atualiza sozinha, a partir do que aconteceu na chamada anterior.

O SBC trata as duas frentes. A lista fixa é o caso conhecido: números que não podem ser discados ou não podem ligar, verificados contra a origem, contra o destino ou contra ambos, rejeitados na hora com código e motivo SIP definidos por você. É onde entra o "não perturbe" da operação, a lista de reclamantes e os números que o jurídico mandou parar de discar.

As regras dinâmicas são a parte que muda o jogo. O SBC observa o desfecho de cada chamada para um número de destino e bloqueia sozinho quando um padrão se repete:

Cada regra tem o seu próprio mínimo de ocorrências e a sua própria duração de bloqueio em minutos. Ultrapassou o limite, o número entra em bloqueio e sai sozinho quando o prazo expira. Antes de qualquer verificação, os números são normalizados internamente, com DDD, sem DDD, com prefixo de operadora, tudo cai no mesmo bloqueio, o que impede o truque mais banal de contornar uma lista.

A contagem e a expiração rodam numa camada de estado em memória, consultada em tempo de chamada. Isso é uma decisão de desempenho: a verificação acontece antes de a chamada sair para a operadora e não pode custar latência mensurável no PDD.

Tudo fica visível numa tela de monitor: quem está bloqueado agora, qual regra disparou, quanto tempo falta, e um botão para desbloquear na hora. O histórico registra cada decisão, para quando alguém perguntar por que aquele número parou de ser discado.

O número que aparece no celular do cliente

Taxa de atendimento em campanha ativa é função direta do número que aparece na tela. Um número que discou dez mil vezes na última semana está marcado, pelo aplicativo de bloqueio do celular, pela operadora, e pelo próprio cliente que já reconhece. Rotacionar é obrigatório, e rotacionar na mão não escala.

O SBC mantém listas de números de origem, importadas por CSV em massa, e faz o sorteio na hora da chamada. Três comportamentos importam:

Sorteio com afinidade de DDD. O SBC prioriza um número de origem com o mesmo código de área do número discado, com fallback para o conjunto geral quando não há. Ligação local tem taxa de atendimento maior que ligação de outro estado, e isso não exige nenhuma lógica no discador.

Limite diário de uso por número. Cada número da lista tem um contador com janela de 24 horas. Atingiu o teto, sai do sorteio até o dia seguinte. É o controle que evita queimar o pool inteiro numa campanha de pico e é o mesmo mecanismo que mantém a operação dentro do padrão de uso que a operadora e os órgãos reguladores esperam de cada linha.

Sorteio no caminho da chamada. O número é escolhido no momento do INVITE, por uma consulta em memória, não por uma chamada de API a um sistema externo. É por isso que a rotação funciona em volume de discador preditivo sem virar gargalo de CPS.

Na prática, a operação sobe uma lista de milhares de números por CSV, define o limite diário e vincula a lista à rota da campanha. O discador continua mandando o mesmo CallerID de sempre, o SBC substitui na saída.

Nota: o SBC não gera números aleatoriamente, eles sempre devem ser importados com base em uma planilha.

Roteamento é onde a operação vira configuração

A tela de rotas é o coração do produto, e não pelo motivo óbvio. Ela casa origem e destino, sim, mas o que a torna central é que todos os recursos avançados são ligados na rota, não na tela deles.

Uma rota tem prioridade de 0 a 99, uma origem (endpoint, grupo de endpoints, ou origem indefinida casada pelo domínio SIP), uma expressão regular para o número discado, outra opcional para o CallerID, e um destino. Até aí é roteamento. O que ela carrega junto é a política inteira daquela chamada: perfil de manipulação, perfil de CPA, perfil de blocklist, lista de CallerID, mídia em bypass ou proxy, entre outros.

A consequência operacional é que política vira granularidade de campanha. CPA ligado na rota de prospecção fria e desligado no tronco de carteira. Rotação de CallerID só na campanha ativa. Blocklist dinâmica agressiva no mailing frio e conservadora na régua de cobrança. Gravação obrigatória na rota de vendas e opcional no suporte. Nada disso exige mexer no discador, e nada disso exige rota nova quando a política muda, é apenas um ajuste no SBC.

Fornecedor cai, e a chamada não

Contact center com uma única operadora é contact center com uma única data de parada. Contact center com três operadoras e nenhuma automação é uma pessoa mudando configuração às pressas durante um problema.

O SBC agrupa endpoints e trata o grupo como destino único, em dois modos:

Balanceador. As chamadas são distribuídas entre os membros proporcionalmente ao peso de cada um. Setenta por cento para a operadora com melhor tarifa, trinta para a segunda. Mudar a divisão é mudar dois números na tela, é assim que se acomoda contrato de volume mínimo sem tocar no discador.

Failover. As chamadas vão para o primeiro membro disponível, na ordem de cadastro. Falhou, a próxima tentativa sai pelo membro seguinte, dentro da mesma chamada. O padrão é transbordar quando não há resposta nenhuma, e uma expressão regular de falha permite ampliar o critério para os códigos SIP que a sua operação considera falha de rota. Um 503 da operadora não é a mesma coisa que um 486 do cliente, e só você sabe onde traçar a linha.

Por baixo dos dois, o SBC monitora cada endpoint com um OPTIONS a cada 30 segundos. Um destino que parou de responder sai da distribuição antes de a próxima chamada tentar por ele, e volta sozinho quando responde de novo. A diferença prática é entre perder uma chamada e perder cinco minutos de campanha.

Há ainda dois limites que evitam o pior tipo de incidente: canais simultâneos e CPS, configuráveis por endpoint e por grupo. Discador preditivo que abre demais não derruba a operadora, ele encontra o teto no SBC, que é onde o teto deve estar. Sem isso, o excesso vira 503 em massa, e o 503 em massa vira transbordo em cascata para o fornecedor de contingência.

Cada operadora quer o número de um jeito

Trocar de operadora deveria ser uma decisão comercial. Na maioria das operações é um projeto, porque o formato do número, o cabeçalho de identificação e o dialeto de sinalização mudam junto, e o único lugar que sabe reescrever isso é o discador ou o PABX.

Os perfis de manipulação movem esse trabalho para a borda. Cada perfil é um conjunto de regras com expressão regular e padrão de substituição, aplicadas ao número de origem, ao de destino, ou aos dois, mais uma lista de cabeçalhos SIP a adicionar ou remover. Adicionar o 55 em quem discou com 0, tirar o prefixo de operadora que o PABX insiste em mandar, injetar o cabeçalho proprietário que a operadora exige para tarifar o serviço certo: tudo isso é uma linha de regra, vinculada à rota daquele fornecedor.

No cadastro do endpoint há a outra metade do problema, a compatibilidade de sinalização:

A soma disso é o argumento comercial mais direto do produto: homologar uma operadora nova vira ajuste de perfil, não projeto de integração. E como o perfil é vinculado à rota, a operação pode rodar as duas operadoras em paralelo, com formatos diferentes, durante a transição.

UDP de um lado, WSS do outro, na mesma chamada

Um contact center moderno tem, ao mesmo tempo: uma operadora que só fala UDP na porta 5060, um cliente corporativo que exige TLS e agentes em home office usando softphone no navegador. Esses mundos não se falam diretamente.

O SBC declara perfis SIP, um socket de escuta por interface, com IP, porta e transporte, e converte entre eles de forma transparente:

Uma chamada pode entrar por WSS vindo do navegador do agente e sair por UDP para a operadora, com o SBC fazendo a tradução de transporte e, quando necessário, a de criptografia de mídia: SRTP de um lado, RTP puro do outro. Cada perfil ainda aceita um endereço externo de advertise para atravessar NAT e marcação de QoS por T.O.S.

Isso é o que permite duas coisas que a operação normalmente considera projetos separados: colocar agentes em casa sem VPN e sem hardware, e atender o cliente que exige criptografia fim a fim na sinalização sem trocar de PABX. A mesma borda, os mesmos endpoints, o mesmo plano de rotas.

A transferência que some no meio do caminho

Chamada de contact center raramente termina onde começou. Entra pela URA, é distribuída para um DAC, o agente atende, qualifica e transfere, para outro DAC, para o supervisor, para um ramal do cliente, às vezes para um número externo. Cada uma dessas transferências é uma requisição REFER, e é onde as coisas quebram.

Quebram de três formas conhecidas. A operadora não aceita REFER e a transferência simplesmente falha. A transferência funciona, mas a gravação para na perna original e o trecho novo não é gravado. Ou a transferência funciona e grava, mas o CDR registra duas chamadas independentes, e ninguém consegue reconstruir o atendimento inteiro para a monitoria.

O SBC resolve isso interceptando a transferência em vez de repassá-la. Com o modo B2B ativo na rota, o SBC atua como agente de usuário completo nas duas pontas: recebe o REFER, executa a transferência em nome dele estabelecendo a nova perna, e entrega no destino uma chamada comum, que qualquer operadora entende. Quem está fora nunca vê o REFER, nunca vê a topologia interna, e nunca precisa suportar um recurso que muitos troncos não suportam.

O áudio passa por aqui, e isso é a vantagem

A borda é o único ponto da rede que vê 100% do áudio, em ambos os sentidos, de todas as chamadas: as que entram, as que saem, as transferidas e as que o discador abriu por engano. Duas funções aproveitam isso.

Gravação por SIPREC, independente de quem faz a chamada

Ligar o SIPREC é marcar uma opção na rota e apontar o gravador, cadastrado como um endpoint qualquer. O SBC passa a duplicar o áudio da chamada para o servidor de gravação usando o padrão SIPREC, com os metadados da sessão junto.

O que isso muda na prática: a gravação deixa de ser função do discador, da URA ou do PABX e passa a ser função da borda. Um único gravador atende todas as plataformas da operação, inclusive as que não têm gravação nativa.

A duplicação acontece no mesmo motor de mídia que já está tratando a chamada, sem hop adicional na rede e sem um segundo elemento para dimensionar.

Transcodificação onde precisa, e só onde precisa

O SBC é transparente a codecs por padrão: se os dois lados se entendem, o áudio passa sem ser tocado. Quando não se entendem, a operadora só aceita G.729, o agente no navegador manda Opus, o agente de voz com IA quer G.722, o SBC transcodifica, e você escolhe entre adicionar codecs à oferta ou forçar a lista, com a prioridade definida arrastando os codecs na tela.

O ponto de arquitetura aqui é o que não transcodifica. Cada rota declara se a mídia vai em bypass, só a sinalização passa pelo SBC e o áudio vai direto entre as pontas, ou em proxy, com o áudio atravessando o SBC. Transcodificação, gravação, criptografia de mídia e CPA exigem proxy; interconexão simples entre redes que se enxergam, não. Escolher isso por rota é a diferença entre dimensionar o servidor para a operação inteira e dimensioná-lo apenas para a fração que realmente precisa de tratamento de mídia.

O CDR que fecha a conta com a operadora

Quase toda operação tem dois números de minutagem que não batem: o do discador e o da fatura. A discussão que se segue é sempre a mesma, e sempre termina sem prova.

O CDR do SBC existe para ser essa prova, porque é gerado no ponto que vê os dois lados. São quase trinta variáveis, e a ordem das colunas do CSV é definida arrastando os campos na tela, o que significa que o arquivo pode sair no layout que o seu billing já lê, sem conversor no meio. A rotação é diária ou mensal, e os arquivos ficam disponíveis para download pela própria interface.

O que vale destacar não é a lista inteira, é o subconjunto que responde perguntas de operação:

Doze funções, um servidor, uma tela

No SipPulse SBC é um servidor, configurado por uma interface web, sem acesso SSH para operar nada, com dashboard de chamadas e recursos em tempo real, exportação de métricas para o monitoramento que a operação já usa, captura de pacotes e ping/traceroute pela própria tela para o time de suporte, backup agendado, log de auditoria de quem mudou o quê, e replicação de configuração para um segundo nó.

E o número que amarra o argumento é o do benchmark do CPA: 1.000 análises simultâneas, com 2.000 canais no ar, em 8 vCPU, a 30% de CPU. Toda a lista acima roda no mesmo lugar, no mesmo caminho de mídia, sem hop extra e sem stream de áudio saindo da rede do cliente. Isso não é otimização, é a consequência de tratar a borda como um produto em vez de um conjunto de integrações.

A conta, e o convite

O custo de não ter essa camada não aparece numa linha do orçamento, ele aparece diluído. Aparece no tempo de agente gasto com caixa postal. Aparece na taxa de atendimento que cai porque o pool de CallerID queimou. Aparece no mailing que é rediscado por meses porque ninguém marcou o número como inválido. Aparece na semana de projeto para homologar uma operadora nova. Aparece na fatura que não bate e ninguém contesta.

Faça a aritmética com os seus números. Numa operação ilustrativa de 20 mil discagens por dia, com 25% de atendimento e 70% desses atendimentos sendo máquina, são 3.500 atendimentos por dia sem ninguém do outro lado, a cerca de 25 segundos cada, perto de 24 horas de tempo de agente por dia. Encerrando em cerca de 1 segundo, quase tudo isso volta. Os 20 mil, os 25% e os 70% são exemplo ilustrativo: troque pelos números da sua operação.

A avaliação não exige mudar nada. O SBC entra em paralelo, o CPA roda em modo passivo medindo lado a lado com o detector que você usa hoje, e a operação segue como está. Você sai com um número próprio: quantas horas de venda a sua operação perde por dia, e quantas das doze funções acima você está pagando para manter espalhadas.

sippulse.com · docs.sippulse.ai · info@sippulse.com · +55 48 3332-8540