Saindo do AudioCodes Mediant: guia de migração para provedores de serviços
Implantações do AudioCodes Mediant funcionam. Esse raramente é o problema. A questão da migração surge quando algo mais muda: um Mediant 4000 ou 9000 recebe um aviso de fim de vida útil, uma política de aquisição exclusivamente OPEX chega à mesa, a unidade de negócios de contact center pergunta por que o fornecedor do SBC também está inscrevendo seus clientes corporativos via Operator Connect, ou o item de transcodificação na cotação de renovação deixa de fazer sentido. Nenhum desses gatilhos exige descartar o restante da stack AudioCodes. O SBC é um componente único na borda, e pode ser substituído isoladamente.
Esta página é a versão operacional da comparação com a alternativa ao AudioCodes. Ela pressupõe que a decisão de avaliar uma substituição já foi tomada e mostra como uma migração do AudioCodes Mediant para o ProSBC realmente funciona: como auditar a configuração existente do Mediant, como os objetos de configuração do AudioCodes mapeiam para os do ProSBC, como executar os dois SBCs em paralelo com segurança e como planejar uma migração com um caminho real de rollback.
O que desencadeia uma migração do AudioCodes Mediant 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 a um determinado ambiente define como o projeto é dimensionado.
Fim de vida útil do hardware é o gatilho mais previsível. A AudioCodes publicou avisos de fim de venda e fim de suporte para chassis Mediant mais antigos, incluindo algumas revisões de CPU da série 4000 e placas anteriores da série 1000. Quando o appliance atinge o fim do suporte, a escolha é uma atualização forçada no mesmo fornecedor ou uma migração limpa para um SBC por software que roda em hardware commodity.
Política de aquisição OPEX é o segundo. Provedores de serviços e operadores de contact center que migraram todas as outras categorias de infraestrutura para faturamento por assinatura encontram cada vez mais um compromisso CapEx com seu SBC. A AudioCodes oferece preços por assinatura e baseados em uso, mas o ciclo de negociação e a ausência de valores publicados por sessão dificultam a modelagem de margens antes da chegada de uma cotação.
Conflito de canal é relevante especificamente para MSPs e operadores de call center que revendem chamadas Teams. A AudioCodes é Microsoft Premier Partner e provedora Operator Connect, o que significa que o mesmo fornecedor que fornece o SBC também vende serviços de chamadas Teams para os potenciais clientes do MSP. Migrar o SBC para um fornecedor de infraestrutura que não possui programa Operator Connect elimina esse conflito na camada de tecnologia.
Economia de transcodificação é o quarto, e tende a surgir tardiamente. O licenciamento de transcodificação da AudioCodes é por canal e por codec, e em escala o item na cotação de renovação se torna relevante. Provedores de serviços que precisam de conversão Opus para G.711 para tráfego móvel e WebRTC são os que mais sentem o impacto.
Se o gatilho se aplica a um único Mediant em um parque multi-SBC, a migração pode ser dimensionada para esse único elemento. O PBX, as operadoras, o plano de discagem e o restante da frota Mediant permanecem onde estão.
Fase 0: inventariar o que está no Mediant 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 no cutover. O resultado não é uma captura de tela da interface Web do AudioCodes, é uma lista estruturada que mapeia de forma limpa para o que o SBC substituto precisa ser configurado.
Extraia o seguinte do Mediant 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. A maioria das implantações Mediant opera bem abaixo da capacidade nominal, e o SBC substituto deve ser dimensionado para o uso real. O ProSBC escala até 60.000 sessões por servidor, então a questão prática de dimensionamento geralmente é licenciamento, não hardware.
O inventário de IP Groups. Liste cada IP Group no Mediant: troncos de operadoras, o PBX, quaisquer tenants Teams Direct Routing ou Operator Connect, quaisquer plataformas de gravação ou análise SIP e quaisquer endpoints de teste internos. Para cada um, capture o transporte (UDP, TCP, TLS), o endereço de proxy, o IP Profile associado e o SRD ao qual pertence.
O catálogo de IP Profiles. Documente as preferências de codec, requisitos de transcodificação, política de SRTP e TLS, intervalos de keep-alive OPTIONS, tratamento de early-media e quaisquer particularidades por lado para cada perfil. Uma implantação real do Mediant geralmente tem menos perfis distintos do que IP Groups, e um perfil frequentemente é reutilizado em múltiplos peers.
Manipulation Sets e tabelas de IP-to-IP Routing. Exporte cada regra de Manipulation Set e cada entrada de roteamento. Esta é a parte da configuração que carrega a maior parte da lógica de negócios: reescritas de P-Asserted-Identity para operadoras específicas, normalização de cabeçalho From, transformações de plano de discagem, marcação de atestação para STIR/SHAKEN, entre outros. Qualquer coisa que não sobreviva à migração se perde no cutover.
Certificados, ACLs e política de segurança. Capture cada certificado TLS e sua data de expiração, cada lista de permissão ou bloqueio de IP, cada Classification Rule e quaisquer limites de DDoS. O 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.
STIR/SHAKEN e integrações antifraude. Se o Mediant está assinando ou verificando via STIR/SHAKEN integrado da AudioCodes, documente o serviço de assinatura, o certificado e a política de atestação. O mesmo para qualquer integração antifraude que se conecte ao SBC. Essas peças são as mais propensas a necessitar de uma escolha arquitetural diferente no ProSBC, onde assinatura e fraude são preocupações de primeira classe do mecanismo de roteamento, e não toggles de configuração.
Fase 1: mapear objetos do AudioCodes Mediant para objetos do ProSBC
A maior fonte de atrito na migração não é a rede, é o modelo de configuração. AudioCodes e ProSBC descrevem as mesmas funções subjacentes do SBC com objetos diferentes, e os engenheiros que conduzem a migração precisam de um modelo mental funcional do mapeamento antes de iniciar o build de laboratório.
A tabela abaixo cobre os objetos que aparecem em toda implantação Mediant. O mapeamento é conceitual, não uma equivalência direta, e a coluna mais à direita captura a diferença prática que afeta como a configuração é traduzida.
| Objeto AudioCodes Mediant | Equivalente ProSBC | O que muda na prática |
|---|---|---|
| IP Group | NAP (Network Access Point) | Mapeamento um para um. O NAP carrega transporte, proxy, lista de codecs, configurações de SRTP e ACL que o Mediant divide entre o IP Group e seu IP Profile associado. |
| SRD (SIP Realm Definition) | Agrupamento de NAP na lógica de roteamento | O ProSBC não possui um container de realm separado. A segregação por tenant ou unidade de negócios é tratada pela nomenclatura de NAP, pela lógica do Routing Script e por ACLs, em vez de um objeto de configuração pai. |
| IP Profile | Campos de configuração NAP e SIP Profiles | O comportamento SIP e de mídia por lado é incorporado ao NAP ou Profiles. Qualquer coisa fora das configurações de NAP ou Profile no ProSBC é comum a todos os NAPs e troncos SIP. |
| Media Realm | Vinculação de interface de mídia do NAP | A seleção de interface de mídia é definida diretamente no NAP. Não há um objeto de realm separado para manter. |
| SIP Interface | Transporte NAP e interface de sinalização | Incorporado ao NAP. O ProSBC trata a interface de sinalização como uma propriedade do NAP, não como um recurso compartilhado. |
| Message Manipulation Set | Routing Script (módulo Ruby) | A maior mudança conceitual. Listas de regras estáticas se tornam código procedural que roda por chamada. Os engenheiros ganham consultas HTTP externas, lógica condicional contra qualquer parâmetro de chamada e a capacidade de integrar fraude, LNP e STIR/SHAKEN na própria decisão de roteamento. |
| Tabela IP-to-IP Routing | Tabela de roteamento mais Routing Script | Entradas de roteamento simples mapeiam diretamente. Roteamento condicional (failover de operadora, roteamento por horário, menor custo) é implementado no Routing Script em vez de como linhas adicionais na tabela. |
| Classification Rules | Correspondência de IP de origem do NAP mais ACLs | A classificação de entrada é tratada pela correspondência do IP de origem e das características SIP com a definição do NAP. |
| Coder Group | Lista de codecs do Profile | Os Profiles carregam a lista de codecs, não os NAPs. Um único Profile pode ser atribuído a múltiplos NAPs, mas cada NAP usa apenas um Profile. |
| TLS Context | Configuração TLS do NAP e repositório de certificados | Os certificados são enviados uma vez e referenciados pelo NAP. O mTLS para Teams Direct Routing segue o mesmo padrão do Mediant. |
| STIR/SHAKEN (integrado) | Módulo de assinatura do Routing Script | O STIR/SHAKEN do ProSBC roda através do mecanismo de roteamento e se integra com provedores externos STI-AS (TransNexus ClearIP, Neustar ou qualquer serviço de assinatura baseado em HTTP) com endpoints primário e secundário e fallback P-Identity-Bypass. A atestação se torna uma decisão por chamada em vez de uma configuração por tronco. |
| OVOC / Routing Manager | Portal Web ProSBC mais API | O gerenciamento de painel único se consolida no Portal Web ProSBC. A orquestração multi-elemento é tratada pela API em vez de um produto de gerenciamento separado. |
O mapeamento não é a migração. É o contrato contra o qual as duas fases seguintes trabalham.
Fases 2-4: o plano de migração
O plano abaixo pressupõe um único Mediant sendo substituído por uma única instância ProSBC. Implantações Mediant com múltiplos elementos seguem o mesmo padrão elemento por elemento. Toda a sequência normalmente leva de quatro a oito semanas do laboratório ao cutover, dependendo de quantas operadoras distintas e integrações de PBX estão no escopo.
Fase 2: build de laboratório
Instale uma instância ProLab no mesmo segmento de rede do Mediant. A licença ProLab é permanentemente gratuita, oferece três sessões concorrentes e é provisionada em aproximadamente vinte minutos. Use o laboratório para replicar um IP Group do lado da operadora, um IP Group do lado do PBX e quaisquer regras de Manipulation Set associadas. 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 envia, não recriar toda a configuração de produção.
Se Teams Direct Routing está no escopo, teste mTLS, SRTP e o fluxo OPTIONS de SBC para Teams contra um tenant de teste. A certificação Teams importa como um checkbox de aquisição em algumas organizações compradoras: o ProSBC suporta Teams Direct Routing e está implantado em ambientes de produção Teams DR, mas não obteve a certificação formal da Microsoft. Se existir um requisito rígido de certificação, a lista publicada pela Microsoft é a fonte oficial.
Fase 3: replicar
Uma vez que o build de laboratório comprove o mapeamento, construa a configuração completa de produção na instância ProSBC. Replique cada NAP a partir do inventário de IP Groups, porte as listas de codecs dos IP Profiles e converta os Manipulation Sets em lógica de módulo Ruby. É aqui que o tempo é gasto, e esta é a fase que mais se beneficia de um inventário limpo da Fase 0.
Faça upload dos certificados TLS e configure as configurações TLS em nível de NAP. Se TLS e SRTP são necessários de ponta a ponta, valide os cipher suites e crypto suites SRTP contra o que as operadoras e o PBX realmente negociam, não o que a configuração do Mediant aparenta dizer. Incompatibilidades entre a política configurada e o tráfego observado são a segunda causa mais comum de surpresas no cutover.
Se a assinatura STIR/SHAKEN está no escopo, aponte o Routing Script para o mesmo serviço de assinatura externo que o Mediant usa, 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 Mediant em produção. Encaminhe um tronco de operadora pelo ProSBC enquanto todos os outros troncos permanecem no Mediant. Duas a quatro semanas de execução em paralelo normalmente detectam os casos extremos que os testes de 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 horário de pico, um intervalo OPTIONS que difere do valor documentado, ou um código de resposta SIP específico que o Mediant trata silenciosamente e 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 uma regra de roteamento do Mediant está fazendo um trabalho que ninguém documentou, encontrá-la em cinco por cento do tráfego é muito melhor do que encontrá-la em cem por cento.
Cutover
Agende o cutover durante uma janela de manutenção com o Mediant ligado e aquecido. Mova os troncos de operadoras restantes um de cada vez, validando cada um antes de mover o próximo. Atualize os registros DNS e quaisquer referências de roteamento upstream para apontar para o ProSBC.
Deixe o Mediant ligado e acessível por pelo menos trinta dias. Este é o caminho de rollback. Se um problema com impacto no cliente surgir após o cutover, redirecionar o tráfego de volta para o Mediant é uma mudança de rede, não um projeto de recuperação. Após a janela de validação passar, descomissione o chassis ou a instância virtual do Mediant e cancele o item de suporte.
Validação pós-cutover
As primeiras setenta e duas horas após o cutover são a janela de validação de maior rendimento. Três verificações são as mais importantes.
Reconciliação de CDR verifica se os registros de chamadas no novo SBC correspondem ao volume e formato do anterior. Compare contagens de chamadas hora a hora, duração média de chamada e a distribuição de códigos de disposição entre a última semana completa no Mediant e os primeiros três dias no ProSBC. Uma divergência geralmente aponta para uma regra de roteamento que não sobreviveu ao mapeamento, não para um problema de rede.
Validação de limites de fraude é importante especificamente porque as regras de detecção de fraude telefônica ajustadas ao comportamento do Mediant podem disparar em excesso ou perder padrões no novo SBC. Se a pontuação de fraude em tempo real está integrada via TransNexus ClearIP, SecureLogix ou YouMail, acompanhe a primeira semana de decisões cuidadosamente e ajuste os limites com base nos falsos positivos observados.
Continuidade de monitoramento cobre toda a telemetria que estava fluindo do Mediant: traps SNMP, feeds de syslog, streams de CDR via RADIUS ou uma parceria com o produto de gerenciamento de elementos do Mediant. O ProSBC expõe métricas por NAP e por chamada que podem ser direcionadas para Datadog, Prometheus, um SIEM ou um serviço de monitoramento gerenciado. Confirme que os dashboards estão lendo o novo feed antes de declarar o cutover como concluído.
Armadilhas comuns na migração
Em migrações de MSP, ISP e contact center, quatro armadilhas aparecem com mais frequência do que quaisquer outras. Nenhuma delas é uma surpresa técnica isoladamente, mas cada uma tende a custar um ou dois dias se não for antecipada.
Lógica de Manipulation Set não documentada. Implantações Mediant acumulam regras de reescrita de cabeçalhos ao longo de anos, frequentemente adicionadas por pessoas que já saíram da equipe. Tratar as regras existentes como oficiais sem entender por que cada uma existe é a forma mais rápida de quebrar uma operadora específica no cutover. O caminho correto é revisar cada regra de Manipulation Set durante a Fase 0 e marcar aquelas cujo propósito não é óbvio para testes explícitos durante a Fase 4.
Suposições sobre transcodificação. Os AudioCodes Mediants fazem transcodificação assistida por hardware para um amplo conjunto de codecs, incluindo Opus, G.729 e AMR. A transcodificação por software do ProSBC atualmente cobre G.711 ALAW e ULAW; transcodificação de codecs mais ampla está no roadmap, mas requer confirmação cuidadosa antes de uma migração que dependa dela. Tráfego móvel e WebRTC que atualmente depende da transcodificação do Mediant precisa de um plano confirmado, não de uma suposição.
Transferência de cadeia de certificados TLS. Mediants e seus peers upstream às vezes negociam cadeias de certificados que incluem intermediários que o Mediant serve automaticamente. Quando o mesmo certificado é movido para o ProSBC, a configuração da cadeia precisa ser explícita. Teste mTLS para Teams Direct Routing e qualquer tronco de operadora com TLS no laboratório antes de confiar nele em produção.
Compatibilidade de hiperplataforma para HA no Azure. O ProSBC roda em VMware, KVM, Proxmox, AWS, Azure e bare metal. O HA nativo 1+1 no Azure requer configuração adicional em comparação com o comportamento padrão no VMware ou KVM. Se o Mediant existente roda no Azure com HA, levante esse requisito durante a Fase 2 em vez de descobri-lo durante a Fase 4.
Perguntas frequentes
Quanto tempo uma migração do AudioCodes Mediant normalmente leva?
Quatro a oito semanas, da auditoria da Fase 0 ao cutover completo, é a faixa típica para uma migração de elemento único. As Fases 0 e 1 (auditoria e mapeamento) geralmente levam uma a duas semanas, a Fase 2 (build de laboratório) leva cerca de uma semana, a Fase 3 (replicar a configuração completa) é de duas a três semanas dependendo da complexidade dos Manipulation Sets, e a Fase 4 (execução em paralelo) leva de duas a quatro semanas. O cutover em si é uma única janela de manutenção. Implantações com múltiplos elementos escalam linearmente: cada Mediant sendo substituído adiciona seu próprio trabalho de Fase 3 e Fase 4.
Precisamos alterar nosso PBX, plano de discagem ou contratos de operadora para migrar do Mediant?
Não. O SBC fica na borda entre as operadoras e a infraestrutura de voz interna, e substituí-lo não requer alterações no PBX, no plano de discagem ou nos contratos de tronco SIP com as operadoras. O PBX continua falando SIP para qualquer endereço IP que o SBC apresente, e as operadoras continuam terminando troncos para qualquer endereço IP que o SBC apresente a elas. Apenas o equipamento no meio muda.
O que acontece com nossa configuração STIR/SHAKEN durante a migração?
O ProSBC implementa assinatura e verificação STIR/SHAKEN através de seu mecanismo de roteamento Ruby, integrando-se com provedores externos STI-AS (TransNexus ClearIP, Neustar ou qualquer serviço de assinatura baseado em HTTP) em vez de um módulo de assinatura integrado. Durante a migração, o serviço de assinatura pode permanecer o mesmo, ou este pode ser o momento de avaliar um provedor diferente. Endpoints de assinatura primário e secundário fornecem redundância, e um fallback P-Identity-Bypass garante que as chamadas não caiam se o serviço de assinatura estiver brevemente indisponível. A atestação se torna uma decisão por chamada no Routing Script em vez de uma configuração por tronco.
O ProSBC pode rodar no mesmo hypervisor que usamos para o Mediant VE?
O Mediant VE suporta VMware, KVM, Hyper-V, OpenStack, AWS, Azure, GCP e ambientes de container. O ProSBC roda em VMware, KVM, Proxmox, AWS, Azure e bare metal. Se a implantação existente do Mediant VE é em VMware, KVM, AWS ou Azure, o ProSBC roda na mesma plataforma. Implantações em Hyper-V, GCP e container não são atualmente suportadas no ProSBC e precisariam de uma decisão de plataforma antes da migração. O HA nativo no Azure também requer configuração adicional no ProSBC em comparação com o padrão no VMware e KVM.
E se não tivermos expertise interna em SBC para conduzir a migração?
A TelcoBridges oferece um Serviço Gerenciado que cuida da migração de ponta a ponta: auditoria da Fase 0, mapeamento de configuração, implantação do ProSBC, gerenciamento da execução em paralelo e execução do cutover. O Serviço Gerenciado inclui ProSBC+ com alta disponibilidade 1+1, suporte 24×7 e monitoramento contínuo. É hospedado na infraestrutura da TelcoBridges ou em uma plataforma escolhida pelo cliente. Para equipes sem engenheiros de SBC dedicados, este geralmente é o caminho certo: o custo de uma migração gerenciada é uma fração do custo de contratar um especialista interno em SBC.
Qual é o plano de rollback se algo der errado após o cutover?
O Mediant permanece ligado e acessível por pelo menos trinta dias após o cutover. Se um problema com impacto no cliente surgir nessa janela, redirecionar o tráfego de volta para o Mediant é uma mudança de rede, não um projeto de recuperação. O plano de quatro fases é especificamente projetado em torno desse caminho de rollback: o Mediant nunca é descomissionado até que o ProSBC tenha sido validado sob tráfego real de produção por várias semanas. A maioria das migrações nunca precisa do rollback, mas tê-lo disponível é o que torna a execução em paralelo e o cutover seguros.
Comece a migração do AudioCodes Mediant com um laboratório, não com um compromisso
A forma de menor risco para avaliar se o ProSBC se encaixa em um ambiente AudioCodes Mediant existente é implantar uma instância ProLab e replicar um IP Group contra uma operadora real. A licença ProLab é permanentemente gratuita, oferece três sessões concorrentes e é provisionada em aproximadamente vinte minutos. Não é necessário engajamento comercial para começar.
Para equipes que preferem uma avaliação guiada, o Serviço Gerenciado cobre a migração completa: auditoria, mapeamento, implantação, execução em paralelo, cutover e operações contínuas.
Comparando fornecedores primeiro? Veja a comparação completa ProSBC vs. AudioCodes ou Substituindo SBC de hardware por software.