Ligação muda e áudio de um lado só no VoIP: causas e como corrigir

O que é ligação muda e o que é áudio de um lado só?

Ligação muda é a chamada VoIP que completa sem áudio em nenhum dos dois sentidos: ninguém ouve ninguém. Áudio de um lado só, ou áudio unidirecional, é a chamada em que um lado ouve e o outro não. Nos dois casos a sinalização SIP funcionou; o que falhou foi o caminho do áudio, o fluxo RTP.

Em inglês, os termos são no-way audio e one-way audio. Áudio de um lado só indica que um dos sentidos encontrou o caminho e o outro não, o que aponta quase sempre para endereço, NAT ou firewall de um lado específico. Ligação muda costuma apontar para algo que afeta o fluxo inteiro: codec, criptografia, uma faixa de portas fechada nos dois sentidos ou uma mídia marcada como inativa.

Num 0800 ou numa URA, uma chamada que completa e fica em silêncio é pior que uma recusa: ela aparece como atendida e nenhum alarme de completamento dispara.

Por que a chamada completa e o áudio não passa?

A chamada completa e o áudio não passa porque a chamada VoIP usa dois caminhos separados. O SIP (RFC 3261) negocia a chamada; o áudio viaja em RTP (RFC 3550), em portas UDP escolhidas na hora. O 200 OK prova que o SIP passou, mas não prova que o RTP encontra o endereço e a porta anunciados.

O endereço do áudio vai dentro da própria mensagem SIP, no corpo SDP. Pelo modelo de oferta e resposta da RFC 3264, quem liga oferece um endereço, uma porta e uma lista de codecs; quem atende responde com os seus. Cada lado envia o áudio para o endereço que o outro anunciou. Um exemplo de oferta feita por um PABX atrás de NAT:

v=0
o=- 4021 4021 IN IP4 192.168.1.20
s=-
c=IN IP4 192.168.1.20
t=0 0
m=audio 14562 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=sendrecv

A linha c= diz para onde enviar o áudio, e a linha m= diz em que porta e com quais codecs. Nesse exemplo, o PABX anunciou 192.168.1.20, um endereço privado. A operadora, do lado de fora, envia o áudio para esse endereço, que não existe na internet, e o áudio some. O PABX, por sua vez, envia o seu áudio para o endereço público que a operadora anunciou, e esse sentido funciona. Resultado: a operadora ouve o ramal, e o ramal não ouve a operadora.

A linha a=sendrecv também conta. Os atributos sendonly, recvonly e inactive limitam o sentido do áudio de propósito, por exemplo numa chamada em espera. Um inactive que sobra de uma espera ou de uma transferência mal concluída pode deixar a chamada muda com a rede inteira funcionando.

Quais são as causas mais comuns de ligação muda e áudio unidirecional?

As causas mais comuns de ligação muda e áudio unidirecional no VoIP são oito: NAT sem tratamento, SIP ALG reescrevendo o SDP, faixa RTP bloqueada, IP externo errado no SDP, falta de RTP simétrico, codec incompatível, SRTP de um lado só e early media mal tratada. A tabela resume o sintoma de cada uma.

Causa	Sintoma típico	Onde conferir
NAT sem tratamento	Áudio de um lado só, quase sempre de fora para dentro	Endereço na linha c= do SDP enviado pelo PABX
SIP ALG no roteador ou firewall	Sintoma que muda de chamada para chamada, registro que cai, chamadas que caem perto de 32 s	Opções de SIP ou VoIP do roteador ou firewall
Faixa RTP bloqueada ou sem encaminhamento	Ligação muda ou de um lado só, só nas chamadas pelo tronco	Regras de entrada e encaminhamento de portas UDP
IP externo errado no SDP	Áudio de entrada some, às vezes só depois de uma troca de IP ou de link	external_media_address no PJSIP, externaddr no chan_sip
Falta de RTP simétrico	Áudio de um lado só com telefones remotos ou com a outra ponta atrás de NAT	rtp_symmetric e force_rport no endpoint
Codec incompatível	Recusa com SIP 488, ou chamada completa com silêncio ou ruído	Linhas m= e a=rtpmap da oferta e da resposta
SRTP de um lado só	Ligação muda nos dois sentidos, ou recusa com SIP 488	Perfil RTP/SAVP no SDP e criptografia de mídia no endpoint
Early media	Silêncio antes do atendimento: não se ouve o toque nem a mensagem da operadora	183 Session Progress com SDP

NAT sem tratamento

O NAT troca o endereço privado do PABX pelo endereço público do link nos cabeçalhos IP, mas não mexe no conteúdo da mensagem SIP. O SDP continua dizendo 192.168.1.20, e a outra ponta acredita nele. A RFC 4787 descreve como os NATs tratam UDP, com comportamentos de mapeamento diferentes conforme o destino, e a RFC 6314 reúne as práticas de travessia de NAT para SIP: anunciar o endereço público, responder para a porta de onde a mensagem veio, manter o mapeamento vivo com mensagens periódicas e usar RTP simétrico. Telefones e adaptadores atrás de NAT também podem descobrir o próprio endereço público com STUN (RFC 8489).

SIP ALG reescrevendo o SDP

O SIP ALG é uma função de muitos roteadores e firewalls que lê as mensagens SIP, troca os endereços privados por públicos dentro do SIP e do SDP e abre portas RTP sob demanda. Quando o PABX já anuncia o endereço externo, as duas correções se somam; quando o ALG reescreve só uma parte, por exemplo o cabeçalho Contact e não a linha c=, o resultado é um SDP incoerente. O ALG também não lê SIP sobre TLS, porque a mensagem vai criptografada. Por isso a recomendação usual é desligá-lo e tratar o NAT num lugar só.

Faixa de portas RTP bloqueada ou sem encaminhamento

Cada fluxo RTP usa uma porta UDP, e pela RFC 3550 o RTCP correspondente usa a porta seguinte. O PABX escolhe as portas dentro de uma faixa configurada, e o firewall precisa deixar essa faixa inteira chegar até ele. Um encaminhamento parcial produz um defeito intermitente: as chamadas que caem numa porta dentro da parte encaminhada funcionam, e as outras ficam mudas.

IP externo errado no SDP

Configurar o endereço externo resolve o NAT até o endereço mudar. Links com IP dinâmico, um segundo link que assume quando o principal cai, ou uma rota de saída por um link diferente do anunciado fazem o PABX anunciar um endereço que não é o de onde o tráfego sai. O mesmo vale para a lista de redes locais: o Asterisk só troca o endereço privado pelo público para destinos fora das redes listadas como locais. Uma rede interna que falta na lista, como a VPN de uma filial, recebe o IP público e passa a ter áudio de um lado só.

RTP simétrico

RTP simétrico quer dizer enviar e receber o áudio pela mesma porta e, do outro lado, devolver o áudio para o endereço e a porta de onde ele de fato chegou, ignorando o que o SDP disse. É a forma mais robusta de atravessar um NAT que não se conhece, e é uma das práticas da RFC 6314. Quando a outra ponta, um telefone remoto ou uma operadora atrás de NAT, anuncia um endereço que não funciona, só o RTP simétrico do seu lado faz o áudio chegar até ela.

Codec incompatível

Se a oferta e a resposta não têm nenhum codec de voz em comum, a chamada costuma ser recusada com SIP 488 Not Acceptable Here. O caso mais difícil é a chamada que completa: um lado aceita um codec que não sabe tratar, uma conversão de codec falha no PABX, ou a lista de codecs muda num reenvio do SDP. A chamada aparece atendida e fica muda ou com ruído.

SRTP de um lado só

Com SRTP, o áudio vai criptografado, e o SDP anuncia o perfil RTP/SAVP em vez de RTP/AVP. Se um lado exige criptografia e o outro envia áudio aberto, ou se as chaves não foram combinadas, os pacotes chegam e são descartados. A chamada fica muda nos dois sentidos com os contadores de pacotes normais. Pela RFC 3264, um fluxo de mídia recusado volta na resposta com a porta 0, e esse detalhe no SDP costuma ser a pista.

Early media

Early media é o áudio que chega antes do atendimento: o toque de chamada gerado pela rede ou a mensagem da operadora dizendo que o número não existe. Ele vem com um SIP 183 Session Progress que traz SDP, e a RFC 3960 descreve como esse áudio antecipado é tratado. Se o PABX, o firewall ou o telefone não deixam esse áudio passar, quem liga ouve silêncio até o atendimento, e uma chamada que falha com uma mensagem gravada parece muda. Um SDP no 183 diferente do SDP no 200 OK também pode deixar o áudio apontado para o lugar errado depois do atendimento.

Como o sintoma aponta para a causa?

O sintoma de uma ligação muda ou de um áudio unidirecional aponta para a causa quando se observa em que sentido o áudio falha, em que momento da chamada e em quais chamadas. Um defeito em toda chamada de entrada é diferente de um que aparece em uma de cada três.

Sintoma	Causa provável	Primeira verificação
O ramal não ouve quem está fora; quem está fora ouve o ramal	IP privado no SDP, SIP ALG, faixa RTP de entrada fechada	SDP enviado pelo PABX e encaminhamento de portas
Quem está fora não ouve o ramal	Saída UDP restrita, ou SDP da outra ponta com endereço inalcançável	Regras de saída do firewall e SDP recebido
Ninguém ouve ninguém	Codec, SRTP, mídia inactive ou recusada com porta 0	Oferta e resposta lado a lado
O áudio para depois de uma espera ou transferência	Novo SDP num reenvio de INVITE, mídia direta entre as pontas	direct_media e o SDP do reenvio
O áudio para depois de alguns minutos de silêncio	Tempo de sessão UDP curto no firewall	Tempos de sessão UDP e mensagens de manutenção
A chamada cai perto de 32 segundos	ACK perdido por Contact com endereço privado	Cabeçalho Contact do 200 OK
Falha em algumas chamadas e não em outras	Faixa RTP encaminhada pela metade, dois links de saída	Porta RTP das chamadas que falharam
Silêncio só antes do atendimento	Early media bloqueada	183 com SDP e o que o PABX faz com ele

Por que a chamada cai depois de 32 segundos?

Porque o ACK não chegou. Pela RFC 3261, quem atende uma chamada retransmite o 200 OK até receber o ACK. Se passar 64 × T1 sem ACK, a sessão deve ser encerrada. Com o T1 padrão de 500 ms, são 64 × 0,5 = 32 segundos. O ACK é enviado para o endereço do cabeçalho Contact do 200 OK; se o PABX atrás de NAT pôs ali o seu endereço privado, o ACK se perde, o PABX continua retransmitindo e derruba a chamada no fim da conta. Não é um problema de áudio, mas aparece junto com ele, porque nasce do mesmo NAT mal tratado.

Como corrigir a ligação muda no Asterisk, no Issabel e no FreePBX?

No Asterisk, no Issabel e no FreePBX, a correção da ligação muda passa por quatro ajustes: informar o endereço externo e as redes locais no transporte, desligar a mídia direta e ligar o RTP simétrico nos endpoints do tronco, alinhar a faixa RTP do rtp.conf com o firewall e conferir os codecs e a criptografia de mídia dos dois lados.

PJSIP: o transporte

No PJSIP, o endereço externo e as redes locais ficam no transporte. Com documentação de exemplo, 203.0.113.10 como IP público e duas redes internas:

[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0:5060
external_media_address=203.0.113.10
external_signaling_address=203.0.113.10
local_net=192.168.1.0/24
local_net=10.20.0.0/16

external_media_address é o endereço que vai na linha c= do SDP; external_signaling_address é o que vai nos cabeçalhos SIP, como Contact e Via. local_net lista as redes para as quais o Asterisk mantém o endereço privado. Liste todas as redes internas, inclusive as de VPN das filiais.

PJSIP: o endpoint do tronco

No endpoint do tronco e dos telefones remotos:

[tronco-operadora]
type=endpoint
transport=transport-udp-nat
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
disallow=all
allow=alaw,ulaw

Com direct_media=yes, o Asterisk tenta tirar a si mesmo do caminho do áudio depois do atendimento, com um novo INVITE para que as duas pontas troquem RTP direto. Atravessando NAT, isso costuma falhar e o áudio some logo depois do atendimento ou de uma transferência; direct_media=no mantém o áudio passando pelo Asterisk. rtp_symmetric=yes liga o RTP simétrico, force_rport=yes responde para a porta de onde a mensagem veio, e rewrite_contact=yes grava o endereço de onde o registro chegou, e não o que o aparelho disse. As linhas disallow e allow definem os codecs aceitos, na ordem de preferência; elas precisam ter interseção com o que a operadora aceita. O comando pjsip show endpoint tronco-operadora mostra os valores em vigor.

Se a operadora exige SRTP, a opção media_encryption do endpoint precisa combinar com ela. Se ela não usa, a opção precisa estar desligada.

chan_sip, em instalações antigas

No chan_sip, que as versões recentes do Asterisk já não trazem, os equivalentes ficam no sip.conf: externaddr (antes externip) para o endereço público, localnet para as redes locais, nat=force_rport,comedia para o RTP simétrico e directmedia=no para manter o áudio no Asterisk.

rtp.conf: a faixa de portas

A faixa de portas RTP do Asterisk fica no rtp.conf:

[general]
rtpstart=10000
rtpend=20000

Esses são os valores do arquivo de exemplo do Asterisk e o padrão do FreePBX. A faixa do firewall precisa ser exatamente a mesma, ou maior. Se for preciso estreitar a faixa, faça a conta: cada ponta de chamada que passa pelo Asterisk usa um par de portas (RTP e RTCP), e uma chamada entre um telefone e o tronco tem duas pontas, ou seja, quatro portas. Uma faixa de 10.000 portas comporta, em conta aproximada, 10.000 ÷ 4 = 2.500 chamadas simultâneas.

No mesmo arquivo, a opção strictrtp, ligada por padrão nas versões atuais, faz o Asterisk aceitar o RTP só da origem que ele aprendeu no início da chamada. Uma operadora que troca a origem do áudio no meio da chamada, por exemplo depois de uma mensagem gravada, pode ter o áudio descartado. Desligá-la é um teste de diagnóstico, não a correção definitiva.

FreePBX e Issabel

No FreePBX, os campos equivalentes ficam em Settings → Asterisk SIP Settings, na aba General SIP Settings: External Address, Local Networks e RTP Port Ranges. Prefira a interface aos arquivos: o FreePBX regrava os arquivos que gera ao aplicar a configuração, e os ajustes feitos à mão ficam nos arquivos terminados em _custom.conf. O Issabel traz o Asterisk com uma interface derivada do FreePBX, e os mesmos três itens, endereço externo, redes locais e faixa RTP, aparecem nas suas configurações SIP. Em centrais Issabel antigas com chan_sip, vale a seção anterior.

Para um primeiro teste interno, o FreePBX tem um teste de eco no código *43, e no Asterisk puro o aplicativo Echo() do plano de discagem faz o mesmo. Esse teste só prova o trecho entre o telefone e o PABX; o tronco, o NAT e o firewall ficam de fora.

Como ajustar o firewall e o roteador para o áudio VoIP?

Para o áudio VoIP atravessar o firewall e o roteador, três ajustes resolvem a maior parte dos casos: desligar o SIP ALG quando o PABX já trata o NAT, encaminhar para o PABX a mesma faixa UDP de RTP que ele usa e dar às sessões UDP um tempo de vida maior que o intervalo entre as mensagens.

Desligue o SIP ALG

O nome e o lugar mudam de fabricante para fabricante, e vale sempre conferir a documentação da versão instalada:

• FortiGate: o tratamento de SIP pode vir de um session helper de SIP ou da ALG de SIP aplicada pelo perfil de VoIP das políticas. Confira os dois antes de concluir que o SIP passa sem alteração.
• MikroTik: o helper fica em IP → Firewall → Service Ports, na entrada sip. Desabilite essa entrada.
• pfSense: o ponto mais citado para VoIP é o NAT de saída trocar a porta de origem das conexões. Uma regra de NAT de saída com porta estática para o endereço do PABX evita a troca.
• Roteadores de banda larga: muitos trazem a opção como “SIP ALG” ou “SIP Passthrough” nas configurações avançadas de NAT.

Depois de desligar, limpe as sessões ativas para que as entradas antigas saiam da tabela de conexões.

Abra e encaminhe a faixa RTP

Encaminhe a faixa UDP inteira, 10000 a 20000 no exemplo, para o endereço interno do PABX, e libere essa mesma faixa nas regras de entrada. Por segurança, limite a origem aos endereços da operadora sempre que ela informar quais são, e faça o mesmo com a porta SIP.

Ajuste os tempos de sessão UDP

O firewall esquece um mapeamento UDP que fica sem tráfego. A RFC 4787 pede que esse temporizador não expire em menos de 2 minutos e recomenda um padrão de 5 minutos ou mais. Equipamentos com tempos menores derrubam o mapeamento do registro SIP entre duas renovações, e o tronco passa a receber chamadas que não chegam ao PABX. Duas saídas: aumentar o tempo de sessão UDP no firewall para as portas de voz, ou fazer o PABX enviar mensagens com mais frequência, com uma renovação de registro mais curta e o qualify_frequency do AOR no PJSIP, que envia um OPTIONS periódico.

E se houver um SBC?

Um SBC na borda assume o NAT e ancora o áudio entre o PABX e a operadora; o PABX conversa só com ele, numa rede conhecida. O cuidado é não tratar o NAT duas vezes: SBC, ALG e PABX corrigindo o mesmo endereço geram um SDP incoerente.

Como saber se o 0800 ou o tronco SIP está com ligação muda?

A forma de saber se um 0800, uma URA ou um tronco SIP está com ligação muda é ligar de fora e verificar o áudio nos dois sentidos, numa chamada real, de forma repetida. Um painel de PABX não vê o problema: o tronco aparece registrado, a chamada é atendida, e só quem está na linha percebe o silêncio.

O teste que prova os dois sentidos é uma chamada para um serviço de eco ou de tons. O que a chamada envia precisa voltar: se o eco devolve o áudio, ele chegou até lá e voltou. Uma chamada interna, um teste de eco no próprio PABX ou o toque de chamada antes do atendimento não provam isso, porque deixam de fora o tronco, o NAT ou o próprio caminho do áudio depois do atendimento. Por causa dos defeitos intermitentes, como uma faixa RTP encaminhada pela metade, um teste isolado também não basta: o defeito pode aparecer só numa parte das chamadas.

É isso que o Monitor faz para cada circuito de voz, que é cada tronco SIP, 0800 ou número de atendimento monitorado. A 2N5 faz chamadas de teste reais da própria plataforma, no ritmo combinado, sem instalar nada no PABX e sem integração com ele. Quando o número é atendido por um tom de teste ou por um serviço de eco, a chamada passa quando é atendida e os tons enviados voltam. Áudio em um só sentido ou ausente conta como falha, mesmo com a chamada completa. Veja o que cada chamada verifica em monitoramento de troncos SIP.

Uma falha é repetida antes de qualquer alerta. No ritmo padrão, cada circuito recebe uma chamada a cada 15 minutos; depois de uma falha, a chamada é repetida três vezes, a cada 2 minutos, quatro falhas seguidas abrem um incidente e duas chamadas boas seguidas confirmam a volta. O incidente avisa a escada de escalonamento por e-mail e SMS, até alguém assumir; veja alertas e escalonamento. Se o problema estiver do lado da 2N5, o teste fica sem visibilidade e não conta contra o circuito.

Como os contadores de RTP mostram de que lado o áudio parou?

Os contadores de RTP enviados e recebidos mostram de que lado o áudio parou porque cada sentido tem o seu fluxo. Numa chamada normal, os dois contadores sobem juntos. Quando um deles fica parado em zero enquanto o outro sobe, o áudio unidirecional está provado, e o sentido parado indica em que trecho procurar.

A conta de referência é simples. Com áudio empacotado a cada 20 ms, cada sentido envia 1.000 ÷ 20 = 50 pacotes por segundo. Uma chamada de 60 segundos tem cerca de 3.000 pacotes em cada sentido. Um contador de recebidos em zero ao lado de 3.000 enviados não deixa dúvida.

No Asterisk, três comandos dão essa visão:

• pjsip show channelstats mostra, para cada canal ativo, os pacotes recebidos e transmitidos, a perda, o jitter e o tempo de ida e volta;
• rtp set debug on mostra cada pacote com o endereço de origem e de destino, e revela na hora um áudio sendo enviado para um endereço privado; rtp set debug ip filtra por endereço;
• no chan_sip, sip show channelstats faz o papel do primeiro.

Fora do Asterisk, uma captura de pacotes no PABX ou no firewall, aberta no Wireshark em Telephony → RTP → RTP Streams, lista cada fluxo com origem, destino e quantidade de pacotes. Capturar dos dois lados do firewall mostra se o pacote para na borda. O RTCP ajuda também: pela RFC 3550, o relatório de quem envia traz a contagem de pacotes e de bytes enviados, e o relatório de quem recebe traz a fração perdida, o total perdido e o jitter. Uma ponta que nunca recebe RTCP da outra tem o mesmo problema no caminho de volta.

Enviados pelo PABX	Recebidos pelo PABX	Leitura
Normais	Zero	O áudio de fora não chega: IP privado no SDP, SIP ALG ou faixa RTP de entrada fechada
Zero	Normais	O PABX não envia: mídia recvonly ou inactive, falha de conversão de codec, mídia direta
Normais	Normais, com silêncio mesmo assim	O áudio chega e não é usado: SRTP sem chave, codec errado, trecho entre PABX e telefone
Zero	Zero	Nenhum fluxo: mídia recusada com porta 0, inactive, canal sem ponte
Sobem e depois param	Sobem e depois param	Novo SDP num reenvio de INVITE, tempo de sessão UDP vencido, troca de origem com strictrtp

O que levar para a operadora?

Leve à operadora o horário de cada chamada que falhou, o número chamado, o Call-ID, a captura do SIP com o SDP da oferta e da resposta, e os contadores de RTP dos dois sentidos. Se o seu PABX envia áudio ao endereço anunciado e nada volta, o problema está do lado dela ou entre vocês.

Uma ligação muda não tem código de erro: a chamada completou com 200 OK. No Monitor, cada incidente traz o circuito, a operadora, o primeiro sintoma, o código SIP e a causa Q.850 de cada chamada, e a última chamada saudável, num bloco pronto para colar no chamado. A consulta de código SIP ajuda a ler os códigos das chamadas que foram recusadas no caminho.

Lista de verificação

1. Confirme o sentido que falha e em quais chamadas: todas, só as de entrada, só algumas.
2. Capture o SIP e leia o SDP: o endereço da linha c= é o público?
3. Desligue o SIP ALG do roteador ou firewall, e reinicie as sessões ativas.
4. Configure external_media_address, external_signaling_address e todas as redes em local_net.
5. Use direct_media=no, rtp_symmetric=yes, force_rport=yes e rewrite_contact=yes no tronco e nos telefones remotos.
6. Alinhe a faixa do rtp.conf com o encaminhamento UDP do firewall, inteira.
7. Ajuste os tempos de sessão UDP ou encurte a renovação do registro.
8. Compare codecs e criptografia da oferta e da resposta.
9. Confira o que acontece com o 183 e o early media.
10. Prove o resultado com chamadas reais de fora para um eco ou tom, de forma repetida, olhando os contadores de RTP dos dois sentidos.

Perguntas frequentes

Por que a ligação VoIP completa e fica muda?

Porque o SIP, que completa a chamada, e o RTP, que leva o áudio, seguem caminhos diferentes. O 200 OK prova que o SIP passou. O áudio depende do endereço e da porta anunciados no SDP; se esse endereço é privado, se a porta está fechada no firewall ou se os dois lados não combinam codec ou criptografia, a chamada fica muda.

O que é áudio unidirecional?

É a chamada em que um lado ouve e o outro não. O sentido que falha indica onde procurar: quando quem está dentro não ouve quem está fora, o áudio de entrada não chega, quase sempre por IP privado no SDP, SIP ALG ou faixa RTP sem encaminhamento. Quando é o contrário, olhe a saída do PABX e o SDP da outra ponta.

Desligar o SIP ALG resolve sempre?

Não sempre, mas é o primeiro passo recomendado quando o PABX já trata o NAT. O SIP ALG reescreve endereços dentro do SIP e do SDP, e a correção dupla gera endereços trocados. Depois de desligá-lo, o PABX precisa anunciar o endereço externo certo e a faixa RTP precisa estar encaminhada, senão o problema continua.

Por que a chamada cai depois de uns 30 segundos?

Quase sempre porque o ACK não chegou. Pela RFC 3261, quem atende retransmite o 200 OK até receber o ACK e, depois de 64 × T1, 32 segundos com T1 de 500 ms, encerra a sessão. O ACK vai para o endereço do cabeçalho Contact; se esse endereço é privado, ele se perde no NAT.

Como testar se o áudio passa nos dois sentidos?

Com uma chamada real, vinda de fora pelo tronco, para um serviço de eco ou de tons: o que sai precisa voltar. Uma chamada interna só prova o trecho entre telefone e PABX. Enquanto isso, os contadores de RTP do PABX mostram se os pacotes estão saindo e chegando nos dois sentidos.

Fontes

1. RFC 3261: SIP, incluindo a retransmissão do 200 OK até o ACK (64 × T1)
2. RFC 3264: modelo de oferta e resposta com SDP
3. RFC 3550: RTP e RTCP, contadores de pacotes e jitter
4. RFC 3960: early media e geração de toque de chamada no SIP
5. RFC 6314: práticas de travessia de NAT para aplicações SIP
6. RFC 4787: comportamento de NAT para UDP, incluindo tempos de mapeamento
7. RFC 8489: STUN

Continue lendo

• Monitoramento de circuitos de voz: o guia completo
• Monitoramento de troncos SIP
• Qualidade de voz: MOS, MOS-LQO e ViSQOL na prática
• Consulta de código SIP
• Alertas e escalonamento