Transcodificação SBC AMR para G.711: como as redes modernas conectam voz móvel e IP

Redes móveis e redes de voz IP raramente falam o mesmo codec de áudio. Operadoras móveis utilizam por padrão o Adaptive Multi-Rate (AMR), o codec projetado para links de rádio celular. IP-PBXs corporativos, SIP Trunks, centrais de atendimento e a PSTN em geral operam quase universalmente em G.711. Quando uma chamada cruza essa fronteira, em algum ponto do caminho um dispositivo precisa converter o áudio de um formato para o outro em tempo real. Esse dispositivo é quase sempre um Controlador de Borda de Sessão (SBC), e a conversão em si é chamada de transcodificação.
Este artigo explica o que a transcodificação SBC AMR para G.711 realmente faz, por que ela fica na camada do SBC em vez de dentro do PBX, a diferença entre transcodificação por hardware e software, e os cenários de implantação onde ela mais importa. O objetivo é um panorama claro e agnóstico de fornecedor sobre como a interoperação de voz móvel-para-IP realmente acontece na borda da rede.
![]()
O que a transcodificação AMR para G.711 realmente faz
O trabalho é simples de descrever e surpreendentemente exigente de executar. De um lado da chamada, o SBC recebe pacotes RTP com áudio codificado em AMR, amostrado e comprimido para um link de rádio móvel. Do outro lado, ele precisa entregar pacotes RTP com áudio G.711, o formato que todo IP-PBX, SIP Trunk e gateway PSTN espera. Para conectar os dois, o SBC decodifica o fluxo AMR de volta para amostras PCM brutas, recodifica essas amostras como G.711 (A-law ou µ-law, dependendo do destino) e encaminha o resultado com novos timestamps e payload type RTP. A mesma conversão ocorre no sentido inverso no caminho de retorno.
AMR e G.711 foram projetados para mundos diferentes
O AMR existe porque a largura de banda de rádio é escassa e as condições mudam segundo a segundo. O AMR-NB comprime voz de 8 kHz para tão pouco quanto 4,75 kbps; o AMR-WB eleva a taxa de amostragem para 16 kHz para qualidade notavelmente melhor, mas ainda comprime agressivamente. O G.711, por outro lado, foi projetado na década de 1970 para telefonia fixa onde largura de banda era barata e a latência precisava ser próxima de zero. Ele aplica uma compressão logarítmica simples à voz de 8 kHz e produz um fluxo constante de 64 kbps. Os dois codecs não são intercambiáveis, e nenhum IP-PBX vai repentinamente começar a falar AMR.
Onde a conversão pertence
O PBX e o core móvel são locais inadequados para transcodificar. Pedir a um PBX que decodifique AMR nativamente obriga cada licença de terminal a incluir uma pilha de codec móvel, o que a maioria não faz. Pedir ao core móvel que emita G.711 anula toda a razão pela qual o móvel usa AMR em primeiro lugar. Colocar a transcodificação no SBC mantém ambos os lados limpos: cada rede fala seu codec nativo até a borda, e a conversão acontece uma vez, na fronteira, onde a operadora já controla sinalização e mídia.
Por que um SBC é o lugar certo para transcodificar
Três propriedades da arquitetura SBC fazem dele o ponto natural de transcodificação. A primeira é o controle de mídia por leg. Como um SBC termina o RTP em cada lado e o conecta com controle total de B2BUA, ele pode aplicar diferentes codecs, tamanhos de pacote e tratamentos de DTMF em cada leg independentemente. A segunda é a reescrita de SDP. O SBC vê ambos os INVITEs e pode reescrever a lista de codecs que cada lado anuncia, dizendo à rede móvel “eu suporto AMR” enquanto diz ao PBX “eu suporto G.711,” e conectando a mídia real no meio. A terceira é a política. A escolha de codec raramente é apenas uma preferência técnica; ela é moldada por contratos com operadoras, contagens de licenças e metas de qualidade. Colocar essas políticas em uma configuração por NAP no SBC as mantém visíveis e auditáveis.
O handshake SDP
Quando uma chamada originada no móvel chega ao SBC, o INVITE de entrada tipicamente anuncia AMR-WB como codec preferido, com AMR-NB e possivelmente G.711 como fallbacks. O INVITE de saída que o SBC envia ao IP-PBX geralmente oferece apenas G.711, porque é o que o PBX espera. O SBC aceita AMR no leg de entrada, aceita G.711 no leg de saída e transcodifica entre os dois. Conforme definido na RFC 4566, o corpo SDP é o que torna essa mediação de codec possível sem que nenhum terminal saiba que o outro existe.
Re-INVITE e mudanças de codec durante a chamada
Redes móveis ocasionalmente renegociam codecs durante a chamada, por exemplo quando um aparelho se move entre células com diferentes condições de rádio. Um SBC B2BUA absorve o re-INVITE resultante no leg móvel sem perturbar o leg do PBX, o que mantém a chamada estável do ponto de vista da empresa.
Uma topologia típica de transcodificação AMR para G.711: mídia codificada em AMR da rede móvel termina no SBC, um DSP de hardware realiza a conversão e o SBC encaminha mídia G.711 para o IP-PBX ou SIP Trunk no outro leg. Clique para ampliar.
Transcodificação por hardware vs software
Nem todo codec custa o mesmo para transcodificar. O G.711 é essencialmente uma tabela de consulta; converter entre A-law e µ-law, ou entre G.711 e PCM bruto, é barato o suficiente para que qualquer servidor x86 moderno faça isso em software para centenas de chamadas simultâneas. AMR é outra história. AMR-NB e AMR-WB usam codificação preditiva linear com múltiplas taxas de bits adaptativas, e o custo de CPU por canal torna a transcodificação puramente em software impraticável em escala de operadora.
Por que a transcodificação AMR precisa de DSPs hoje
DSPs de hardware são construídos especificamente para a matemática que o AMR exige. Um único appliance DSP de 1U pode entregar milhares de sessões simultâneas de transcodificação AMR para G.711 com latência consistente, enquanto a mesma carga de trabalho em CPUs commodity consumiria uma ordem de magnitude mais silício e produziria jitter menos previsível. Para qualquer implantação em escala significativa, incluindo agregação móvel, handoff VoLTE e voz corporativa gerenciada com breakout móvel, a transcodificação acelerada por hardware é o padrão prático.
Quando a transcodificação por software é suficiente
A transcodificação por software dentro do SBC lida com a conversão de G.711 µ-law para A-law nativamente, o que cobre o caso de interoperabilidade América do Norte-Europa mais comum. Ela também lida com conversão RTP para SRTP e mudanças de packetização. O ponto em que uma implantação cruza de “software é suficiente” para “você precisa de um DSP” é o momento em que um codec complexo como AMR entra em cena.
Alinhamento de taxa de amostragem
O AMR-WB amostra a 16 kHz, o G.711 a 8 kHz. A transcodificação precisa fazer downsample no caminho de saída para G.711 e upsample no caminho de retorno. O downsample é simples; o upsample não pode recuperar detalhes que AMR-NB ou G.711 nunca carregaram, razão pela qual um leg wideband-para-narrowband soa notavelmente mais abafado que o lado móvel original. Não há truque de SBC que corrija isso; é uma propriedade do codec de destino.
Cenários comuns de implantação
Operadora móvel para IP-PBX ou SIP Trunk
O caso clássico: uma operadora móvel entrega uma chamada a um IP-PBX corporativo ou a um revendedor de SIP Trunk. AMR-WB no leg móvel, G.711 no leg corporativo, transcodificação no SBC. Esta é a implantação que a maioria das operadoras e MSPs encontra primeiro, e ela escala linearmente com o tráfego simultâneo originado no móvel.
Handoff VoLTE para voz legada
Uma chamada VoLTE feita em um aparelho 4G chega como AMR-WB na borda do IMS, e de lá precisa chegar a algum ponto na PSTN mais ampla. Se o próximo hop é um gateway TDM ou um SIP Trunk legado, o SBC fica entre o core IMS e o gateway, transcodificando AMR-WB para G.711 para que o resto da rede nunca veja o codec wideband.
Bridging WebRTC e Teams
Terminais WebRTC usam Opus, Microsoft Teams usa G.722, e o móvel usa AMR. Um SBC conectando plataformas UCaaS a operadoras móveis tipicamente precisa de um plano de transcodificação que lide com todos os três, com G.711 como codec intermediário comum para entrega PSTN downstream.
DTMF junto com voz
O mesmo hardware que realiza a conversão AMR para G.711 também lida com a tradução de DTMF RFC 2833 para inband no mesmo plano de mídia. Executar ambos em um único plano de transcodificação simplifica dimensionamento e licenciamento em vez de distribuir o trabalho entre múltiplos appliances.
Considerações sobre qualidade de voz
Cada etapa de transcodificação tem um custo, tanto em latência quanto em qualidade percebida. O impacto de latência por leg é pequeno, tipicamente alguns milissegundos quando DSPs estão fazendo o trabalho, mas é cumulativo entre hops, e em um caminho com dois pontos de transcodificação o atraso acumulado começa a importar para eco e cadência da conversa. O Mean Opinion Score (MOS) também degrada cada vez que a voz é decodificada e recodificada, com a queda mais acentuada em conversões wideband para narrowband onde informação é genuinamente perdida. Duas diretrizes práticas valem: minimize o número de hops de transcodificação em qualquer caminho dado, e prefira o codec de maior qualidade que a rede de destino possa sustentar. Se o leg do PBX suporta G.711 a 64 kbps completos, não introduza G.729 apenas para economizar largura de banda em um leg que não precisa.
Perguntas frequentes
Posso transcodificar AMR para G.711 em software em um SBC virtual?
Não em escala de produção hoje. O custo de CPU da codificação e decodificação AMR é alto o suficiente para que DSPs de hardware permaneçam a opção prática para qualquer contagem significativa de chamadas simultâneas. A transcodificação por software para AMR está no roadmap do ProSBC para o final de 2026; até lá, o caminho suportado é uma unidade de transcodificação por hardware dedicada junto ao SBC.
Qual é a diferença entre AMR-NB e AMR-WB para fins de transcodificação?
O AMR-NB amostra a 8 kHz; o AMR-WB amostra a 16 kHz. A transcodificação de qualquer um para G.711 reduz a chamada a áudio de 8 kHz, mas uma chamada wideband passando por G.711 narrowband perde notavelmente detalhes de alta frequência. O SBC lida com ambos os formatos; a compensação de qualidade vem do codec de destino, não do SBC.
A transcodificação quebra a atestação STIR/SHAKEN?
Não. O STIR/SHAKEN assina a sinalização SIP, não a mídia, então a conversão de codec no SBC não tem efeito no cabeçalho Identity ou no nível de atestação da chamada. Sinalização e mídia são tratadas independentemente.
Quantas sessões de transcodificação um appliance 1U típico suporta?
Depende de quais codecs estão envolvidos. Um appliance DSP de hardware moderno suporta milhares de sessões G.711 simultâneas, com contagens menores para codecs complexos como AMR-WB. A tradução de DTMF para inband roda no mesmo hardware sem reduzir a capacidade de sessões. O dimensionamento deve ser feito com base no mix de codecs real que você espera em produção.
O SBC precisa saber se o leg móvel é AMR-NB ou AMR-WB?
Sim. Os dois formatos usam diferentes payload types RTP e diferentes taxas de amostragem, e o SBC negocia um ou outro através do SDP. Um SBC corretamente configurado aceita ambos e transcodifica o que for oferecido para G.711 no leg de saída.
Conclusão
A transcodificação AMR para G.711 é a infraestrutura discreta que mantém voz móvel e IP conversando entre si. Redes móveis continuarão enviando AMR enquanto o rádio celular permanecer limitado em largura de banda, e IP-PBXs continuarão exigindo G.711 enquanto a PSTN mais ampla o fizer. O SBC é o único ponto no caminho com o controle de mídia por leg, a visibilidade SDP e os hooks de política para mediar essa lacuna de forma limpa, e para cargas de trabalho AMR em produção, a transcodificação acelerada por hardware é o que realmente entrega o throughput e a consistência que o caso de uso exige. Dimensionamento, política de codec e metas de qualidade são decisões do arquiteto de rede; o SBC e seu plano de transcodificação são como essas decisões se tornam reais na rede.
Transcodifique AMR para G.711 com ProSBC e TSBC-HW-TRANS
O ProSBC lida com a sinalização SIP, controle de mídia B2BUA, negociação de codec e política por NAP necessários para conectar voz móvel e IP. Para o trabalho de transcodificação em si, o ProSBC se combina com o TSBC-HW-TRANS, uma unidade de transcodificação por hardware de grau carrier que suporta até 2.744 sessões por enclosure 1U e escala até 30.000 sessões. O TSBC-HW-TRANS lida com AMR-NB, AMR-WB, G.711, G.723, G.729 e conversão DTMF em silício DSP dedicado, além de reprodução de prompts e gravação de chamadas no mesmo plano de mídia.
O ProSBC em si roda em VMware, KVM, AWS, Azure ou baremetal, e se integra com a unidade de transcodificação pelo mesmo plano de gerenciamento. Operadoras dimensionando para handoff VoLTE, interconexão móvel-para-empresa, ou qualquer implantação que precise de suporte AMR hoje podem executar o software SBC onde sua borda de rede já está e adicionar transcodificação por hardware na capacidade que seu mix de codecs exige.
Prefere avaliar por conta própria primeiro? Inicie seu teste gratuito de 30 dias.