FreeSWITCH + ProSBC: Configuração de SIP Trunking

FreeSWITCH é uma das plataformas open-source mais robustas do ecossistema de voz. Ele termina SIP, ancora mídia, transcodifica codecs, executa dialplans completos, reproduz prompts, mixa conferências, grava chamadas e expõe a Event Socket Library (ESL) para controle externo de cada sessão ativa. Equipes que operam FreeSWITCH em escala o fazem porque nenhum outro motor de mídia open-source se compara ao que ele entrega quando a chamada está no servidor.

O que o FreeSWITCH não é, porém, é um Controlador de Borda de Sessão (SBC). Ele não vem com a postura de segurança, a disciplina de criptografia por perna de chamada, a inteligência de roteamento multi-operadora nem as ferramentas de autenticação de chamadas que um SBC real traz para a borda da rede. Implantações que colocam o FreeSWITCH diretamente na internet pública herdam uma longa lista de tarefas para as quais a plataforma nunca foi projetada, e os operadores acabam reconstruindo essas tarefas costurando regras de iptables, scripts de fail2ban e código Lua. A arquitetura mais limpa é colocar um SBC na frente do FreeSWITCH e deixar cada camada fazer seu próprio trabalho.

Este artigo aborda o que o ProSBC acrescenta na frente do FreeSWITCH, quando o mod_sofia nativo do FreeSWITCH é suficiente por conta própria, os comportamentos SIP específicos do FreeSWITCH que o SBC precisa tratar, e a abordagem de configuração de alto nível para uma implantação em produção.

FreeSWITCH na Borda vs FreeSWITCH Atrás de um SBC

O motivo mais comum para adotar essa configuração é que a equipe começou com o FreeSWITCH diretamente na internet pública e esbarrou nos limites desse modelo. FreeSWITCH na borda funciona; milhares de implantações pequenas operam assim. O problema começa em escala, em jurisdições reguladas, ou em qualquer cenário onde as exigências de qualidade de chamada e segurança se equiparam ao que redes de operadoras exigem nos seus pontos de interconexão.

Uma instância FreeSWITCH na borda é, ao mesmo tempo, o servidor de aplicações inteiro, o motor de mídia inteiro e a fronteira de segurança inteira em um único processo. Uma varredura de registro, uma enxurrada de INVITEs ou tráfego SIP malformado que gera erros de parser ou carga excessiva de processamento atingem o mesmo kernel que está ancorando chamadas ativas e executando dialplans ao vivo. A plataforma nunca foi projetada para absorver tráfego hostil de forma resiliente; foi projetada para atender chamadas que já foram aceitas.

O mesmo padrão aparece no lado da interoperabilidade. O mod_sofia do FreeSWITCH negocia SIP e SDP de forma limpa com operadoras que se comportam bem, e recorre a parâmetros por gateway quando não é o caso. A coleção desses parâmetros cresce ao longo do tempo conforme você adiciona operadoras, e cada um se torna uma peça crítica de conhecimento operacional. Um SBC move essa complexidade para fora do servidor de aplicações, colocando-a em um dispositivo cuja função é exatamente normalizar entre dialetos SIP, e entrega ao FreeSWITCH um upstream único e consistente para se comunicar.

O restante deste artigo trata da implantação do ProSBC como um SBC B2BUA real entre o FreeSWITCH e a PSTN. Onde o FreeSWITCH é a ferramenta certa (ancoragem de mídia, IVR, conferência, gravação, controle de chamadas via ESL), ele permanece onde pertence: no lado LAN do SBC, fazendo o que faz de melhor.

O que o ProSBC Acrescenta na Frente do FreeSWITCH

O FreeSWITCH possui sua própria pilha SIP e sua própria pilha de mídia. Negociação de codec, tratamento de Contact com reconhecimento de NAT, gerenciamento básico de registros e parâmetros por gateway vivem dentro do mod_sofia. Para uma implantação com uma única operadora, baixo volume e um provedor cooperativo, isso basta. O ProSBC se torna necessário quando os requisitos fora da zona de conforto do mod_sofia excedem o que a plataforma FreeSWITCH foi projetada para absorver.

Roteamento multi-operadora e failover como preocupação de primeira classe

O FreeSWITCH consegue discar através de múltiplos gateways, mas a lógica de roteamento, as verificações de disponibilidade via OPTIONS e o comportamento de failover acabam espalhados entre dialplan, scripts Lua e manipuladores de eventos ESL. O ProSBC consolida o roteamento em um motor baseado em regras com rotas ordenadas por prioridade, verificações de saúde SIP OPTIONS por NAP e mapeamento de reason-cause que avança a rota nos códigos de resposta que devem tentar novamente e interrompe chamadas nos códigos que não devem. O FreeSWITCH enxerga um único upstream e descarrega toda a diversidade de operadoras no SBC.

Segurança na fronteira com a internet pública

Um servidor FreeSWITCH com IP público e porta SIP aberta é uma das classes de endpoint mais escaneadas da internet. Varreduras de registro SIP, enxurradas de INVITE e sondagens de fraude telefônica atingem qualquer endpoint SIP acessível pela internet em questão de horas após entrar no ar. O ProSBC absorve esse tráfego na borda com limitação de taxa SIP-aware por IP de origem e por método, mitigação automática de ataques SIP DoS e varreduras de registro, lista de bloqueio dinâmica com greylisting para resposta graduada e pontuação de fraude por chamada antes que a chamada chegue ao FreeSWITCH.

Normalização SIP entre operadoras e regiões

Operadoras variam no que aceitam, no que esperam e no que reescrevem silenciosamente. P-headers carregam informações que um lado exige e o outro rejeita; formatos de Contact e From diferem; a ordem de oferta de codec varia; session timers se comportam de forma diferente entre fabricantes. O motor de manipulação de cabeçalhos SIP do ProSBC normaliza a perna voltada para a operadora por NAP sem alterar a forma como o FreeSWITCH constrói seu próprio SIP de saída. O dialplan permanece limpo; as excentricidades por operadora ficam no SBC.

STIR/SHAKEN, CNAM e autenticação de chamadas

Para implantações FreeSWITCH que terminam na América do Norte, as regras da FCC para autenticação de identificação de chamadas continuam se tornando mais rígidas, e as operadoras upstream continuam transferindo as decisões de atestação para seus clientes wholesale. Controle de atestação, integração com serviço de assinatura e política de bypass para interrupções pertencem à camada do SBC, não dentro do servidor de aplicações. O ProSBC se integra com serviços de assinatura STIR/SHAKEN como TransNexus ClearIP e Neustar via SIP, com redundância tratada por ordenação de rotas e lógica de failover baseada em respostas. Consultas de CNAM e LNP se conectam ao mesmo motor de roteamento.

Quando o mod_sofia do FreeSWITCH Basta vs Quando Não Basta

O FreeSWITCH é um endpoint SIP perfeitamente capaz dentro de suas premissas de projeto. A arquitetura split-thread lida bem com concorrência, o motor de codec é maduro, e os parâmetros por gateway cobrem a maioria das particularidades de cada operadora individualmente. O fator decisivo é se o seu ambiente cabe dentro do que o mod_sofia foi construído para resolver ou se já ultrapassou esses limites.

Cenário	FreeSWITCH sozinho	FreeSWITCH com ProSBC
Operadora única cooperativa, baixo volume de chamadas, apenas usuários internos	Suficiente	Opcional
Failover multi-operadora ou roteamento de menor custo entre regiões	Depende de dialplan	Recomendado
Operadora com dialeto SIP não padrão ou regras rígidas de normalização	Ajustes por gateway	Recomendado
Controle de atestação STIR/SHAKEN, assinatura por chamada	Camada inadequada	Necessário
Exposição à internet pública com alto risco de varredura e fraude	DIY iptables + fail2ban	Necessário
Provedor de serviços operando FreeSWITCH como plataforma multi-tenant	Instâncias por tenant	NAPs por tenant em um único SBC

O padrão na tabela é consistente. O FreeSWITCH cuida do interior da sua plataforma de voz; o SBC cuida da fronteira. Assim que a fronteira desenvolve requisitos que excedem um único tronco cooperativo, o SBC assume essas responsabilidades para que o FreeSWITCH possa continuar fazendo o que faz bem. Para uma discussão mais ampla sobre onde o FreeSWITCH se encaixa no cenário open-source ao lado do Kamailio e do OpenSIPS, veja nosso artigo complementar sobre como escolher uma plataforma SIP.

Comportamentos SIP Específicos do FreeSWITCH que o SBC Precisa Tratar

A lógica de integração com o FreeSWITCH é a mesma de qualquer soft switch, com alguns comportamentos específicos da plataforma que merecem destaque. Cada um deles reside no mod_sofia ou no dialplan do FreeSWITCH e se manifesta como algo que o SBC precisa reconhecer na perna voltada para o FreeSWITCH. Acerte esses pontos e o restante da configuração se encaixa naturalmente.

Perfis SIP, gateways e como eles mapeiam para NAPs do ProSBC

O FreeSWITCH organiza seu mundo SIP em perfis (um perfil internal e um perfil external por padrão), cada um escutando em sua própria porta com sua própria lista de codecs, transporte e entradas de gateway. O padrão mais limpo com o ProSBC na frente é tratar o SBC como um único gateway no perfil external, com a escolha de autenticação do lado FreeSWITCH (REGISTER vs baseada em IP) definida conforme o que se adequa ao seu modelo operacional. No lado do ProSBC, essa mesma conexão se torna um único NAP apontando para o endereço interno do servidor FreeSWITCH, com os NAPs voltados para operadoras tratados de forma independente. Toda particularidade de operadora fica em um NAP de operadora, nunca no NAP do FreeSWITCH.

Preferência de codec e a questão da transcodificação

O FreeSWITCH oferece codecs conforme o outbound-codec-prefs e negocia o conjunto de mídia final com base na resposta recebida do lado remoto. Quando a operadora suporta um conjunto diferente de codecs, ou prefere uma ordem diferente, o SBC normaliza a oferta conforme a expectativa da operadora. Para tráfego destinado à PSTN, isso geralmente significa G.711 µ-law ou A-law na primeira posição, com o SBC removendo ofertas não-PSTN como G.722 ou Opus que a operadora não negociará. Se uma chamada realmente precisa de conversão de codec na borda (Opus no lado FreeSWITCH, G.711 no lado da operadora, ou AMR-WB de entrada de uma operadora móvel), a transcodificação por hardware tira essa carga do servidor FreeSWITCH, onde ela disputaria CPU com ancoragem de mídia e mixagem de conferência.

Reescrita de Contact, Via e Record-Route

O FreeSWITCH coloca seu próprio IP externo ou hostname nos cabeçalhos Contact e Via, com NDLB-force-rport e flags NDLB-* relacionadas (No Default Loopback Behavior) ajustando o quão estritamente o mod_sofia respeita a porta e endereço de origem nas respostas. O SBC geralmente reescreve Contact, Via e cabeçalhos de roteamento conforme a política de ocultação de topologia antes de encaminhar o tráfego de saída, e reverte a reescrita no caminho de volta para que o FreeSWITCH receba um endereço que consiga rotear. A ocultação de topologia no SBC trata isso de forma transparente, impedindo que a operadora veja o endereçamento interno do FreeSWITCH e evitando falhas de rota causadas por vazamento de endereços privados.

Handover de fax T.38 e o re-INVITE no meio da chamada

O FreeSWITCH suporta T.38 através do mod_spandsp, com o modo T.38 gateway fazendo a ponte entre T.38 em uma perna e passthrough G.711 na outra. Todo o padrão depende de um re-INVITE no meio da chamada que troca o stream de áudio por um stream T.38 quando tons de fax são detectados. Algumas operadoras aceitam o re-INVITE sem problemas; outras o rejeitam, deixam expirar ou removem os atributos SDP que fazem o T.38 funcionar. O SBC trata o comportamento por NAP: relay de T.38 quando a operadora aceita T.38, passthrough G.711 com perfil fax-safe (cancelamento de eco desligado, jitter buffer estático, VAD desabilitado) quando não aceita, e reescrita limpa de SDP em ambas as direções. Os detalhes completos de como o T.38 negocia e onde costuma falhar estão cobertos na nossa referência de Fax over IP (T.38).

REFER, transferência assistida e a alternativa via bridge

O FreeSWITCH implementa transferências de chamada por SIP REFER (quando iniciado por um endpoint que o envia) ou pelo mecanismo de bridge do dialplan, que mantém a perna da chamada no FreeSWITCH e origina uma nova. Operadoras variam no suporte ao REFER. O SBC tem dois comportamentos corretos: encaminhar o REFER se a operadora o suporta, ou substituir o REFER por um re-INVITE dentro do SBC para que a operadora nunca veja o REFER. Configure isso por NAP conforme o que cada operadora upstream aceita, e o FreeSWITCH nunca precisará saber qual operadora está do outro lado.

Session timers e quedas silenciosas de chamada

O FreeSWITCH usa SIP session timers (RFC 4028) quando configurado para isso (enable-timer, session-timeout), e os ignora caso contrário. O SBC precisa negociar valores de timer compatíveis em cada perna, renovando na cadência esperada pelo FreeSWITCH e na cadência exigida pela operadora. Timers desalinhados causam quedas silenciosas de chamada no meio da conversa, que aparecem como falhas aleatórias e intermitentes nos logs do FreeSWITCH porque a falha está acontecendo um salto adiante. Configurar timers de forma consistente no SBC elimina essa classe de problema por completo.

Abordagem de Configuração: FreeSWITCH, SBC, Operadora

Os menus específicos diferem entre fabricantes de SBC, mas a lógica de integração é a mesma em qualquer SBC B2BUA. O objetivo são dois grupos de troncos limpos (um voltado para o FreeSWITCH, um por operadora) com o SBC fazendo a ponte e tratando toda transformação entre eles. O lado FreeSWITCH da configuração é intencionalmente simples; o SBC absorve tudo que de outra forma viveria em parâmetros por gateway espalhados pelo mod_sofia.

1. Planeje a topologia antes de tocar na configuraçãoDefina onde o ProSBC ficará: no mesmo cloud VPC do FreeSWITCH, em uma VM separada no mesmo data center, ou em uma região de nuvem dedicada na frente de um cluster FreeSWITCH on-premises. Confirme o endereçamento de IP público, DNS e provisionamento de certificado TLS para o ProSBC. O servidor FreeSWITCH mantém seu endereçamento LAN existente; o ProSBC assume o papel público e o tráfego ESL continua terminando no lado LAN do FreeSWITCH onde sempre esteve.
2. Configure o NAP voltado para o FreeSWITCH no ProSBCCrie um NAP apontando para o endereço interno do servidor FreeSWITCH. Use o mesmo transporte que o mod_sofia está configurado no perfil external (UDP, TCP ou TLS) na porta acordada. Decida se o FreeSWITCH autenticará por IP ou por credenciais REGISTER, e configure o NAP conforme a escolha. Mantenha este NAP simples: regras de cabeçalho, políticas de codec e ajustes de segurança pertencem aos NAPs do lado da operadora.
3. Configure cada NAP voltado para operadora no ProSBCCrie um NAP por operadora upstream. Defina transporte, lista de codecs, regras de cabeçalho e modo de autenticação conforme o guia de integração da operadora. Se a operadora fornecer IPs de sinalização redundantes, agrupe-os em um NAP com ordenação de rotas primária e secundária e heartbeat SIP OPTIONS configurado para detecção de disponibilidade.
4. Adicione regras de manipulação de cabeçalho por pernaRemova P-headers e campos proprietários que a operadora não aceita no tráfego de saída do FreeSWITCH. Reescreva Contact e Via com o endereço público do ProSBC. Normalize From e PAI para o formato esperado pela operadora para atestação STIR/SHAKEN. Nada disso exige alteração na configuração do próprio FreeSWITCH.
5. Configure regras de roteamento entre NAPsDefina regras de entrada de cada operadora para o NAP do FreeSWITCH, e regras de saída do NAP do FreeSWITCH para a operadora apropriada com base em prefixo de destino, horário do dia ou qualquer outro critério. Adicione regras de fallback para interrupções de operadora, de modo que uma chamada negada na rota primária avance para a secundária. O mapeamento de reason-cause determina quais códigos de resposta devem gerar nova tentativa e quais devem interromper a chamada.
6. Adicione segurança e autenticação de chamadasHabilite proteção DoS/DDoS e proteção contra varredura de registro SIP nos troncos voltados para operadoras. Configure lista de bloqueio dinâmica e pontuação de fraude telefônica. Para tráfego destinado aos EUA, configure a assinatura STIR/SHAKEN através do seu provedor STI-AS, com rotas primária e secundária para o próprio serviço de assinatura e um mapa de reason-cause que avança a rota em 404 e interrompe chamadas em 603, conforme o padrão de integração SIP em produção.
7. Reconfigure o FreeSWITCH para se comunicar com o ProSBC em vez de diretamente com as operadorasNo FreeSWITCH, edite as entradas de gateway relevantes em conf/sip_profiles/external/ para que cada uma aponte para o ProSBC em vez da operadora. As preferências de codec e configurações de proxy no nível do gateway se simplificam substancialmente porque o SBC absorve tudo que é específico da operadora. Recarregue o mod_sofia ou faça rescan do perfil afetado em vez de reiniciar o FreeSWITCH, se possível, para evitar a interrupção.
8. Teste em ambas as direções e sob failoverRealize chamadas de teste de entrada e saída. Verifique a apresentação do identificador de chamadas, negociação de codec, DTMF (RFC 2833 / RFC 4733), tratamento de transferências e entrega de fax, se utilizado. Em seguida, interrompa deliberadamente a conectividade de sinalização da operadora primária e confirme que o ProSBC move o tráfego para a rota secundária no tempo ditado pelo SIP OPTIONS. Monitore a saída de sofia.status e sofia.profile.external.status do FreeSWITCH durante o failover para confirmar que o lado FreeSWITCH permanece estável durante todo o processo.

O que Procurar em um SBC para FreeSWITCH

As funcionalidades qualificadoras de um SBC compatível com FreeSWITCH são as mesmas que tornam qualquer SBC bom em interoperabilidade multi-fabricante, com algumas considerações adicionais específicas para operar na frente de um servidor de aplicações open-source. Use a lista a seguir como checklist ao avaliar opções.

Arquitetura B2BUA, não um SIP proxy

Um SIP proxy não consegue fazer esse trabalho. Reescrever Contact e Via, substituir REFER por re-INVITE, converter RTP para SRTP e assinar chamadas de saída com STIR/SHAKEN exigem que o SBC termine e reorigine cada diálogo de forma independente. Arquitetura B2BUA é o requisito de base.

Roteamento programável que atende o FreeSWITCH nos seus próprios termos

Operadores de FreeSWITCH tendem a esperar programabilidade, porque é isso que a própria plataforma oferece através de ESL, Lua e dialplan. Um SBC pareado com o FreeSWITCH deve oferecer um nível comparável de controle do seu próprio lado. A API de roteamento Ruby do ProSBC expõe o contexto completo da chamada para scripts externos em três estágios de filtro (before_filter, after_filter, after_remap_filter), com módulos prontos para assinatura STIR/SHAKEN, TransNexus ClearIP, SecureLogix, YouMail e Neustar. O modelo de integração é pensado para o mesmo tipo de operador que já administra dialplan e código ESL no lado FreeSWITCH.

TLS, SRTP e regras de cabeçalho por NAP

Busque um SBC onde cada NAP carregue sua própria configuração de transporte, sua própria lista de codecs e seu próprio perfil de manipulação de cabeçalhos. É isso que permite que uma operadora fique em UDP/5060 com G.711 enquanto outra usa TLS/5061 com SRTP, e o FreeSWITCH atrás de ambas receba uma apresentação consistente independentemente de qual operadora tratou a chamada.

Integração STIR/SHAKEN aberta com parceiros

STIR/SHAKEN no SBC não deve prender você a um único serviço de assinatura. O ProSBC se integra com TransNexus ClearIP e Neustar via SIP, e com qualquer provedor STI-AS que exponha uma API HTTPS quando necessário. A atestação é decidida por chamada dentro do motor de roteamento em vez de por tronco como configuração estática, que é exatamente o que a regra de certificado próprio da FCC pressupõe quando uma única plataforma trata tráfego multi-tenant.

Flexibilidade de implantação compatível com a flexibilidade do FreeSWITCH

O FreeSWITCH roda em Linux em praticamente qualquer infraestrutura. O SBC deve rodar onde quer que sua topologia coloque a borda: AWS, Azure, VMware, KVM/Proxmox ou bare metal. Um SBC cloud-native co-localizado com um FreeSWITCH hospedado na nuvem minimiza a latência entre os dois; um SBC virtualizado no mesmo hypervisor de um FreeSWITCH on-premises mantém toda a pilha de voz na infraestrutura do cliente.

Avaliação self-service

A melhor forma de confirmar que um SBC funciona bem com o FreeSWITCH é colocar tráfego real por ele. Uma licença de avaliação gratuita e self-service permite que você coloque o SBC ao lado de uma instância FreeSWITCH de teste e valide cada comportamento listado acima antes de se comprometer.

Segurança na Borda do FreeSWITCH

O FreeSWITCH tem suas próprias proteções, incluindo filtragem baseada em ACL e limites de taxa no nível do mod_sofia. O SBC complementa essas proteções com defesas em camadas que operam antes do tráfego chegar ao FreeSWITCH, que é a posição arquitetural correta para proteção na camada SIP. Todo pacote que o FreeSWITCH nunca precisa examinar é CPU que ele não gasta decidindo o que fazer com ele.

Proteção contra varredura de registro SIP

O ataque mais comum contra um servidor FreeSWITCH na internet pública é uma enxurrada lenta de REGISTERs sondando extensões válidas ou senhas fracas. O ProSBC detecta padrões de varredura por frequência e distribuição de origem, bloqueia a fonte automaticamente e nunca encaminha a sondagem ao FreeSWITCH. Greylisting com resposta baseada em percentual permite que o SBC investigue fontes suspeitas gradualmente, em vez de bloqueá-las e desbloqueá-las em ciclos alternados.

Mitigação de DoS e DDoS

Enxurradas volumétricas de INVITE e OPTIONS que consumiriam o pool de conexões do FreeSWITCH são limitadas primeiro na camada do SBC. Limitação de taxa SIP-aware por IP de origem, por grupo de troncos e por método SIP descarta tráfego malicioso antes de consumir a capacidade de atendimento de chamadas do FreeSWITCH.

Detecção de fraude telefônica na perna voltada para a operadora

Discagem internacional para números premium é o maior risco de exposição financeira em qualquer endpoint SIP. O ProSBC aplica uma pontuação de risco por chamada considerando prefixo de destino, taxa de chamadas, horário e histórico de padrões, bloqueando a chamada ou encaminhando-a para revisão antes de sair pelo tronco da operadora. A integração com parceiros validados de detecção de fraude como TransNexus e YouMail se conecta ao mesmo motor de roteamento.

Ocultação de topologia para o próprio servidor FreeSWITCH

O IP público do ProSBC é o único endereço que a operadora vê. O hostname interno do FreeSWITCH, seu endereço privado, a estrutura da LAN por trás dele e qualquer sistema back-end conectado via ESL permanecem invisíveis do lado da operadora. Isso reduz a superfície de ataque a uma única fronteira bem defendida, em vez do próprio servidor de aplicações.

Perguntas Frequentes

Conclusão

O FreeSWITCH é uma plataforma open-source capaz dentro de suas premissas de projeto. Com uma única operadora cooperativa e um ambiente contido, ele não precisa de nada na frente. A partir desse ponto, as questões de integração se acumulam: diversidade de operadoras, perfis SIP customizados, atestação em setores regulados, exposição à internet pública, entrega de serviço multi-tenant. Cada uma dessas questões se resolve de forma limpa com um SBC na borda.

As funcionalidades decisivas ao avaliar um SBC para FreeSWITCH são: arquitetura B2BUA para controle total de cabeçalhos, política de transporte e codec por NAP, roteamento programável que atende operadores de FreeSWITCH nos seus próprios termos, modelo STIR/SHAKEN aberto com parceiros, e avaliação self-service para confirmar que a integração funciona antes de assinar qualquer contrato. Acertando esses pontos, o SBC faz seu trabalho silenciosamente por anos enquanto o FreeSWITCH continua fazendo o que faz bem.