Resumo executivo

Quando alguém diz que “a ligação ficou ruim”, a primeira resposta não deve ser trocar codec, mexer em jitter buffer ou culpar a operadora. A primeira resposta deve ser: qual tipo de ruim?

Uma chamada que não completa é um problema de sinalização ou roteamento. Uma chamada que completa, mas fica sem áudio, aponta para caminho de mídia, NAT, firewall ou RTP. Já uma chamada que completa, tem áudio nos dois sentidos e mesmo assim soa ruim entra no território de qualidade de mídia.

Nesse terceiro caso, a maior parte dos incidentes cai em cinco áreas: perda de pacotes, jitter, latência, codec/transcodificação e eco. Cada uma tem assinatura auditiva, evidência técnica e correção diferentes.

Primeiro: qual é o problema correto?

Em operação de voz, tentativa-e-erro custa caro. Alterar tudo ao mesmo tempo pode mascarar a causa raiz e criar novos sintomas. O caminho mais seguro é coletar a chamada afetada, ler os indicadores de mídia e separar a reclamação por categoria.

• Perda: pacotes RTP ausentes ou descartados.
• Jitter: pacotes chegam em cadência irregular.
• Latência: a conversa fica atrasada, mesmo com áudio limpo.
• Codec/transcodificação: a rede parece boa, mas a voz fica metálica, oca ou estreita.
• Eco: uma parte ouve a própria voz retornando.

1. Perda de pacotes

Voz é tempo real. Um pacote RTP que não chega no momento certo não será retransmitido a tempo de ser reproduzido. Acima de cerca de 1% de perda sustentada, a degradação já pode ser perceptível; acima de 3%, a chamada tende a ficar difícil de acompanhar.

O usuário descreve como áudio picotando, palavras cortadas, pequenos silêncios ou voz robótica. A evidência deve aparecer em RTCP, CDR de mídia do SBC ou análise RTP no Wireshark.

As causas mais comuns são congestionamento em rota de operadora ou WAN, QoS/DSCP não preservado, microbursts, MTU/fragmentação, flaps de rota ou problemas de LAN/Wi-Fi no endpoint.

A correção passa por validar marcação DSCP, confirmar se ela é respeitada em todos os saltos, testar rota/tronco alternativo, separar filas de voz de tráfego bulk e, quando o problema estiver no acesso local, corrigir a rede do endpoint.

2. Jitter

Jitter não é pacote perdido; é pacote fora de ritmo. Em chamadas com ptime típico de 20 ms, o receptor espera uma cadência regular. Quando a variação aumenta, o jitter buffer tenta absorver. Se não consegue, descarta pacotes atrasados e o sintoma pode parecer perda.

A assinatura audível costuma ser voz instável, subaquática, robótica ou com falhas intermitentes. Como referência prática, abaixo de 20 ms costuma ser confortável; entre 20 e 50 ms depende do buffer; acima de 50 ms a qualidade normalmente cai bastante.

Procure filas variáveis, QoS inconsistente, virtualização sem reserva de CPU, SBC/PBX com starvation de vCPU, assimetria de rota e jitter buffer mal dimensionado. Buffer pequeno demais gera drop; buffer grande demais vira latência.

3. Latência

Latência é diferente: o áudio pode estar limpo, mas a conversa fica ruim. As pessoas se interrompem, falam por cima uma da outra e sentem a chamada “atrasada”.

Acima de 150 ms unidirecional, o desconforto começa a aparecer. Acima de 250 ms, a conversa lembra chamada via satélite. Acima de 400 ms, a experiência tende a ser impraticável.

Os contribuintes são cumulativos: distância geográfica, rota real, codificação/decodificação, transcodificações, jitter buffer, acesso móvel e enlaces de longa distância. A correção vem de reduzir o que está sob controle da operação: transcodificação desnecessária, política de codec, posição regional do SBC e ajuste de buffer.

4. Codec e transcodificação

Às vezes perda, jitter e latência estão bons, mas o áudio ainda parece ruim. Nesse caso, o suspeito é o codec ou a cadeia de transcodificação.

A voz pode soar metálica, oca, estreita ou com queda clara de fidelidade. Música de espera, ruído de fundo, DTMF in-band e fax costumam sofrer mais em codecs comprimidos ou em cadeias com múltiplas conversões.

A evidência está no SDP, no SIP trace e no CDR: qual codec foi negociado em cada perna? Houve G.711 em uma ponta e G.729 na outra? A chamada passou por mais de um ponto de transcodificação?

O ideal é negociar codec comum sempre que possível, usar política por NAP/tronco e concentrar transcodificação em ponto controlado. Em rotas premium, G.711 fim a fim pode ser preferível à economia de banda quando a qualidade percebida é prioridade.

5. Eco

Eco é frequentemente confundido com rede ou codec, mas vive em outra camada. A parte afetada ouve a própria voz retornando, geralmente com atraso, enquanto a outra parte pode não perceber nada.

As causas clássicas são bordas analógicas, conversões 2 fios/4 fios, gateways TDM/IP, cancelador de eco desabilitado ou mal ajustado, headset ruim e viva-voz aberto. A latência pode tornar audível um eco que já existia em baixo nível.

A correção começa por identificar a perna que introduz a híbrida analógica ou o endpoint problemático, validar cancelador de eco, tail length, ERL/ERLE quando disponível e revisar mudanças recentes que tenham aumentado o atraso no caminho.

Fluxo prático de diagnóstico

1. Coletar horário, origem, destino, rota, NAP/tronco e CDR da chamada.
2. Ler perda, jitter, atraso unidirecional e MOS.
3. Se perda estiver acima do aceitável, investigar caminho de rede e direção afetada.
4. Se jitter estiver alto, investigar fila variável, QoS, virtualização e jitter buffer.
5. Se atraso estiver alto, decompor distância, rota, codec, transcodificação e buffer.
6. Se rede parece boa e MOS está baixo, revisar codec e transcodificação.
7. Se uma parte ouve a própria voz, tratar como eco e procurar borda analógica ou endpoint.
8. Quando CDR/RTCP não fecharem a conta, capturar PCAP no SBC e analisar RTP no Wireshark.

O que o SBC enxerga — e o que não enxerga

O SBC tem excelente visibilidade do que cruza suas interfaces: SIP, RTP, codec negociado, MOS, perda, jitter, atraso, CDR e PCAP. Mas ele não controla todo o caminho fim a fim.

Wi-Fi congestionado, softphone em notebook sobrecarregado, headset com cancelamento ruim, driver de áudio, rede da outra operadora e acesso móvel do usuário final podem estar fora da janela de medição direta do SBC.

Por isso, a função operacional do SBC é dupla: corrigir o que está sob seu controle e produzir evidência suficiente para escalar o que está fora dele. Um chamado com horário, CDR, direção afetada, rota, SIP trace e PCAP tem muito mais chance de avançar do que uma reclamação genérica de “áudio ruim”.

Como a ZICTEC pode apoiar

A ZICTEC atua em diagnóstico de redes de voz, SIP, SBC/ProSBC, interconexão, suporte operacional e preparação de evidências para RCA ou escalação entre operadoras. Em muitos casos, o primeiro passo é revisar rotas, NAPs, CDRs, política de codecs, arquitetura de SBC, exposição SIP e capacidade de captura/observabilidade.

• Site: https://www.zictec.com.br
• WhatsApp: https://wa.me/554732300435
• Reunião: https://www.calendly.com/zictec/reuniao

Resumo executivo

Em muitas redes, o Session Border Controller ainda é lembrado apenas como “firewall de SIP”. Na prática, um SBC carrier grade ocupa uma posição muito mais estratégica: ele normaliza interconexões, protege aplicações, controla roteamento, viabiliza redundância, registra evidências de tráfego, integra serviços de reputação e ajuda a preparar a rede para autenticação de chamadas.

Para quem opera voz em escala — prestadora, integrador, contact center, plataforma UCaaS/CPaaS ou empresa com múltiplos troncos SIP — o SBC vira uma camada de controle operacional da chamada.

1. Peering entre prestadoras: interconexão com mediação e controle

No peering, o SBC fica entre redes de prestadoras, fornecedores wholesale, operadoras regionais, plataformas UCaaS ou outros ambientes de voz. A função não é apenas “passar chamada”: é controlar como o tráfego entra e sai, normalizar comportamento SIP, aplicar políticas e produzir registros que sustentem operação, conciliação e troubleshooting.

Para a ZICTEC, esse caso é especialmente relevante em ambientes com múltiplas interconexões, legados TDM/SS7/SIP-I, rotas nacionais e internacionais, e necessidade de isolar problemas entre rede própria, parceiro e cliente final.

2. Acesso de PMEs e filiais: NAT traversal, registro e escala

Quando uma prestadora entrega telefonia para muitas empresas pequenas, filiais, lojas ou usuários remotos, o problema clássico aparece: telefones atrás de NAT, firewalls diferentes, registros SIP instáveis e centenas ou milhares de endpoints exigindo gestão centralizada.

O SBC ajuda a manter a borda organizada: recebe registros, atravessa NAT, protege o registrar/softswitch e permite operar vários clientes sem expor diretamente a aplicação central.

3. SIP Trunking corporativo: normalizar múltiplas operadoras

Empresas maiores raramente dependem de um único tronco. É comum haver DIDs, 0800, rotas internacionais, contingência e contratos com diferentes operadoras. Cada uma pode trazer particularidades de cabeçalhos SIP, codecs, regras de discagem, tratamento de caller ID e sinalização.

O SBC é a camada onde essas diferenças são normalizadas antes de chegar ao IP-PBX, contact center ou plataforma interna. Além disso, reduz a exposição da aplicação a tráfego malformado e permite políticas de saída por custo, qualidade, disponibilidade ou destino.

4. Redundância: continuidade quando uma peça falha

Redundância em voz não é só ter dois servidores. É preciso que softswitch, SBCs, operadoras e regras de roteamento concordem sobre o que acontece quando uma rota degrada, um provedor sai do ar, um MOS piora ou um equipamento falha.

Com dois SBCs ativos e regras bem definidas, a rede pode redirecionar tráfego automaticamente, reduzindo impacto para o assinante. Esse desenho exige arquitetura, testes e observabilidade — principalmente para evitar cenários em que a contingência existe no papel, mas não assume corretamente na prática.

5. Acesso xCaaS: proteger UCaaS, CPaaS e contact centers

Plataformas de comunicação como serviço precisam receber tráfego de dispositivos remotos, softphones e integrações distribuídas. Em muitos casos, a aplicação principal não deve lidar diretamente com criptografia, NAT traversal e exposição SIP à internet.

O SBC assume a borda segura: termina SIP/TLS quando aplicável, protege a aplicação, organiza o tráfego remoto e permite que a plataforma cresça com menos acoplamento entre segurança de rede e lógica de produto.

6. Trunking xCaaS: conectar aplicações cloud a operadoras

No trunking para UCaaS/CPaaS, o desafio muda de lado: a aplicação em nuvem precisa falar com múltiplas operadoras, DIDs, 0800, rotas internacionais e fornecedores locais.

O SBC fica como camada de interoperabilidade entre o mundo cloud e o mundo de operadoras. Ele controla regras de roteamento, adaptação de sinalização, proteção da aplicação e métricas de qualidade.

7. STIR/SHAKEN e autenticação de chamadas

STIR/SHAKEN adiciona à chamada um elemento criptográfico que permite verificar a legitimidade da origem. Em mercados como EUA e Canadá, essa camada já é usada para combater spoofing e robocalls. No Brasil, a discussão se conecta ao movimento regulatório da Anatel para autenticação e identificação de chamadas e à iniciativa comercial de Origem Verificada.

Aqui é importante separar conceitos:

• STIR/SHAKEN é a camada técnica/protocolo de autenticação e verificação;
• autenticação da chamada comprova, dentro do fluxo entre prestadoras, que a origem foi atestada conforme as regras aplicáveis;
• identificação de marca/campanha, como Origem Verificada/Branded Call, é uma camada posterior de exibição e relacionamento com o usuário final.

Um SBC pode participar do fluxo de autenticação/verificação, integrar serviços externos e preservar logs/evidências. Mas a exibição de marca ou logo no terminal depende de regras, homologações, cadastro, rotas e aceite do ecossistema — não deve ser prometida como consequência automática de “ter STIR/SHAKEN”.

8. Proteção contra TDoS e chamadas abusivas

TDoS — Telephony Denial of Service — ocorre quando uma empresa ou prestadora é inundada por chamadas, muitas vezes automatizadas, malformadas ou fraudulentas. O impacto pode ser operacional e financeiro: filas ocupadas, agentes indisponíveis, queda de qualidade e reclamações.

O SBC pode se integrar a serviços de analytics e reputação, enviando informações da chamada para classificação antes de permitir, bloquear, desviar ou colocar em triagem. Essa arquitetura é especialmente útil para contact centers, serviços críticos e prestadoras que precisam reduzir tráfego abusivo antes que ele chegue ao cliente.

9. Borda inteligente: filtrar antes de chegar ao core

Nem toda inteligência precisa ficar no core. Em clientes com alto volume de discagem, filiais críticas ou equipamentos locais com tráfego intenso, colocar função de SBC na borda pode reduzir carga no core e tratar problemas antes que contaminem a rede central.

Esse desenho pode ser útil para varejo, cobrança, operações distribuídas e cenários em que uma única filial ou aplicação gera volume desproporcional de chamadas.

10. Habilitação de CPaaS: SIP para aplicações e media bypass

Aplicações CPaaS precisam conversar com operadoras reais. Isso exige troncos SIP, normalização, segurança, roteamento e, muitas vezes, desenho para evitar custo excessivo de mídia em nuvem.

Em alguns cenários, o SBC controla a sinalização enquanto a mídia segue por caminho mais direto, reduzindo custo de tráfego em cloud. Esse tipo de arquitetura exige cuidado: segurança, NAT, codecs, gravação, compliance e troubleshooting precisam continuar observáveis.

Quando avaliar um SBC/ProSBC na sua operação

Considere uma revisão de arquitetura quando a rede apresenta um ou mais sinais abaixo:

• múltiplas operadoras ou rotas SIP com comportamento diferente;
• IP-PBX, softswitch ou contact center exposto demais à internet ou a parceiros;
• falhas de NAT, registro SIP ou áudio unidirecional em clientes remotos;
• necessidade de contingência real entre SBCs, softswitches e carriers;
• crescimento de tráfego abusivo, robocalls ou chamadas malformadas;
• preparação para autenticação de chamadas, STIR/SHAKEN ou Origem Verificada;
• desejo de conectar aplicações cloud/CPaaS a operadoras com controle de custo e mídia;
• dificuldade de provar causa raiz por falta de logs e evidências de borda.

Como a ZICTEC pode apoiar

A ZICTEC atua em projetos de voz IP, SIP, ProSBC, interconexão, suporte operacional e preparação para autenticação/identificação de chamadas. O trabalho pode começar por um diagnóstico técnico-comercial da arquitetura atual: rotas, SBCs, softswitches, pontos de falha, logs, regras de roteamento, exposição SIP, redundância e roadmap para novos serviços.

• Site: https://www.zictec.com.br
• WhatsApp: https://wa.me/554732300435
• Reunião: https://www.calendly.com/zictec/reuniao

STIR/SHAKEN nasceu como resposta a um problema de confiança.

Durante anos, redes telefônicas permitiram que a identificação de origem da chamada fosse manipulada com relativa facilidade. Isso abriu espaço para spoofing, robocalls, golpes, chamadas abusivas e degradação da confiança do usuário no telefone.

Nos Estados Unidos e Canadá, o volume de chamadas fraudulentas acelerou a adoção de mecanismos técnicos e regulatórios para autenticar a origem das chamadas. É nesse contexto que surgem STIR e SHAKEN.

STIR e SHAKEN: de onde vêm os nomes

STIR vem de Secure Telephone Identity Revisited, um conjunto de especificações ligado ao IETF para identidade segura em chamadas. SHAKEN é o framework operacional usado principalmente em redes IP de operadoras, com governança, certificados e procedimentos para aplicar a autenticação em escala.

Em termos simples: STIR/SHAKEN permite assinar e verificar informações de origem da chamada, ajudando a indicar se aquele tráfego veio de uma fonte autorizada ou confiável.

Evolução internacional

Nos EUA, a FCC pressionou operadoras a adotarem autenticação de chamadas como parte do combate a robocalls. No Canadá, a adoção também avançou com regulação e governança setorial. A tecnologia não eliminou fraude sozinha, mas criou uma camada essencial de rastreabilidade e confiança.

Com o tempo, o tema deixou de ser apenas técnico. Passou a envolver reputação de chamadas, analytics, políticas de bloqueio, identificação de marca e experiência do usuário na tela do telefone.

Adoção no Brasil

No Brasil, o tema evolui conectado ao combate a chamadas abusivas, à identificação de chamadas e ao ecossistema operacional envolvendo Anatel, operadoras e entidades setoriais. A iniciativa de Origem Verificada amplia a conversa: não basta autenticar tecnicamente; empresas querem que o usuário reconheça quem está chamando.

Mas é fundamental separar as camadas. Autenticação e identificação de marca não são a mesma entrega.

Três camadas que não devem ser confundidas

• STIR/SHAKEN: protocolo/camada técnica de autenticação.
• Autenticação de chamadas: operação que permite trafegar chamadas com validação conforme regras, certificados, rotas e arquitetura.
• Origem Verificada / Branded Call: identificação visual/comercial da marca ou campanha, dependente de critérios, governança, homologação, credenciais, rotas e aceite.

Tendências

• Maior pressão contra spoofing e chamadas abusivas.
• Integração entre autenticação, reputação e analytics.
• Demanda de empresas por identificação confiável na tela do usuário.
• Operadoras precisando preparar SBC, rotas, logs e evidências.
• Separação comercial entre autenticar a chamada e exibir marca/campanha.

O que não devemos prometer

Não se deve prometer logo na tela apenas porque existe STIR/SHAKEN. A exibição de marca depende de uma etapa própria e de aceite operacional/comercial. O papel correto é preparar a base técnica, autenticar quando aplicável e evoluir para Origem Verificada conforme regras e viabilidade.

Gancho comercial

A ZICTEC pode apoiar operadoras em diagnóstico, escolha de arquitetura, integração com SBC/ProSBC ou API, testes, evidências, operação assistida e preparação para a jornada de Origem Verificada sem misturar promessa técnica com promessa comercial.

O problema real: muitas prestadoras sequer apresentam DETRAF.

Em operações de menor porte, é comum o DETRAF ser tratado como uma cobrança recebida — não como uma rotina ativa de conciliação. A prestadora recebe demonstrativos de outra operadora, paga o que foi cobrado e raramente confere tecnicamente se aquele valor está correto.

O prejuízo aparece em duas frentes: a empresa pode pagar a mais por divergência de classificação, tráfego ou rota; e também pode deixar de receber valores que teria direito a cobrar, simplesmente porque não apresenta seu próprio DETRAF ou não sustenta a conciliação com evidências.

DETRAF não é só burocracia: é margem operacional.

O Detalhamento de Tráfego entre operadoras conecta engenharia, faturamento e backoffice. Quando ele não existe, ou quando é feito de forma frágil, a operação deixa dinheiro na mesa. Em telecom, uma diferença pequena repetida todos os meses vira custo estrutural invisível.

Onde o dinheiro escapa

• Pagamento cego: aceitar a cobrança de outra operadora sem confrontar com CDRs próprios.
• Ausência de apresentação: não cobrar tráfego que deveria ser cobrado da outra parte.
• Classificação incorreta: chamadas locais, longa distância, móvel/fixo ou rotas tratadas de forma diferente entre as partes.
• Portabilidade e BDO: eventos de portabilidade não refletidos corretamente na rota e no cálculo.
• Falta de evidência: sem dados consistentes, a contestação perde força.

Por que isso acontece nas pequenas e médias

Muitas prestadoras cresceram com foco em rede e cliente final, não em backoffice de telefonia. O conhecimento de DETRAF fica concentrado em uma pessoa, em planilhas ou em rotinas manuais. Quando há troca de equipe, mudança de fornecedor ou aumento de tráfego, a fragilidade aparece.

Como uma rotina madura deveria funcionar

• Geração recorrente de DETRAF com CDRs íntegros.
• Conciliação entre tráfego próprio, cobrança recebida e valores a apresentar.
• Critérios claros de cálculo, classificação e contestação.
• Backoffice documentado para envio, acompanhamento e negociação.
• Histórico de evidências para auditoria, divergência e revisão.

O papel da tecnologia e do backoffice

A ZICTEC possui solução para DETRAF em plataformas já homologadas, com possibilidade de customização conforme o cenário da prestadora. Além da parte técnica, também é possível apoiar a rotina burocrática/backoffice: apresentação, conferência, conciliação, organização de evidências e acompanhamento do ciclo.

Gancho comercial

Se a prestadora hoje apenas paga o que recebe, sem conferir e sem apresentar seus próprios valores, o primeiro passo não é uma landing page: é um diagnóstico. Mapear tráfego, fontes de CDR, cobranças recebidas e valores não apresentados pode revelar economia e receita recorrente antes invisíveis.

SIP-I não é “SIP normal com outro nome”.

Uma interconexão SIP comum costuma tratar sinalização VoIP entre plataformas IP. SIP-I é diferente: ele carrega informações ISUP dentro de mensagens SIP, preservando elementos importantes da sinalização tradicional usada nas redes legadas. Na prática, é uma ponte entre o mundo IP e o legado SS7/ISUP.

Por isso, uma interconexão SIP-I exige atenção a perfil, parâmetros, interoperabilidade e homologação. Não basta “abrir um trunk SIP”.

ISUP, SS7 e a evolução para SIP-I

Historicamente, redes de telefonia usaram SS7 como arquitetura de sinalização, com ISUP para controle de chamadas. Com a migração para IP, surgiu a necessidade de transportar essa lógica em redes SIP sem perder informações relevantes para interconexão entre operadoras.

O SIP-I encapsula conteúdo ISUP em SIP, permitindo que redes modernas IP conversem com requisitos e semântica herdados do ambiente de telefonia tradicional.

Versões e perfil adotado no Brasil

Existem variações e perfis de implementação. Para funcionar em uma interconexão real no Brasil, a operadora precisa seguir o perfil específico aceito pelas partes e adotado no ecossistema nacional. Diferenças aparentemente pequenas em ISUP, cabeçalhos, parâmetros, timers ou tratamento de causas podem impedir completamento, afetar tarifação ou dificultar portabilidade e roteamento.

Novas interconexões e o movimento para SIP-I

Na prática de mercado, novas interconexões vêm sendo estruturadas em SIP-I, substituindo gradualmente modelos TDM/legados. Isso reduz dependência de infraestrutura tradicional, mas aumenta a exigência sobre SBC, roteamento IP, segurança, observabilidade e homologação técnica.

Internet pública ou link dedicado?

Algumas modalidades podem usar conectividade sobre internet pública, especialmente em cenários específicos ou menores. Porém, grandes operadoras normalmente trabalham com links dedicados de interconexão, com endereçamento, roteamento e políticas próprias.

Nesses ambientes, é comum existir desenho com redundância, BGP, rotas controladas e conexões cruzadas entre pares de SBCs. A ideia é evitar ponto único de falha e garantir continuidade mesmo durante falha de link, equipamento ou caminho.

Arquitetura típica de alta disponibilidade

• Dois SBCs de um lado e dois SBCs do outro.
• Links dedicados redundantes, frequentemente cruzados.
• Roteamento BGP para preferência, contingência e failover.
• Políticas de segurança, ACLs, NAT/control-plane e proteção de sinalização.
• Captura de SIP traces, CDRs e métricas para diagnóstico.

Onde projetos falham

• Tratar SIP-I como SIP comum.
• Ignorar o perfil ISUP esperado pela outra operadora.
• Não validar causas, timers, codecs, SDP e roteamento antes do tráfego real.
• Não documentar topologia, BGP, redundância e janelas de teste.
• Não ter SBC preparado para troubleshooting.

Gancho comercial

A ZICTEC pode apoiar diagnóstico, desenho, implantação e sustentação de interconexões SIP-I, incluindo SBC/ProSBC, roteamento, testes, homologação, análise de traces e documentação técnica para operação.

Telefonia pode aumentar margem — ou virar uma fonte silenciosa de custo.

Para o ISP regional, telefonia fixa costuma parecer uma oportunidade natural: a empresa já tem cliente, cobrança, suporte, infraestrutura IP e presença local. Mas voz não é apenas mais um serviço no combo. É uma operação com responsabilidades próprias: autorização, numeração, interconexão, portabilidade, bilhetagem, atendimento, disponibilidade e obrigações regulatórias.

O ponto central não é “ter ou não ter STFC”. É saber se a operação está preparada para vender, entregar, medir e sustentar telefonia sem depender de improviso.

Quando a telefonia faz sentido para um provedor

• Base empresarial ativa: clientes B2B pedem telefone fixo, PABX, portabilidade, ramais, atendimento e continuidade.
• Necessidade de aumentar ARPU: voz pode complementar conectividade, especialmente em contas corporativas.
• Capacidade de operação: existe time ou parceiro para tratar SIP, CDR, rotas, portabilidade, incidentes e relatórios.
• Estratégia comercial clara: telefonia é vendida como solução, não como “mais um item barato”.

Onde muitos provedores erram

O erro mais comum é tratar telefonia como revenda simples. A venda acontece, mas depois surgem chamados sobre áudio unilateral, chamadas que não completam, portabilidade parada, divergência de cobrança, falhas de PABX, problemas de rota e dúvidas regulatórias. Sem processo, isso consome margem.

Checklist mínimo antes de escalar vendas

• Modelo de autorização e escopo de serviço.
• Arquitetura de softswitch, SBC, rotas e interconexões.
• Processo de portabilidade e cadastro de numeração.
• Bilhetagem confiável e conciliação de tráfego.
• Rotina de suporte com logs, testes e responsáveis.
• Controle de obrigações Anatel, QEML, DETRAF e evidências quando aplicável.

O gancho comercial correto

Antes de investir em campanha de telefonia, o provedor deveria fazer um diagnóstico curto: onde está a margem, onde está o risco e quais rotinas precisam existir para a operação não vender prejuízo. A ZICTEC pode apoiar essa leitura e estruturar o caminho técnico, regulatório e operacional.

1. A pergunta correta: arquitetura, não disputa de ferramenta

Kamailio, OpenSIPS e FreeSWITCH aparecem muitas vezes como se fossem três produtos concorrentes. Na prática, essa comparação é incompleta. Kamailio e OpenSIPS são proxies/roteadores SIP, pensados para lidar com sinalização, registro, roteamento, balanceamento e alto volume de tentativas de chamada. FreeSWITCH é um B2BUA com pilha de mídia, capaz de encerrar uma chamada de um lado, originar outra do outro e controlar áudio, codecs, gravação, URA, conferência e WebRTC.

Por isso, a decisão técnica não costuma ser “qual dos três instalar?”. A decisão mais madura é: qual função cada componente vai assumir, onde ele ficará na topologia e quais responsabilidades não devem ser empurradas para a ferramenta errada?

2. Glossário rápido

• Proxy SIP: elemento focado em sinalização. Encaminha requisições, aplica regras, ajusta cabeçalhos e decide rotas, mas não precisa encerrar a chamada nem carregar o áudio.
• B2BUA: Back-to-Back User Agent. Termina a sessão SIP de um lado e cria uma sessão independente do outro. Isso permite controle profundo de sinalização e mídia.
• RTPengine/RTPproxy: relays de mídia normalmente usados junto com proxies SIP para NAT traversal e ancoragem simples de RTP, sem transformar o proxy em media server completo.
• CPS: chamadas por segundo. Métrica crítica para elementos de sinalização de alto volume.
• SBC: Session Border Controller. Elemento de borda com funções de segurança, interconexão, política, NAT, TLS/SRTP, manipulação, limites, logs e proteção operacional.

3. Proxy SIP x B2BUA/media server

Um proxy SIP como Kamailio ou OpenSIPS é excelente quando o problema principal é decidir rapidamente o destino de milhares de chamadas, distribuir carga, aplicar regras por domínio/cliente/tronco, registrar usuários e manter a sinalização eficiente. O áudio pode ir diretamente entre as pontas ou passar por um relay de mídia controlado pelo proxy.

Um B2BUA/media server como FreeSWITCH entra quando a chamada precisa de inteligência de mídia: transcodificação, URA, gravação, conferência, bridge controlado, WebRTC, manipulação mais profunda de sessão e integração com aplicações. Ele normalmente escala de outro modo, porque passa a estar no caminho de mídia e não apenas na sinalização.

4. Kamailio: escala e flexibilidade no roteamento

Kamailio é muito usado como front-end SIP de alta escala. Ele se destaca quando a rede precisa de performance, roteamento granular, manipulação de cabeçalhos, registro, dispatcher/load balancing, antifraude básico, integração com bases externas e scripts de roteamento sofisticados. O ecossistema KEMI permite escrever lógica em linguagens como Lua, Python, JavaScript e Ruby, mantendo o motor SIP especializado.

Em arquiteturas de operadora, Kamailio costuma ficar na frente de media servers, softswitches ou plataformas de aplicação. O cuidado é não confundir “rotear SIP muito bem” com “fazer tudo que uma borda de interconexão precisa”.

5. OpenSIPS: roteamento, integração e controle operacional

OpenSIPS também nasce da tradição SER e resolve problemas parecidos: sinalização SIP, registro, roteamento, balanceamento e integração. Em muitos projetos, a diferença prática aparece na preferência da equipe pelo modelo de script, pelos módulos disponíveis, pelas ferramentas de administração, por integrações HTTP/REST e pelo desenho operacional desejado.

Em termos comerciais, a decisão entre Kamailio e OpenSIPS raramente deve ser feita por “marca” ou opinião isolada. Ela depende de quem vai sustentar a operação, dos módulos necessários, do padrão de troubleshooting, das integrações e da maturidade do time.

6. FreeSWITCH: mídia, aplicações e chamadas inteligentes

FreeSWITCH é a peça natural quando o projeto precisa encerrar chamadas, controlar mídia e criar serviços: URA, gravação, conferência, transcodificação, WebRTC, discadores, CPaaS e integrações via ESL/Event Socket. Ele não é apenas um roteador SIP; ele participa da chamada durante toda a sessão.

Justamente por isso, colocar FreeSWITCH sozinho para resolver tudo — registro massivo, borda pública, interconexão, mídia, segurança e aplicação — pode gerar uma pilha difícil de escalar e proteger. O desenho comum é colocar um proxy SIP na frente e deixar FreeSWITCH tratar os fluxos que realmente precisam de mídia inteligente.

7. O padrão híbrido em produção

Um desenho frequente é: Kamailio ou OpenSIPS recebe a sinalização, autentica/roteia/balanceia, aplica políticas de chamada e encaminha apenas os fluxos que precisam de mídia para FreeSWITCH. Esse modelo reduz carga no media server, melhora previsibilidade e separa responsabilidades.

Para operadoras e ISPs, o ganho está em manter o core mais claro: o que é borda, o que é roteamento, o que é mídia, o que é aplicação e o que é interconexão. Quando essa separação não existe, qualquer ajuste de codec, NAT, fraude, failover ou manipulação de cabeçalho vira um risco sistêmico.

8. O erro comum: achar que isso substitui um SBC

Nenhuma dessas três peças, por si só, deve ser tratada como substituto completo de um SBC de borda. É possível montar uma solução “DIY-SBC” combinando proxy, relay de mídia, firewall, scripts, logs e automações. Para laboratórios e cenários controlados, isso pode funcionar. Em ambiente de operadora, interconexão, atacado ou borda exposta, as lacunas aparecem rápido.

Um SBC precisa tratar segurança, topologia, NAT, TLS/SRTP, políticas por trunk/peer, manipulação de cabeçalhos, limites, proteção contra abuso, evidências, troubleshooting, interoperabilidade e operação contínua. O custo escondido do stack caseiro não é só software: é sustentação, plantão, documentação, testes, logs e responsabilidade sobre falhas.

9. Como decidir no contexto da sua rede

• Precisa de alta escala de sinalização e roteamento? avalie Kamailio ou OpenSIPS como front-end SIP.
• Precisa de URA, gravação, transcodificação, conferência ou WebRTC? FreeSWITCH provavelmente entra como media server/B2BUA.
• Precisa expor borda, interconectar, proteger trunks e operar com evidências? trate SBC como camada própria, não como detalhe.
• Tem time para manter stack open-source crítico 24×7? some o custo de engenharia, documentação, monitoração e troubleshooting.
• Quer evoluir para STIR/SHAKEN, Origem Verificada ou integrações regulatórias? pense desde o início em sinalização, logs, rotas, políticas e governança.

10. Como a ZICTEC ajuda

A ZICTEC atua no desenho e sustentação de arquiteturas de voz com SIP, SBC, interconexão, STFC, ProSBC/TelcoBridges, rotas, troubleshooting e operação regulatória. Em vez de vender uma ferramenta como solução universal, o trabalho começa por mapear a rede, separar responsabilidades e identificar onde proxy, media server, SBC e backoffice precisam conversar.