G.711 vs G.729: comparação de codecs VoIP

Praticamente toda negociação de SIP trunk, configuração de IP-PBX e interconexão com operadoras acaba exigindo a mesma decisão: G.711 ou G.729. Os dois codecs são os padrões práticos para voz digital sobre IP, e foram projetados para cenários opostos. O G.711 transmite voz com qualidade próxima à da PSTN e consome 64 kbps por chamada antes de qualquer overhead de rede. O G.729 comprime a mesma fala para 8 kbps usando um algoritmo preditivo agressivo, ao custo de alguma qualidade, processamento de CPU e um longo histórico de complicações com licenciamento.

Este artigo é uma comparação direta: cálculos de largura de banda, qualidade de voz, custo de CPU e licenciamento, compatibilidade com fax e DTMF, e um framework claro para escolher um ou outro em cada trecho de uma rede real. Para o panorama mais amplo de codecs incluindo Opus e AMR, o pilar de SIP trunking cobre o contexto geral. Para a mecânica de conversão entre codecs quando ambos estão na mesma chamada, o artigo sobre transcodificação SBC AMR para G.711 aprofunda o plano de transcodificação.

A diferença de engenharia

G.711 e G.729 estão em extremos opostos do trade-off entre largura de banda e qualidade, e as razões de engenharia remontam a quando cada codec foi projetado.

O G.711 data dos anos 1970 e foi construído para telefonia digital fixa. Ele amostra a fala a 8 kHz, aplica uma compressão logarítmica simples (A-law ou µ-law) a cada amostra e produz um fluxo constante de 64 kbps. A matemática é quase trivial: uma CPU x86 pode codificar e decodificar milhares de fluxos G.711 simultâneos sem esforço, e a conversão entre A-law e µ-law é uma tabela de consulta. A qualidade de voz é essencialmente o que se obtém de uma chamada PSTN por fio.

O G.729 data de meados dos anos 1990, quando o VoIP corporativo estava sendo forçado através de links WAN de 64 kbps ou 128 kbps que também precisavam transportar dados. Ele amostra na mesma frequência de 8 kHz, mas comprime cada quadro de 10 ms para 80 bits usando CS-ACELP, resultando em 8 kbps. O codec analisa janelas curtas de fala, modela o trato vocal do falante como um conjunto de coeficientes de filtro e transmite os coeficientes mais um índice de excitação em vez da forma de onda em si. O receptor sintetiza a fala a partir desses parâmetros. A compressão funciona bem para voz humana e mal para todo o resto, e por isso o G.729 não consegue transportar tons de modem de fax, música em espera ou DTMF in-band de forma confiável.

A referência do lado de sinalização para como cada codec é oferecido e aceito está no corpo SDP do SIP INVITE, definido na RFC 4566. A lista de codecs e sua ordem de prioridade são o que a negociação opera, e um SBC tem visibilidade completa de ambos os lados.

Largura de banda: como os números realmente se apresentam

O número principal de 64 kbps versus 8 kbps é apenas o payload do codec. A largura de banda real por chamada no fio é maior em ambos os lados porque cada pacote RTP carrega cabeçalhos RTP, UDP, IP e Ethernet que adicionam o mesmo número de bytes independentemente de quanto áudio está dentro.

Com um ptime típico de 20 ms, os cálculos funcionam aproximadamente da seguinte forma. O G.711 gera 50 pacotes por segundo, cada um carregando 160 bytes de áudio mais cerca de 54 bytes de cabeçalhos RTP/UDP/IP/Ethernet, totalizando cerca de 85 a 87 kbps por direção. O G.729 gera os mesmos 50 pacotes por segundo, cada um carregando 20 bytes de áudio mais os mesmos 54 bytes de cabeçalhos, totalizando cerca de 31 kbps por direção. A taxa de compressão no payload é de 8 para 1, mas no fio cai para aproximadamente 2,8 para 1.

Três implicações decorrem disso. Primeiro, valores maiores de ptime (30 ou 40 ms) reduzem o overhead dos cabeçalhos e melhoram a proporção para ambos os codecs, mas também aumentam o atraso ponta a ponta se um pacote for perdido, o que importa mais para codecs de baixa taxa de bits que têm menos redundância desde o início. Segundo, o VAD com G.729b reduz ainda mais a taxa de bits média durante o silêncio (frequentemente de 30 a 50 por cento), o que ajuda em links compartilhados, mas prejudica fax e alguns prompts de IVR. Terceiro, a economia de largura de banda do G.729 só importa quando o link está realmente restrito. Dentro de uma LAN gerenciada, em um SIP trunk dedicado moderno ou em qualquer link dimensionado para vídeo HD, a diferença entre 87 kbps e 31 kbps por chamada raramente é o fator decisivo.

Qualidade de voz

O G.711 entrega voz com qualidade próxima à da rede fixa, com um Mean Opinion Score de aproximadamente 4,2, dentro da mesma faixa de uma chamada PSTN por fio. O G.729 fica em torno de 3,9, que a maioria dos ouvintes percebe como “boa, mas levemente comprimida”. Consoantes sussurradas perdem definição, sibilantes ficam suaves e a sensação de presença diminui. Ninguém confundirá a chamada com áudio de alta fidelidade, mas a fala conversacional permanece inteligível.

A diferença importa em três situações específicas. A primeira é a transcodificação em tandem. Cada vez que uma chamada é transcodificada de G.729 para G.711 e de volta, o MOS cai ainda mais porque a compressão com perda se acumula. Dois saltos G.729-para-G.711 no mesmo caminho de chamada empurram a qualidade percebida significativamente abaixo de qualquer codec isoladamente, e por isso os arquitetos de rede tentam minimizar o número de pontos de transcodificação em qualquer rota. A segunda é o áudio wideband. O G.729 limita a chamada a amostragem de 8 kHz independentemente do que cada endpoint seja capaz, então um cliente Microsoft Teams ou WebRTC que poderia entregar Opus wideband soará narrowband através de um trecho G.729. A terceira é fala ruidosa ou sob estresse. O CS-ACELP é otimizado para voz limpa; ruído de fundo, múltiplos falantes simultâneos e fala emocional ou gritada degradam mais acentuadamente no G.729 do que no G.711.

Se a qualidade de voz é o KPI principal de uma implantação (conferências executivas, gravação de contact center, análise de chamadas de vendas), o G.711 vence por padrão. Se a largura de banda é a restrição determinante, a queda de MOS do G.729 é um trade-off conhecido e gerenciável.

CPU, licenciamento e onde o custo se esconde

O G.711 é efetivamente gratuito tanto em termos de CPU quanto de licença. O codec é uma recomendação pública da ITU-T sem ônus de patente, todo PBX e SBC comercial o suporta nativamente, e uma CPU moderna codifica milhares de fluxos simultâneos sem ultrapassar 5 por cento de utilização.

O G.729 tem um histórico mais complicado. O codec esteve sob patentes por anos, com royalties devidos à Sipro Lab Telecom e outros detentores. As patentes começaram a expirar em 2017 e o codec tornou-se efetivamente livre de royalties, o que levou vários projetos de código aberto a adicionar suporte nativo ao G.729. A realidade comercial ainda não acompanhou totalmente. Muitos fabricantes de PBX empresarial (Cisco, Avaya e outros) ainda cobram licenças G.729 por canal, em parte como receita legada e em parte porque placas DSP de hardware ainda carregam termos de licenciamento por canal. O resultado é que o custo por chamada do G.729 em uma implantação de PBX gerenciado é frequentemente dominado pela licença, não pela CPU ou pela largura de banda.

O custo de CPU no codec em si é real, mas modesto em hardware moderno. A codificação/decodificação G.729 puramente em software é viável para centenas de fluxos simultâneos em um núcleo x86 comum. Em escala de operadora, porém, a aceleração DSP por hardware permanece como o padrão prático porque a latência previsível por canal importa mais do que o throughput de pico. O ProSBC se integra com o TSBC-HW-TRANS para transcodificação G.729 acelerada por hardware quando a implantação precisa do codec em escala; a transcodificação G.729 por software dentro do ProSBC está no roadmap do produto para o final de 2026.

Fax, DTMF e compatibilidade com modem

A forma mais clara de resumir esta seção é que o G.711 é seguro para fax e o G.729 é fatal para fax. O CS-ACELP modela fala, não tons de sinalização, e no momento em que um handshake de fax T.30 atinge um codec G.729, os tons de modem são irrecuperáveis. Qualquer caminho de chamada com fax deve permanecer em G.711 de ponta a ponta com as condições de passthrough atendidas (cancelamento de eco desabilitado, VAD desabilitado, perda de pacotes próxima de zero) ou mudar para relay T.38 no SBC. O artigo sobre Fax over IP e T.38 cobre os mecanismos de relay em detalhes.

O DTMF tem uma história paralela. O DTMF in-band transportado como áudio sobrevive ao G.711, mas não ao G.729. A solução é o RFC 2833 (agora RFC 4733), que transporta DTMF como eventos RTP nomeados fora do fluxo de áudio. A maioria dos endpoints SIP modernos negocia RFC 2833 por padrão, mas IVRs legados e alguns tipos de tronco PBX ainda emitem DTMF in-band que um SBC precisa detectar e converter. Se o G.729 está no caminho, o RFC 2833 é obrigatório.

Tráfego de modem e TTY têm a mesma restrição. Dados em banda de voz de qualquer tipo precisam do G.711 ou não sobrevivem à compressão.

Quando usar cada um: um framework de decisão

A escolha geralmente se decide sozinha quando a rede é mapeada de forma honesta. O padrão que se mantém na maioria das implantações é direto.

Dentro de uma LAN gerenciada, em um SIP trunk dedicado dimensionado para a carga de chamadas, em uma conexão UCaaS sobre uma WAN saudável ou em qualquer trecho onde a largura de banda não é a restrição determinante, o G.711 é o padrão. A qualidade é maior, a CPU é mais barata, a interoperabilidade com fax e DTMF é automática e a licença é gratuita. A economia de largura de banda do G.729 não justifica os trade-offs quando o link é largo o suficiente.

O G.729 ainda tem seu lugar em três tipos de links. Segmentos WAN restritos, tipicamente filiais conectadas à matriz por circuitos compartilhados de 1 a 4 Mbps onde cada 50 kbps de margem de voz importa; backhaul móvel, via satélite ou marítimo onde a largura de banda é tarifada ou genuinamente escassa; e interconexões com operadoras legadas onde o provedor upstream oferece apenas G.729 em uma determinada rota de terminação. Em cada um desses casos, a largura de banda economizada é significativa, as preocupações com fax e DTMF são resolvidas com T.38 e RFC 2833, e a queda perceptível de qualidade é aceitável para o caso de uso.

O terreno mais complexo é o de plataformas de PBX hospedado ou contact center de alta densidade, onde os clientes estão distribuídos em uma variedade de tipos de rede. A resposta correta raramente é uma única escolha de codec para a plataforma; é uma política de codec por cliente ou por tronco aplicada no SBC.

Redes mistas e o papel do SBC

A maioria das redes reais tem ambos os codecs em jogo. Uma operadora norte-americana entrega G.711 µ-law para um cliente, uma operadora europeia oferece A-law para outro, uma filial com link restrito roda G.729, e um tenant de Teams Direct Routing negocia Opus ou Silk em seu trecho. O SBC é o único elemento de rede com o controle de mídia por trecho, a visibilidade SDP e os ganchos de política para mediar de forma limpa entre todos eles.

Três funções do SBC importam para a política de codec. A primeira é a negociação de codec por trecho através de reescrita de SDP: o SBC pode oferecer um codec para a operadora e outro diferente para o PBX, fazendo a ponte entre os dois com transcodificação no meio. A segunda é a configuração de codec por NAP, onde cada grupo de tronco carrega sua própria lista de codecs preferenciais, lista de fallback e regras de packetização, tudo aplicado na fronteira sem que nenhum endpoint precise saber o que o outro está fazendo. A terceira é a própria capacidade de transcodificação. A transcodificação por software dentro do ProSBC lida nativamente com G.711 A-law para µ-law, o que cobre o caso de interoperabilidade América do Norte-Europa mais comum. A transcodificação por DSP de hardware através do TSBC-HW-TRANS cobre G.729, AMR e o conjunto completo de codecs complexos em escala de operadora.

Os mecanismos mais profundos de como um SBC B2BUA realmente negocia e converte codecs entre trechos são cobertos no artigo sobre transcodificação SBC AMR para G.711. A decisão diante do arquiteto é qual codec aplicar em cada NAP. O SBC é como essa decisão se torna real no fio.

Perguntas frequentes

Conclusão

A decisão entre G.711 e G.729 raramente é tão equilibrada quanto parece no papel. O G.711 vence em qualidade, CPU, licenciamento, interoperabilidade com fax e confiabilidade DTMF, e a diferença de largura de banda (87 kbps versus 31 kbps por chamada no fio) só importa quando o link está realmente restrito. O G.729 ainda tem seu lugar em segmentos WAN estreitos, backhaul móvel e interconexões com operadoras legadas onde a economia de largura de banda é real. O problema mais difícil na maioria das redes não é escolher um codec, mas aplicar uma política coerente de codec por trecho em uma rede onde ambos estão em jogo. Esse é o trabalho do SBC, e a política por NAP na fronteira é onde a decisão se torna operacional.