Migração do Avaya SBC: como substituir o SBCE sem interromper a voz

Implantações Avaya SBCE continuam passando chamadas. Esse raramente é o problema. A conversa sobre migração normalmente começa quando algo ao redor do SBCE muda: um segundo pedido de Chapter 11 reabre a questão de risco com o fornecedor, um par de SBCE atinge o teto de 2.000 sessões e dispara uma expansão de licença inesperada, um aviso de fim de venda do Carrier Services força uma mudança no lado do SIP Trunk (tronco de voz sobre IP) de qualquer forma, ou a cotação de renovação do Core Suite chega sem um preço por sessão que a equipe de compras consiga modelar. Nenhum desses gatilhos exige tocar no Communication Manager, no Session Manager ou no Aura. O SBC é um componente único na borda, e em muitas implantações ele pode ser substituído independentemente do restante da infraestrutura de voz.

Esta página é o guia operacional para migrar do Avaya SBCE para o ProSBC. Ela assume que a decisão de avaliar uma substituição já foi tomada e detalha como a migração realmente funciona em produção: como auditar a configuração existente do SBCE, como os objetos de configuração do Avaya mapeiam para os do ProSBC, como rodar os dois SBCs em paralelo com segurança e como planejar uma virada com um caminho real de rollback.

O que dispara uma migração do Avaya SBCE em 2026

O gatilho da migração geralmente é um de quatro eventos específicos, não uma insatisfação geral com a plataforma. Saber qual se aplica define o escopo do projeto e quão agressivo o cronograma precisa ser.

Reavaliação de risco com o fornecedor é o gatilho mais levantado em 2026. A Avaya entrou com pedido de Chapter 11 em 2017 e novamente em fevereiro de 2023, da segunda vez eliminando cerca de 75% de sua dívida de $3,4 bilhões e saindo 76 dias depois. A organização pós-reestruturação é mais enxuta, a direção estratégica está mais focada em ofertas de nuvem e assinatura, e alguns clientes começaram a reavaliar como querem gerenciar a dependência de longo prazo em infraestrutura on-premises. Nada disso significa automaticamente que o SBCE vai acabar, mas muda a forma como equipes de compras, risco e continuidade respondem à pergunta sobre se o SBC na borda da rede deveria depender deste fornecedor em particular.

O teto de 2.000 sessões importa para qualquer ambiente cujos volumes de chamadas estão crescendo. Implantações SBCE são comumente dimensionadas em torno de uma arquitetura de 2.000 sessões por servidor, o que significa que o crescimento além desse ponto pode exigir instâncias SBCE adicionais, licenciamento adicional e overhead de gestão adicional. Operadores que atingem o teto geralmente descobrem durante um pico de hora cheia que dispara uma conversa de licenciamento não planejada. Um SBC em software que escala até 60.000 sessões por servidor transforma todo esse problema em uma mudança de configuração.

Licenciamento opaco sob o modelo de assinatura é o terceiro. A Avaya migrou o SBCE para assinatura obrigatória, com sessões agrupadas em proporções 7:1 Standard-to-Advanced sob licenciamento Core Suite, e sem preço por sessão publicado. Prever custos de SBC de três e cinco anos exige uma conversa de cotação que depende do restante do contrato Avaya. As equipes de compras e finanças que constroem modelos de TCO para um ciclo OPEX cada vez mais consideram essa opacidade difícil de defender internamente.

Sinais de fim de venda ao redor do portfólio mais amplo da Avaya são o quarto. O Avaya Carrier Services SIP Trunking tem um prazo de migração publicado para setembro de 2025, e outras linhas de produto passaram por fim de venda durante a mesma janela. O próprio SBCE não teve fim de venda declarado no momento desta publicação, mas o padrão de racionalização torna “planejar a substituição agora, no nosso cronograma, enquanto tudo ainda funciona” a opção mais segura do que esperar por uma carta de prazo.

Se o gatilho se aplica a um único par de SBCE em um ambiente Avaya maior, a migração pode ter escopo limitado a esse elemento. Aura, Communication Manager, Session Manager, os planos de discagem e o restante da stack Avaya permanecem onde estão. O SBC é a única peça que muda.

Fase 0: Inventariar o que está no SBCE hoje

Toda migração de SBC bem-sucedida começa com uma auditoria honesta da configuração atual. Pular esta etapa é a causa mais comum de surpresas na virada. O resultado não é uma captura de tela do Avaya SBCE EMS, mas sim uma lista estruturada que mapeia de forma limpa para o que o SBC substituto precisa ser configurado.

Extraia o seguinte do SBCE existente antes de tocar em qualquer outra coisa.

Contagens reais de sessões. Exporte 90 dias de CDRs e encontre a contagem real de pico de sessões concorrentes, não o máximo licenciado. Muitas implantações SBCE operam bem abaixo do teto de 2.000 sessões, o que significa que o substituto pode ser dimensionado pelo uso real em vez da capacidade nominal. O ProSBC suporta implantações de até 60.000 sessões por servidor, então o dimensionamento é tipicamente mais orientado pelos requisitos de implantação do que pelos limites brutos de hardware.

O inventário de Server Configuration. Liste cada Server Configuration no SBCE: troncos de operadoras, peers de Session Manager, trunk groups de Communication Manager, quaisquer integrações de contact center ou CPaaS, quaisquer plataformas de gravação ou analytics, e quaisquer terminais de teste internos. Para cada um, capture o transporte (UDP, TCP, TLS), o endereço e porta, e qual Routing Profile, Media Rule, Signaling Rule e TLS Profile ele se vincula no End Point Flow.

O catálogo de Media Rule e Signaling Rule. Documente preferências de codec, política de SRTP e TLS, intervalos de keep-alive OPTIONS, tratamento de early-media, comportamento de DTMF e quaisquer particularidades por lado. Uma implantação real de SBCE geralmente tem menos conjuntos de regras distintos do que Server Configurations, e um conjunto de regras é frequentemente reutilizado entre múltiplos peers.

Scripts SigMa e Routing Profiles. Exporte cada script SigMa e cada Routing Profile. Esta é a parte da configuração que carrega mais lógica de negócio: reescritas de P-Asserted-Identity para operadoras específicas, normalização de cabeçalho From para o Aura, transformações de plano de discagem, marcação de atestação para STIR/SHAKEN, entre outros. Qualquer item não identificado e recriado durante a migração pode afetar o comportamento após a virada, então scripts não marcados ou não documentados merecem atenção explícita agora, não durante a execução em paralelo.

Topology Hiding Profiles, TLS Profiles e ACLs. Capture cada Topology Hiding Profile, cada certificado TLS e sua data de expiração, cada allowlist ou denylist de IP, cada Application Rule e quaisquer thresholds de DDoS. TLS em particular precisa de tratamento cuidadoso porque a cadeia de certificados no novo SBC deve satisfazer os mesmos peers upstream e downstream sem quebrar a autenticação mútua.

Integrações de STIR/SHAKEN e antifraude. Se o SBCE está assinando ou verificando através de um STI-AS externo, ou se uma plataforma de fraude telefônica está integrada, documente o serviço de assinatura, os certificados e a política de atestação. Essas peças são as mais prováveis de precisar de uma abordagem arquitetural diferente no ProSBC, onde assinatura e antifraude se integram diretamente ao fluxo de roteamento em vez de existirem como elementos de configuração por tronco.

Fase 1: Mapear objetos do Avaya SBCE para objetos do ProSBC

A maior fonte de atrito na migração não é a rede, é o modelo de configuração. Avaya e ProSBC descrevem as mesmas funções de SBC subjacentes com objetos diferentes, e os engenheiros conduzindo a migração precisam de um modelo mental funcional do mapeamento antes de iniciar a construção em laboratório.

A tabela abaixo cobre os objetos que aparecem em toda implantação SBCE. O mapeamento é conceitual, não uma equivalência linha a linha, e a coluna da direita captura a diferença prática que afeta como a configuração é traduzida.

O mapeamento não é a migração. É o contrato contra o qual as próximas três fases trabalham.

Fases 2-4: O plano de migração

O plano abaixo assume um único par de SBCE sendo substituído por uma única instância ProSBC (com ProSBC+ para Alta Disponibilidade (HA) 1+1). Implantações SBCE com múltiplos elementos seguem o mesmo padrão elemento a elemento. A sequência completa geralmente leva de quatro a oito semanas do laboratório à virada, dependendo de quantas operadoras e integrações Aura distintas estão no escopo.

Fase 2: Construção em laboratório

Suba uma instância ProLab no mesmo segmento de rede do SBCE. A licença ProLab é permanentemente gratuita, oferece três sessões concorrentes e provisiona em aproximadamente vinte minutos. Use o laboratório para replicar uma Server Configuration do lado da operadora, um peer de Session Manager ou Communication Manager e qualquer lógica SigMa associada traduzida para Ruby. O objetivo da fase de laboratório é validar o mapeamento na tabela de configuração acima contra o dialeto específico de SIP que a operadora atual e o lado Aura realmente enviam, não recriar a configuração completa de produção.

Se Teams Direct Routing está no escopo do SBCE hoje, teste mTLS, SRTP e o fluxo de OPTIONS SBC-to-Teams contra um tenant de teste. Certificação Teams importa como checkbox de procurement em algumas organizações: o ProSBC suporta Teams Direct Routing e está implantado em ambientes de produção com Teams DR, mas não obteve a certificação formal da Microsoft. Se existe um requisito rígido de certificação, a lista publicada pela Microsoft é a fonte de verdade.

Fase 3: Replicar

Após a construção em laboratório validar o mapeamento, construa a configuração completa de produção na instância ProSBC. Replique cada NAP a partir do inventário de Server Configuration, porte as listas de codecs e a política de SRTP das Media Rules e converta os scripts SigMa em lógica de módulo Ruby. É aqui que o tempo é investido, e é a fase que mais se beneficia de um inventário limpo da Fase 0.

Carregue certificados TLS e configure as definições TLS no nível do NAP. Se TLS e SRTP são necessários de ponta a ponta, valide os cipher suites e crypto suites de SRTP contra o que as operadoras e o Aura realmente negociam, não o que a configuração do SBCE aparenta dizer. Incompatibilidades entre política configurada e tráfego observado são a segunda causa mais comum de surpresas na virada.

Se a assinatura STIR/SHAKEN está no escopo, aponte o routing script para o mesmo serviço de assinatura externo que o SBCE usa hoje, ou para um provedor diferente se a migração for o momento certo para trocar. Configure URLs de assinatura primária e secundária e confirme o comportamento de fallback P-Identity-Bypass.

Fase 4: Paralelo

Mantenha o SBCE em produção. Roteie um tronco de operadora através do ProSBC enquanto todos os outros troncos permanecem no SBCE. Duas a quatro semanas de execução em paralelo geralmente capturam os casos de borda que testes em laboratório não conseguem reproduzir: um cabeçalho P-Charge-Info incomum de uma operadora específica, comportamento de renegociação de codec em hora de pico, um intervalo de OPTIONS diferente do valor documentado, um comportamento de cabeçalho específico do Session Manager que o SBCE trata silenciosamente, ou um código de resposta SIP específico para o qual o ProSBC precisa de uma regra explícita.

Compare taxas de completação de chamadas, scores MOS, precisão de CDR e níveis de atestação STIR/SHAKEN entre os dois caminhos durante o período paralelo. Se um script SigMa acaba fazendo um trabalho que ninguém documentou, descobrir isso em cinco por cento do tráfego é muito melhor do que descobrir em cem.

Virada

Agende a virada durante uma janela de manutenção com o SBCE ligado e aquecido. Mova os troncos de operadora restantes um de cada vez, validando cada um antes de mover o próximo. Atualize registros DNS e quaisquer referências de roteamento upstream para apontar para o ProSBC.

Deixe o SBCE ligado e acessível por pelo menos trinta dias. Este é o caminho de rollback. Se um problema com impacto ao cliente surgir após a virada, redirecionar o tráfego de volta ao SBCE é uma mudança de rede, não um projeto de recuperação. Após a janela de validação, descomissione o chassis do SBCE ou a instância virtual e cancele o item de linha do Core Suite na próxima renovação.

Validação pós-virada

As primeiras setenta e duas horas após a virada são a janela de validação de maior retorno. Três verificações são as mais importantes.

Reconciliação de CDR cobre se os registros de chamadas no novo SBC correspondem ao volume e perfil do antigo. Compare contagens de chamadas hora a hora, duração média das chamadas e a distribuição de códigos de disposição entre a última semana completa no SBCE e os primeiros três dias no ProSBC. Uma divergência geralmente aponta para uma regra SigMa que não sobreviveu ao mapeamento, não para um problema de rede.

Validação de thresholds de fraude importa especificamente porque regras de detecção de fraude telefônica calibradas para o comportamento do SBCE podem disparar demais ou deixar passar padrões no novo SBC. Se scoring de fraude em tempo real está integrado via TransNexus ClearIP, SecureLogix ou YouMail, acompanhe a primeira semana de decisões com atenção e ajuste os thresholds com base nos falsos positivos observados.

Continuidade de monitoramento cobre toda a telemetria que saía do SBCE: traps SNMP, feeds de syslog, streams de CDR via RADIUS ou integração com os produtos de gerenciamento de elementos da Avaya. O ProSBC expõe métricas por NAP e por chamada que se integram com Datadog, Prometheus, um SIEM ou um serviço de monitoramento gerenciado. Confirme que os dashboards estão lendo o novo feed antes de declarar a virada como concluída.

Armadilhas comuns na migração

Em migrações de MSP, ISP, contact center e enterprise, quatro armadilhas aparecem mais do que qualquer outra. Nenhuma é uma surpresa técnica isolada, mas cada uma tende a custar um ou dois dias se não for antecipada.

Lógica SigMa não documentada. Implantações SBCE acumulam regras de reescrita de cabeçalhos ao longo de anos, frequentemente adicionadas por pessoas que já saíram da equipe. Tratar os scripts existentes como definitivos sem entender por que cada um existe é a forma mais rápida de quebrar uma operadora específica na virada. O correto é revisar cada script SigMa durante a Fase 0 e marcar os que têm propósito não óbvio para testes explícitos durante a Fase 4.

Tratamento de P-headers específicos do Aura. Session Manager e Communication Manager produzem comportamento SIP com P-headers proprietários, particularidades de tratamento de sessão e padrões de OPTIONS específicos da Avaya. O SBCE normaliza muito disso silenciosamente. O módulo de roteamento Ruby no ProSBC precisa de regras explícitas para o mesmo comportamento, e testes em laboratório contra uma instância real do Aura, não um terminal de teste SIP genérico, é o que revela esses problemas a tempo de corrigi-los.

Transferência de cadeias de certificados TLS. SBCEs e seus peers upstream às vezes negociam cadeias de certificados que incluem intermediários que o SBCE serve automaticamente. Quando o mesmo certificado é movido para o ProSBC, a configuração da cadeia precisa ser explícita. Teste mTLS para qualquer tronco de operadora com TLS e para Teams Direct Routing no laboratório antes de depender disso em produção.

Premissas de licenciamento agrupado. O agrupamento 7:1 Standard-to-Advanced da Avaya significa que a equipe conduzindo a migração às vezes não tem uma visão clara de quais chamadas estavam consumindo sessões Advanced no SBCE. No ProSBC, onde cada sessão é a mesma sessão a partir de $1.40 por sessão por ano, o modelo de planejamento se torna um número único em vez de uma proporção. Confirme o mix real de funcionalidades “equivalentes a Advanced” em uso antes de dimensionar o substituto, para que a conversa de comparação com finanças se mantenha fundamentada.

Perguntas frequentes