FusionPBX com SBC: configuração e boas práticas

FusionPBX é a interface web que a maioria dos provedores de serviços escolhe quando quer um PBX multi-tenant baseado em FreeSWITCH gerenciável pelo navegador. Um banco de dados PostgreSQL, um cluster FreeSWITCH e uma abstração de domínios que permite que uma única implantação atenda dezenas ou centenas de tenants. Esse design é o que torna o FusionPBX popular entre MSPs, ITSPs, ILECs e CLECs que oferecem PBX hospedado como serviço. E é também o que torna a questão do SBC diferente de qualquer outro artigo sobre integração com PBX neste site.

A maioria dos artigos sobre PBX + SBC começa com “seu PBX não consegue encerrar diálogos SIP corretamente sozinho.” O FusionPBX não tem esse problema. O FreeSWITCH já opera como um Agente de Usuário Back-to-Back (B2BUA) em cada chamada, encerrando o diálogo de entrada em um perfil sofia e originando um novo diálogo em outro. A questão para operadores de FusionPBX é mais precisa: se o FreeSWITCH já faz o que um Controlador de Borda de Sessão (SBC) faz no nível do diálogo SIP, por que adicionar outro B2BUA na borda?

Este artigo responde a essa pergunta, percorre os comportamentos SIP específicos do FusionPBX que um SBC precisa tratar na borda, aborda o padrão de integração multi-tenant que torna implantações de FusionPBX interessantes em escala e apresenta a abordagem de configuração para colocar um SBC na frente de um cluster FusionPBX em produção.

O FreeSWITCH já encerra SIP. Por que adicionar um SBC?

Esta é a pergunta que separa a história de integração do FusionPBX da integração com FreePBX ou 3CX, e merece uma resposta direta.

O FreeSWITCH é um B2BUA. Em cada chamada, o módulo sofia aceita o INVITE de entrada em um perfil, processa a chamada pelo dialplan e origina um novo INVITE para o destino bridged em outro perfil. O Call-ID, From-tag e Contact no trecho de saída são independentes do trecho de entrada. Re-INVITEs, transferências e negociação de mídia são tratados por trecho. No nível do diálogo SIP, o FreeSWITCH faz o que um SBC B2BUA faz.

O que o FreeSWITCH não faz, por design, é assumir as preocupações operacionais que existem na fronteira entre uma rede de voz e a internet pública. Cinco preocupações, especificamente.

Segurança na camada SIP em taxa de operadora

Defesa de borda opera em uma camada diferente daquela para a qual o parser sofia do FreeSWITCH foi construído. O stack sofia aceita uma mensagem SIP, faz o parsing e a executa contra a autenticação de domínio antes de rejeitá-la. A centenas de mensagens malformadas por segundo vindas de um scanner coordenado, o parser se torna o gargalo. A proteção contra DoS e DDoS com reconhecimento SIP de um SBC descarta tráfego malformado e fora de política na borda, com limites de taxa por método, por origem e por grupo de troncos, antes que o sofia sequer veja a mensagem.

Integração com serviço de assinatura STIR/SHAKEN

Assinatura de chamadas não existe nativamente no FreeSWITCH ou no FusionPBX. Não há módulo que chame TransNexus ClearIP ou Neustar, construa um PASSporT, anexe o cabeçalho Identity e faça fallback através de um mapa de reason-cause quando o serviço de assinatura está indisponível. Operadoras norte-americanas que terminam chamadas sem um cabeçalho Identity verificado cada vez mais rebaixam a atestação, e o fluxo de assinatura STIR/SHAKEN é uma preocupação da camada do SBC.

Normalização SIP por operadora em múltiplos provedores upstream

Particularidades de cada operadora escalam mal dentro dos gateways do FreeSWITCH. Uma implantação FusionPBX roteando para quatro operadoras acaba com quatro definições de gateway, cada uma com suas próprias substituições de dial-string de saída, exceções de ACL, ajustes de cabeçalho feitos por variáveis de canal pré-chamada e condições de dialplan que testam o branch da operadora. O motor de manipulação de cabeçalhos SIP de um SBC lida com normalização por trecho em um único lugar com regras que podem ser editadas sem tocar no dialplan.

Ocultação de topologia e política consistente de identidade

Apresentação de borda pertence à borda. O FreeSWITCH anuncia seu endereço de bind nos cabeçalhos Contact e Via por padrão, e os workarounds padrão (sip-ip, ext-sip-ip e extra-headers por gateway no sofia) funcionam, mas distribuem a política entre múltiplos fragmentos XML. Um SBC aplica ocultação de topologia de forma consistente para cada chamada de saída, independente de qual tenant ou qual gateway originou a chamada.

Pontuação de fraude antes que uma chamada consuma minutos

Pontuação de risco por chamada é a camada mais cara que falta ao MSP que opera FusionPBX. Um ramal comprometido em qualquer tenant do cluster pode queimar seis dígitos em minutos de tarifa premium em um fim de semana. O FreeSWITCH pode aplicar limites por domínio e caps de taxa de saída, mas pontuação em tempo real contra um provedor como TransNexus, SecureLogix ou YouMail é uma integração de API que a camada do SBC faz, não a camada do PBX.

O padrão é consistente nas cinco preocupações. FusionPBX e FreeSWITCH são excelentes como motor de controle de chamadas multi-tenant. O SBC assume a responsabilidade pelas preocupações de borda que o motor de controle de chamadas nunca foi construído para assumir.

Multi-tenant por design: domínios FusionPBX e a fronteira do SBC

O modelo de domínios do FusionPBX é o que torna a integração com SBC genuinamente diferente de uma implantação de PBX single-tenant. Cada tenant no FusionPBX é um domínio (por exemplo, customer-a.pbx.msp.example, customer-b.pbx.msp.example, e assim por diante), e cada ramal, gateway, dialplan, IVR e caixa de correio de voz vive dentro de um desses domínios. O mesmo processo FreeSWITCH atende todos, com contexto de domínio aplicado por chamada através de consultas mod_xml_curl ao PostgreSQL.

Esse modelo cria dois padrões de integração com SBC, dependendo de como o MSP quer gerenciar os relacionamentos com operadoras.

Mapeamento de operadora por tenant é adequado para MSPs onde cada tenant traz sua própria operadora, seus próprios DIDs e, às vezes, sua própria política de atestação STIR/SHAKEN. O SBC tem um NAP por tenant no lado interno e um NAP por operadora de tenant no lado upstream. Regras de roteamento no SBC mapeiam a faixa de DID do tenant para sua operadora upstream específica. O isolamento de tenant é aplicado na camada do SBC, não apenas dentro do FusionPBX, o que importa quando as credenciais de operadora de um tenant nunca devem alcançar o tráfego de outro tenant.

Mapeamento de operadora wholesale compartilhada cobre MSPs que agregam tráfego em uma ou duas operadoras wholesale com seu próprio inventário de DIDs. O SBC tem um NAP por tenant no lado interno, mas apenas um ou dois NAPs no lado upstream independente da quantidade de tenants. Regras de roteamento mapeiam a saída de qualquer tenant para a operadora wholesale, com a identidade do tenant transportada via P-Asserted-Identity ou um cabeçalho customizado para reconciliação de faturamento. A atestação STIR/SHAKEN é aplicada uniformemente pelo MSP como provedor de serviço de origem.

Ambos os padrões funcionam, e MSPs de grande porte tipicamente operam uma combinação dos dois. O que ambos dependem é do isolamento de NAP por tenant no SBC. Um único SBC na borda com centenas de NAPs (um por tenant no lado FusionPBX, mais NAPs de operadora) consolida o que seriam centenas de endpoints FusionPBX expostos individualmente em uma única fronteira controlada. A referência de SBC para MSPs cobre a arquitetura multi-tenant em profundidade.

Comportamentos SIP específicos do FusionPBX que o SBC precisa tratar

FusionPBX é a interface. FreeSWITCH é o motor SIP. O SBC se conecta como peer ao módulo sofia do FreeSWITCH, e alguns comportamentos do sofia definem como a integração funciona na prática.

Binding do perfil sofia e a divisão internal/external

O FusionPBX usa por padrão dois perfis sofia. O perfil internal lida com registros de ramais (tipicamente em UDP/5060 de um endereço interno). O perfil external lida com troncos (tipicamente em UDP/5080 do mesmo endereço, ou em uma interface separada). O SBC se conecta ao perfil external, não ao internal. Este é o primeiro ponto onde novas integrações falham: o SBC envia INVITEs para o IP do servidor FusionPBX na porta 5060, o FusionPBX espera recebê-los na porta 5080 no perfil external, e a chamada falha antes de qualquer lógica de dialplan ser executada. Confirme a porta de bind do perfil external e configure o NAP do SBC voltado para o FusionPBX para corresponder.

Autenticação de gateway e contact-in-ping

Para chamadas de saída, o FusionPBX roteia através de um gateway definido no perfil external. O gateway informa ao sofia para onde enviar o INVITE, quais credenciais (se houver) usar para autenticação e qual transporte usar. Quando o SBC é o peer upstream em vez de uma operadora, o gateway aponta para o SBC e a autenticação geralmente é baseada em IP no lado do SBC. A opção sofia contact-in-ping controla se o cabeçalho Contact do gateway é incluído em pings OPTIONS; algumas configurações de SBC exigem isso, outras rejeitam como malformado. Defina o valor para corresponder ao que o SBC espera.

mod_xml_curl, latência de dialplan e comportamento de failover do SBC

mod_xml_curl é o que faz as alterações da interface do FusionPBX entrarem em vigor sem reload do FreeSWITCH. Cada chamada de entrada dispara uma consulta HTTP de volta ao servidor web do FusionPBX para resolver dialplan, diretório e configuração. Sob carga normal isso é invisível. Sob pressão no PostgreSQL ou contenção no servidor web, a latência da consulta aumenta, e INVITEs de entrada para o FreeSWITCH começam a chegar mais rápido do que o dialplan consegue resolver. O papel do SBC aqui é aplicar timers de sessão e prazos de setup de chamada do seu lado, independente do FreeSWITCH, para que uma consulta lenta de dialplan não se propague como um timeout visível para a operadora. A política de retry de saída por NAP no SBC absorve a variação.

Manipulação de cabeçalhos via dialplan vs. normalização via SBC

Os dialplans do FusionPBX podem definir variáveis de canal e adicionar cabeçalhos a chamadas de saída (sip_h_X-Custom, effective_caller_id_name, etc.). Feito com cuidado, isso funciona. Feito em muitos tenants e muitas operadoras, torna-se um problema de manutenção: cada nova integração de operadora requer edições de dialplan em múltiplos lugares, e cada mudança requer testes de regressão entre tenants. Mover a normalização para a camada do SBC através de regras de manipulação de cabeçalhos por NAP consolida o trabalho em um único lugar e mantém o dialplan do FusionPBX focado na lógica de chamada específica do tenant. O SBC faz o trabalho específico da operadora uniformemente entre tenants.

Encaminhamento de REGISTER e o papel de borda do SBC para telefones hospedados

Algumas implantações MSP terminam registros de telefones SIP diretamente no FusionPBX pela internet pública. Isso funciona, e o FreeSWITCH lida bem com registros, mas coloca o servidor FusionPBX na internet pública exposto a varredura de registros. O padrão mais limpo é ter o SBC aceitando registros na borda, encaminhando-os ao FusionPBX via seu recurso de encaminhamento de registros, e aplicando proteção contra varredura de registro SIP antes que qualquer tráfego de varredura chegue ao FusionPBX. O trade-off é que o SBC precisa escalar o encaminhamento de registros para a contagem total de telefones, não apenas a contagem de chamadas ativas.

Negociação de codec e transcodificação

O FreeSWITCH transcodifica entre G.711 µ-law, A-law, GSM, G.722 e L16 nativamente. Opus é suportado nativamente em builds modernos. G.729 e AMR são codecs licenciados que requerem módulos adicionais no FreeSWITCH e, dependendo do volume de chamadas, podem exceder a capacidade de CPU no mesmo host do FusionPBX. A política de codec por trecho do SBC decide o que a operadora vê e o que o lado FusionPBX vê de forma independente. Quando a operadora quer apenas G.711 e o tenant usa Opus para clientes WebRTC, a transcodificação pode rodar na opção de transcodificação por hardware do SBC em vez de consumir CPU do FusionPBX.

Abordagem de configuração: FusionPBX, SBC, operadora

Os menus específicos diferem entre fabricantes de SBC e entre versões do FusionPBX, mas a lógica de integração é a mesma em qualquer SBC B2BUA na frente de um cluster FusionPBX multi-tenant.

1. Planeje a topologia e o modelo de tenant antes de tocar na configuração. Decida se cada tenant traz sua própria operadora ou se o MSP agrega em operadoras wholesale. O modelo de tenant determina quantos NAPs você precisa no SBC e como as regras de roteamento serão. O FusionPBX vai para uma interface privada (ou uma sub-rede de nuvem privada); o SBC assume o papel público.
2. Configure os NAPs voltados para o FusionPBX no SBC. Crie um NAP por tenant FusionPBX, ou um NAP para todo o cluster FusionPBX se todos os tenants compartilham uma operadora wholesale. Aponte cada NAP para o perfil sofia external do FusionPBX (tipicamente UDP/5080 ou TLS/5081), não para o perfil internal. Confirme que a porta de bind corresponde.
3. Configure cada NAP voltado para operadora no SBC. Crie um NAP por operadora upstream com o transporte, lista de codecs, regras de cabeçalho e modo de autenticação que o guia de integração da operadora especifica. Use os valores publicados pela operadora, não os padrões do FreeSWITCH.
4. Adicione regras de manipulação de cabeçalhos por trecho. Remova P-headers que a operadora rejeita, reescreva Contact e Via para ocultação de topologia, normalize From e PAI para compatibilidade com atestação STIR/SHAKEN na saída, e aplique limites de tamanho de mensagem SIP onde a operadora os exige.
5. Configure regras de roteamento entre NAPs. Entrada de cada operadora para o NAP correto do tenant FusionPBX com base na faixa de DIDs. Saída de cada NAP de tenant FusionPBX para a operadora apropriada com prioridade e fallback para que o SBC mova o tráfego quando uma operadora parar de responder.
6. Adicione preservação de identidade de tenant. Quando o SBC agrega muitos tenants em uma operadora wholesale, a identidade do tenant (para faturamento, atestação, gravação) é transportada via P-Asserted-Identity, um cabeçalho customizado ou o cabeçalho From. Configure o SBC para preenchê-la a partir do contexto do NAP do tenant.
7. Adicione segurança e autenticação de chamadas. Ative proteção contra DoS e DDoS, proteção contra varredura de registros se o SBC está encaminhando registros para o FusionPBX, lista de bloqueio dinâmica, pontuação de fraude de tarifação e assinatura STIR/SHAKEN no trecho da operadora.
8. Reconfigure os gateways do FusionPBX para apontar para o SBC. Na interface do FusionPBX em Advanced → Gateways, edite cada gateway voltado para operadora para que o proxy e o registrar (se usado) apontem para o endereço interno do SBC em vez do endereço público da operadora. Ramais, dialplans, IVRs e correio de voz não são afetados. Faça reload do mod_sofia para o perfil external.
9. Teste entrada, saída e isolamento de tenant sob failover. Faça chamadas de teste de cada tenant. Verifique caller ID, DTMF, negociação de codec, tratamento de transferência e correio de voz. Interrompa a sinalização da operadora primária e confirme que o SBC faz failover sem derrubar chamadas ativas. Confirme que uma chamada feita do tenant A nunca cai no contexto de domínio do tenant B no lado FusionPBX.

Segurança na borda do FusionPBX

O FreeSWITCH inclui ACLs baseadas em IP, autenticação por domínio e limitação de taxa no stack sofia. Isso funciona, e a maioria das implantações FusionPBX em produção os utiliza. O SBC complementa com defesas em camadas que operam antes que o tráfego chegue ao FreeSWITCH, que é a posição arquitetural correta para proteção na camada SIP entre muitos tenants em um cluster.

• Proteção contra varredura de registro SIP detecta padrões de varredura na borda, bloqueia a origem automaticamente e nunca encaminha a sonda ao FreeSWITCH. Isso importa especialmente quando o SBC é o encaminhador de registros para telefones hospedados.
• Mitigação de DoS e DDoS aplica limitação de taxa com reconhecimento SIP por IP de origem, por NAP de tenant e por método SIP. O parser do sofia não vê o ataque quando o SBC está na frente.
• Detecção de fraude de tarifação pontua cada chamada contra prefixo de destino, taxa de chamadas, horário do dia e histórico de padrões. Em uma implantação FusionPBX multi-tenant, um ramal comprometido em qualquer tenant é suficiente para queimar minutos de tarifa premium durante a noite; a pontuação de risco por chamada captura o padrão antes que o FreeSWITCH aloque um canal.
• Ocultação de topologia mantém o IP público do SBC como o único endereço que a operadora vê, independente de qual host FreeSWITCH ou qual domínio originou a chamada.
• Lista de bloqueio dinâmica e greylisting automatizam a resposta a abusos detectados sem intervenção manual.

O modelo completo de segurança do SBC cobre o padrão de defesa em camadas em profundidade.

STIR/SHAKEN para MSPs com FusionPBX

Para implantações FusionPBX com terminação na América do Norte, a questão STIR/SHAKEN define como o MSP é posicionado junto às suas operadoras upstream e, cada vez mais, quais taxas de atendimento cada tenant obtém em chamadas de saída.

FreeSWITCH e FusionPBX não assinam chamadas. Não existe módulo nativo para construção de PASSporT, nenhum caminho de consulta STI-AS e nenhuma injeção de cabeçalho Identity no stack sofia. A assinatura acontece na camada do SBC ou upstream na operadora.

Para MSPs que possuem seu próprio SPC token e querem controle total de atestação, o SBC trata a assinatura por chamada. O nível de atestação é decidido por chamada, não por tenant, porque um único cluster FusionPBX tipicamente transporta tráfego misto: nível A para tenants de varejo direto onde o KYC é verificado, nível B para números revendidos e nível C para qualquer tenant cuja parte chamadora não pode ser autenticada. A referência sobre atestação STIR/SHAKEN nível A cobre o que é necessário para manter o nível A à medida que o ambiente regulatório de upstream se torna mais rigoroso.

Para MSPs que permitem que uma operadora wholesale upstream assine em seu nome, o trabalho do SBC é preencher os cabeçalhos de identidade SIP com precisão para que a operadora tenha informações corretas para basear a atestação. Remover ou reescrever P-Asserted-Identity no SBC degradará silenciosamente os resultados de atestação.

Em ambos os padrões, o SBC se integra com serviços de assinatura como TransNexus ClearIP e Neustar através do motor de roteamento do SBC, não através de nada dentro do FusionPBX. Os detalhes de implementação estão no guia de implementação STIR/SHAKEN para SBC.

Perguntas frequentes

Conclusão

O FusionPBX é uma das melhores opções do mercado para um PBX hospedado multi-tenant baseado em FreeSWITCH. Seus pontos fortes são o modelo de domínios, a interface gráfica sobre o motor de controle de chamadas do FreeSWITCH e a economia operacional de executar muitos tenants em uma única infraestrutura. Suas limitações aparecem na fronteira entre essa infraestrutura e a internet pública: segurança na camada de sinalização, assinatura STIR/SHAKEN, normalização por operadora em escala e pontuação de fraude por chamada, todas vivem em uma camada que o FusionPBX não foi projetado para assumir. O SBC é o que assume a responsabilidade por essas preocupações sem mudar como o FusionPBX lida com tenants e chamadas internamente.

As funcionalidades decisivas ao avaliar um SBC para uma implantação FusionPBX são: arquitetura B2BUA para controle total de cabeçalhos e criptografia em cada trecho, política de transporte e codec por NAP para que cada tenant e cada operadora receba o perfil correto, um modelo aberto de parceiros STIR/SHAKEN para que a escolha do serviço de assinatura permaneça do MSP, capacidade de NAPs em escala de tenant para que um SBC possa atender todo o cluster FusionPBX, e avaliação self-service para que você possa confirmar a integração contra sua implantação real antes de assinar qualquer coisa.