Por que uma chamada SIP se registra por uma VPN mas não envia áudio
Registro e áudio seguem caminhos diferentes. Acompanhe uma chamada pelo túnel para ver quais endereços o PBX pode usar e onde o RTP realmente para.
Um registro bem-sucedido não diz quase nada sobre o áudio. Um softphone pode manter um vínculo válido com o PBX do escritório por horas e ainda assim entregar silêncio. O túnel transporta apenas os pacotes que alguém envia deliberadamente para dentro dele, e uma chamada usa três caminhos separados: o vínculo, a configuração do diálogo e o fluxo RTP. Quando você os separa, a falha recai em um caminho em vez da palavra VPN.
Imagine um notebook no Wi-Fi de casa discando um ramal do escritório por um túnel aprovado. O PBX autentica o usuário, aceita o REGISTER e o ramal aparece como disponível, mas a chamada se conecta com silêncio total em uma direção.
O registro vincula um contato, não um caminho de mídia
Uma solicitação REGISTER pede ao registrador que armazene um mapeamento entre um endereço de registro e um ou mais URIs de contato. Esse mapeamento responde a uma pergunta estreita sobre onde um novo diálogo deve ser enviado agora. Não diz nada sobre onde as mídias pertencem, e um registro aceito não prova que um INVITE posterior carregue um endereço de mídia alcançável. Os registros também expiram por temporizador, então um telefone que para de renovar perde chamadas recebidas enquanto seu túnel ainda parece saudável. Observe a expiração do contato em vez do estado do túnel.
Quando o softphone fica atrás do túnel, o cabeçalho de contato pode carregar um endereço privado. Um PBX que o encaminha para outro endpoint cria um diálogo voltado para uma rede que o destinatário não consegue alcançar. Definir rewrite_contact=yes no endpoint PJSIP faz o PBX substituir o endereço de origem que observou, e isso costuma ser a diferença entre um toque e um tempo esgotado.
O que o INVITE oferece e quem pode usá-lo
Um INVITE com corpo SDP propõe onde o chamador quer receber mídia: um endereço, uma porta e uma lista de codecs. O destinatário responde com seu próprio endereço e porta, e então cada lado envia RTP para o que o outro propôs. Se o chamador propôs um endereço 192.168.x.x que só existe dentro da rede dele, o destinatário não tem onde enviar áudio, por mais limpa que tenha sido a sinalização. O mascaramento reescreve os cabeçalhos IP quando os pacotes saem de um roteador, mas nunca reescreve o texto dentro de um corpo SDP.
Essa lacuna explica a clássica chamada unidirecional: a sinalização funciona porque ambos os endpoints alcançam o PBX, e o áudio falha porque um endpoint foi instruído a enviar para um endereço que só existe atrás de outro NAT.
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
Quem carrega o áudio é uma escolha de configuração
Sinalização e mídia são papéis separados. Um proxy pode permanecer no caminho de sinalização durante toda a chamada e nunca tocar um único pacote RTP. Se o PBX se torna um repetidor de mídia depende da configuração, não da presença de um túnel.
Com mídia direta, os endpoints trocam o RTP entre si, o que funciona bem em uma LAN e mal quando um lado está atrás de uma faixa de portas estreita.
Definir direct_media=no força o PBX para o caminho de mídia para que ambas as pernas terminem em um endereço que ele controla, trocando banda e CPU por endereçamento previsível. Ao retransmitir, o PBX ainda precisa anunciar um endereço alcançável. Em um host multi-rede, external_media_address e external_signaling_address em pjsip.conf decidem o que aparece no SDP e nos cabeçalhos Via. Se você os deixar sem definir, o PBX pode oferecer seu endereço LAN a um chamador cujo único caminho é o lado distante do túnel.
Rastreie cada direção antes de tocar nas configurações
Comece pela tabela de sockets no PBX enquanto uma chamada está ativa: ss -uanp | grep -E '5060|10000' mostra se as portas RTP estão vinculadas e qual endereço local usam. Se nada estiver vinculado na faixa de mídia, o repetidor não está ativo e os endpoints falam diretamente. Em seguida, capture no lado do softphone com tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Pacotes de saída sem pacotes de entrada estreitam o problema para o caminho de volta ou para o endereço que o outro lado foi instruído a usar, e uma captura vazia significa que a mídia nunca chegou à interface do túnel. Uma captura de sinalização com sngrep responde à outra metade mostrando a linha de conexão SDP como foi enviada.
Compare o endereço nessa linha de conexão com o endereço para o qual o outro lado realmente consegue rotear. Essa única comparação resolve a maioria dos relatos de áudio unidirecional mais rápido do que qualquer revisão de configuração.
A criptografia para na borda do túnel
SIP sobre TLS protege o salto de sinalização para o qual foi configurado, SRTP protege a mídia quando ambos os lados negociam, e o túnel protege o tráfego entre seus próprios endpoints. Nenhum deles concede os demais. Uma chamada criptografada dentro do túnel pode sair do gateway em texto claro na direção do PBX, e isso é uma decisão de projeto, não um defeito.
Antes de fechar o ticket, confirme três coisas em ordem: o registro está recente, o SDP carrega um endereço que o outro lado consegue alcançar e os pacotes fluem nos dois sentidos nas portas de mídia. Se alguma delas for falsa, o túnel não é onde o problema mora. Corrija o caminho que falhou e depois repita a mesma captura para confirmar a mudança. Manter as capturas de antes e depois transforma o próximo relato unidirecional em uma verificação de cinco minutos em vez de uma tarde inteira.