Migração de Sonus SBC para ProSBC: por que engenheiros de voz estão abandonando a infraestrutura legada Sonus

O nome Sonus ainda aparece em muitos session border controllers instalados em racks de produção. A empresa por trás dele não existe como negócio independente desde 2017. A Sonus Networks se fundiu com a GENBAND naquele ano, e a entidade combinada foi renomeada para Ribbon Communications. Isso significa que as plataformas SBC 5100, 5200, 5110 e 5210 que engenheiros ainda chamam de “os equipamentos Sonus” são agora hardware legado em um roadmap que a Ribbon, não a Sonus, controla.

Para engenheiros de voz, a questão raramente é se o hardware ainda processa chamadas. Normalmente processa. A questão aparece quando a plataforma atinge o fim do suporte, quando uma auditoria de segurança identifica um equipamento que não recebe mais patches, ou quando a Ribbon propõe uma substituição completa para sua linha atual SBC 5400, 7000 ou SWe. Nesse momento de decisão, um número crescente de equipes aproveita a mudança forçada para avaliar se permanecer no ecossistema Ribbon é realmente a melhor escolha.

Esta página cobre o que significa operar infraestrutura legada Sonus hoje, o cronograma específico de fim de suporte para a linha legada de SBC (Session Border Controller), e o que envolve uma migração de um Sonus SBC para o ProSBC. Se você está comparando o ProSBC com a linha atual de produtos da Ribbon em vez de planejar uma migração de hardware legado, a comparação entre ProSBC e Ribbon SBC é o melhor ponto de partida, e esta página pressupõe que você já a leu ou irá ler.

Como a Sonus se tornou Ribbon, e por que seu SBC ainda diz Sonus

A confusão de marca vale a pena ser esclarecida porque ela influencia a conversa sobre suporte. A Sonus Networks anunciou sua fusão com a GENBAND em maio de 2017, em um acordo que deu aos acionistas de cada empresa aproximadamente metade do negócio combinado e avaliou a nova entidade em cerca de 745 milhões de dólares. A fusão foi concluída naquele mesmo ano e a empresa adotou o nome Ribbon Communications.

O portfólio de produtos Sonus não desapareceu nesse momento. As plataformas SBC da série 5000, os media gateways GSX e o policy server PSX continuaram sob o nome Ribbon, e as equipes de engenharia continuaram mantendo-os por anos. Por isso, um equipamento comprado em 2015 ou 2016 ainda inicializa com a marca Sonus, enquanto todos os boletins de suporte, avisos de fim de vida e cotações de renovação chegam com o logotipo da Ribbon.

A consequência prática é que “usamos Sonus” e “somos clientes Ribbon” descrevem a mesma situação. As decisões de roadmap, o ciclo de vida de suporte e os preços de upgrade para esse hardware legado são todos definidos pela Ribbon hoje.

A realidade operacional de manter infraestrutura Sonus sem suporte

Fim de suporte não é um prazo flexível. Quando uma plataforma o ultrapassa, o fabricante para de enviar atualizações de software, para de emitir correções de segurança e para de aceitar chamados de suporte. Para a linha legada Sonus, essas datas já passaram: o SBC 5100 e 5200 ficaram sem suporte em fevereiro de 2020, e o SBC 5110 e 5210 em outubro de 2023.

A própria Ribbon enquadra a situação em termos de segurança. Sua notificação de fim de suporte para o 5110 e 5210 declara claramente que organizações ainda operando essas plataformas têm redes vulneráveis a ataques cibernéticos, e cita ransomware, exposição a conformidade e risco de governança de dados como as preocupações específicas. Essa avaliação vem do fabricante que construiu o hardware, e é o sinal mais claro que um engenheiro de voz pode apresentar internamente ao justificar o orçamento para uma migração.

A exposição se agrava de algumas formas. Um SBC fica na borda da rede e atua como o perímetro de segurança para todo o tráfego SIP, então um SBC sem patches é um firewall sem patches para a rede de voz. Hardware que está em serviço há oito ou dez anos também acumula risco físico: fontes de alimentação, ventiladores e armazenamento envelhecem, e peças de reposição para um chassi fora de suporte se tornam mais difíceis de obter. Do lado da conformidade, frameworks de segurança e auditorias de clientes cada vez mais exigem que a infraestrutura de borda execute software suportado com um caminho de patches atual, e uma linha de produtos descontinuada não pode satisfazer esse requisito, independentemente de quão estável o equipamento tenha sido.

Nada disso significa que um Sonus SBC legado vai falhar amanhã. Muitos funcionam por anos após a data de suporte sem uma interrupção. O ponto é que o risco não está mais sendo gerenciado ativamente por ninguém, e o custo desse risco recai inteiramente sobre a equipe que opera o equipamento.

O momento de decisão: substituição pela Ribbon atual ou migração para fora

Quando o ciclo de suporte termina, o caminho recomendado pela Ribbon é uma substituição completa para sua linha atual, normalmente o appliance SBC 5400 ou 7000 ou o SBC SWe (Software Edition). Esse caminho mantém o modelo de configuração familiar e preserva o conhecimento operacional existente, o que tem valor real para uma equipe que investiu anos em ferramentas Sonus.

Ele também reabre todas as questões comerciais e arquiteturais que acompanharam a compra original. Migrar para o SBC SWe coloca o deployment em uma plataforma de software atual, mas para muitos operadores de médio porte essa plataforma historicamente rodou sobre VMware, que tem sua própria trajetória de custos após as mudanças de licenciamento da Broadcom. O STIR/SHAKEN da Ribbon passa por um componente PSX separado em vez de residir no SBC. Os preços continuam baseados em cotação, não publicados. Essas não são críticas novas, e estão cobertas em detalhes na comparação entre ProSBC e Ribbon SBC, então esta página não as repete. O ponto relevante para uma decisão de migração é que uma substituição completa é, por si só, um projeto com laboratório, operação paralela e cutover, o que significa que o esforço incremental para avaliar um fornecedor diferente durante essa mesma janela é pequeno.

Esse é o raciocínio que muitos engenheiros de voz seguem. A substituição de hardware vai acontecer de qualquer forma. Se a equipe já está montando nova infraestrutura, operando-a em paralelo e migrando o tráfego, fazer esse trabalho em direção ao ProSBC em vez de um novo appliance Ribbon custa pouco a mais e elimina os pontos de atrito recorrentes ao mesmo tempo. Para uma visão mais ampla das forças que empurram operadores de appliances fixos para software, o guia de substituição de SBCs de hardware por software apresenta o caso geral, e a análise de TCO: SBC de hardware versus software coloca números nele.

O que envolve a migração do Sonus

Uma migração de Sonus para ProSBC é mais um problema de tradução de configuração do que um problema de rede. As duas plataformas executam as mesmas funções de SBC, mas as descrevem com objetos diferentes, então a primeira tarefa é construir um modelo mental de como a configuração Sonus se mapeia no ProSBC.

A tabela abaixo cobre os objetos que aparecem em praticamente todo deployment Sonus. Nenhum dos mapeamentos é exato, então a terceira coluna é a que importa: ela descreve como cada conceito Sonus se comporta de forma diferente uma vez reconstruído no ProSBC.

As fases que seguem esse mapeamento não são específicas da Sonus. Auditar o deployment atual, dimensionar a substituição para o tráfego real, montar um laboratório, operar ambos os SBCs em paralelo, migrar trunk groups um de cada vez e descomissionar a plataforma antiga após validação é a mesma sequência, independentemente do fornecedor que você está deixando. Em vez de repetir aqui, o guia de substituição de SBCs de hardware por software percorre esse framework de cinco etapas em detalhes, incluindo como extrair noventa dias de CDRs para encontrar as contagens reais de sessões de pico e como manter um caminho de rollback aberto durante o cutover.

Considerações específicas da migração Sonus

Algumas questões tendem a ser específicas de migrações Sonus, e não comuns a toda mudança de SBC, e vale a pena levantá-las durante a auditoria em vez de descobri-las no cutover.

Onde a lógica de roteamento realmente reside é a primeira pergunta. Se o deployment usa um PSX externo, grande parte da inteligência de roteamento e política está no PSX e não no próprio SBC, e é essa lógica que precisa ser reproduzida no routing script do ProSBC. Uma equipe que audita apenas a configuração do SBC e ignora o PSX vai perder a parte mais importante da migração. Mapear a política do PSX é normalmente o maior item de trabalho em uma migração Sonus.

O caso apenas ERE é mais simples. Deployments Sonus menores que nunca implantaram um PSX mantêm todo o roteamento no mecanismo integrado, e essa lógica se traduz de forma bastante direta para a tabela de roteamento e o script do ProSBC. Saber qual modelo o deployment utiliza, apenas ERE ou com PSX, define o escopo do projeto desde o início.

Idade de certificados e software importa em hardware que está em serviço desde antes da mudança de nome para Ribbon. Certificados TLS em um equipamento com dez anos podem usar comprimentos de chave ou cadeias que os peers upstream não preferem mais, e a migração é o momento natural para renová-los em vez de portar material obsoleto.

Exportação de configuração é feita via CLI no Sonus SBC. A configuração em execução é capturada de forma mais completa pelo CLI do que por screenshots da interface de gerenciamento, então planeje exportá-la como texto e trabalhar a partir disso como o inventário oficial.

Perguntas frequentes