Por que unha chamada SIP se rexistra por unha VPN pero non envía audio
O rexistro e o audio seguen camiños distintos. Segue unha chamada polo túnel para ver que enderezos pode usar o PBX e onde se detén realmente o RTP.
Un rexistro correcto non di case nada sobre o audio. Un softphone pode manter unha vinculación válida co PBX da oficina durante horas e aínda así entregar silencio. O túnel só transporta os paquetes que alguén envía deliberadamente cara a el, e unha chamada usa tres camiños separados: a vinculación, o establecemento do diálogo e o fluxo RTP. Cando os separas, o fallo recae nun camiño e non na palabra VPN.
Imaxina un portátil nun Wi-Fi doméstico que marca unha extensión da oficina por un túnel aprobado. O PBX autentica o usuario, acepta o REGISTER e a extensión aparece dispoñible, pero a chamada conéctase cun silencio absoluto nunha dirección.
O rexistro vincula un contacto, non un camiño de medios
Unha solicitude REGISTER pide ao rexistrador que almacene unha correspondencia entre un enderezo de rexistro e un ou máis URI de contacto. Esa correspondencia responde a unha pregunta estreita sobre onde se debe enviar agora un diálogo novo. Non di nada sobre onde pertencen os medios, e un rexistro aceptado non demostra que un INVITE posterior leve un enderezo de medios alcanzable. Os rexistros tamén caducan cun temporizador, así que un teléfono que deixa de refrescar perde chamadas entrantes mentres o seu túnel aínda parece san. Vixía a caducidade do contacto e non o estado do túnel.
Cando o softphone está detrás do túnel, a cabeceira de contacto pode levar un enderezo privado. Un PBX que a reenvía a outro extremo crea un diálogo dirixido a unha rede á que o receptor non pode chegar. Establecer rewrite_contact=yes no extremo PJSIP fai que o PBX substitúa o enderezo de orixe que observou, e iso adoita ser a diferenza entre un timbre e un tempo de espera esgotado.
Que ofrece o INVITE e quen pode usalo
Un INVITE cun corpo SDP propón onde quere recibir medios quen chama: un enderezo, un porto e unha lista de códecs. O receptor responde co seu propio enderezo e porto, e logo cada lado envía RTP ao que propuxo o outro. Se quen chama propuxo un enderezo 192.168.x.x que só existe dentro da súa rede doméstica, o receptor non ten onde enviar audio, por limpa que fose a sinalización. A ocultación reescribe as cabeceiras IP cando os paquetes saen dun enrutador, pero nunca reescribe o texto dentro dun corpo SDP.
Esa fenda explica a clásica chamada unidireccional: a sinalización funciona porque ambos extremos chegan ao PBX, e o audio falla porque a un extremo se lle dixo que enviase a un enderezo que só existe detrás doutro 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 |
Quen transporta o audio é unha decisión de configuración
A sinalización e os medios son papeis separados. Un proxy pode permanecer no camiño de sinalización durante toda unha chamada e non tocar nunca un só paquete RTP. Que o PBX se converta en repetidor de medios depende da configuración, non da presenza dun túnel.
Con medios directos, os extremos intercambian eles mesmos o RTP, o que funciona ben nunha LAN e mal cando un lado está detrás dun rango de portos estreito.
Establecer direct_media=no forza o PBX a entrar no camiño de medios para que ambas as patas terminen nun enderezo que el controla, cambiando ancho de banda e CPU por direccionamento previsible. Cando retransmite, o PBX aínda ten que anunciar un enderezo alcanzable. Nun host con varias interfaces, external_media_address e external_signaling_address en pjsip.conf deciden que aparece no SDP e nas cabeceiras Via. Se os deixas sen definir, o PBX pode ofrecer o seu enderezo LAN a quen chama cuxo único camiño é o lado afastado do túnel.
Segue cada dirección antes de tocar a configuración
Comeza pola táboa de sockets do PBX mentres unha chamada está activa: ss -uanp | grep -E '5060|10000' mostra se os portos RTP están vinculados e que enderezo local usan. Se non hai nada vinculado no rango de medios, o repetidor non participa e os extremos falan directamente. Logo captura no lado do softphone con tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Os paquetes saíntes sen paquetes entrantes estreitan o problema á ruta de volta ou ao enderezo que se lle dixo ao outro extremo que usase, e unha captura baleira significa que os medios nunca chegaron á interface do túnel. Unha captura de sinalización con sngrep responde á outra metade mostrando a liña de conexión SDP tal como se enviou.
Compara o enderezo desa liña de conexión co enderezo ao que o outro extremo pode encamiñar realmente. Esa única comparación resolve a maioría dos informes de audio unidireccional máis rápido que calquera revisión de configuración.
O cifrado detense no bordo do túnel
SIP sobre TLS protexe o salto de sinalización para o que se configurou, SRTP protexe os medios cando ambos os extremos o negocian, e o túnel protexe o tráfico entre os seus propios extremos. Ningún deles concede os demais. Unha chamada cifrada dentro do túnel pode saír da pasarela en texto claro cara ao PBX, e iso é unha decisión de deseño, non un defecto.
Antes de pechar o ticket, confirma tres cousas por orde: o rexistro é recente, o SDP leva un enderezo ao que o outro extremo pode chegar e os paquetes flúen en ambos os sentidos polos portos de medios. Se algunha é falsa, o túnel non é onde vive o problema. Corrixe o camiño que fallou e logo repite a mesma captura para confirmar o cambio. Conservar as capturas de antes e despois fai que o seguinte informe unidireccional sexa unha comprobación de cinco minutos en lugar dunha tarde enteira.