Por qué una llamada SIP se registra por una VPN pero no envía audio

Un registro correcto no dice casi nada sobre el audio. Un softphone puede mantener un enlace válido con el PBX de la oficina durante horas y aun así entregar silencio. El túnel solo transporta los paquetes que alguien envía deliberadamente hacia él, y una llamada usa tres rutas separadas: el enlace, el establecimiento del diálogo y el flujo RTP. Cuando las separa, el fallo recae en una ruta y no en la palabra VPN.

Imagine un portátil en una Wi-Fi doméstica que marca una extensión de la oficina por un túnel aprobado. El PBX autentica al usuario, acepta el REGISTER y la extensión aparece disponible, pero la llamada se conecta con un silencio absoluto en una dirección.

El registro vincula un contacto, no una ruta de medios

Una solicitud REGISTER pide al registrador que almacene una correspondencia entre una dirección de registro y uno o más URI de contacto. Esa correspondencia responde a una pregunta estrecha sobre dónde debe enviarse ahora un diálogo nuevo. No dice nada sobre dónde pertenecen los medios, y un registro aceptado no demuestra que un INVITE posterior lleve una dirección de medios alcanzable. Los registros también caducan con un temporizador, así que un teléfono que deja de refrescar pierde llamadas entrantes mientras su túnel aún parece sano. Vigile la caducidad del contacto y no el estado del túnel.

Cuando el softphone está detrás del túnel, la cabecera de contacto puede llevar una dirección privada. Un PBX que la reenvía a otro extremo crea un diálogo dirigido a una red a la que el receptor no puede llegar. Establecer rewrite_contact=yes en el extremo PJSIP hace que el PBX sustituya la dirección de origen que observó, y eso suele ser la diferencia entre un timbre y un tiempo de espera agotado.

Qué ofrece el INVITE y quién puede usarlo

Un INVITE con un cuerpo SDP propone dónde quiere recibir medios quien llama: una dirección, un puerto y una lista de códecs. El receptor responde con su propia dirección y puerto, y luego cada lado envía RTP a lo que propuso el otro. Si quien llama propuso una dirección 192.168.x.x que solo existe dentro de su red doméstica, el receptor no tiene dónde enviar audio, por limpia que haya sido la señalización. El enmascaramiento reescribe las cabeceras IP cuando los paquetes salen de un enrutador, pero nunca reescribe el texto dentro de un cuerpo SDP.

Esa brecha explica la clásica llamada unidireccional: la señalización funciona porque ambos extremos llegan al PBX, y el audio falla porque a un extremo se le dijo que enviara a una dirección que solo existe detrás de otro NAT.

Quién transporta el audio es una decisión de configuración

La señalización y los medios son papeles separados. Un proxy puede permanecer en la ruta de señalización durante toda una llamada y no tocar nunca un solo paquete RTP. Que el PBX se convierta en repetidor de medios depende de la configuración, no de la presencia de un túnel.

Con medios directos, los extremos intercambian ellos mismos el RTP, lo que funciona bien en una LAN y mal cuando un lado está detrás de un rango de puertos estrecho.

Establecer direct_media=no fuerza al PBX a entrar en la ruta de medios para que ambas patas terminen en una dirección que él controla, cambiando ancho de banda y CPU por direccionamiento predecible. Cuando retransmite, el PBX sigue teniendo que anunciar una dirección alcanzable. En un host con varias interfaces, external_media_address y external_signaling_address en pjsip.conf deciden qué aparece en el SDP y en las cabeceras Via. Si los deja sin definir, el PBX puede ofrecer su dirección LAN a quien llama cuyo único camino es el lado lejano del túnel.

Siga cada dirección antes de tocar la configuración

Empiece por la tabla de sockets del PBX mientras una llamada está activa: ss -uanp | grep -E '5060|10000' muestra si los puertos RTP están vinculados y qué dirección local usan. Si no hay nada vinculado en el rango de medios, el repetidor no participa y los extremos hablan directamente. Luego capture en el lado del softphone con tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap. Los paquetes salientes sin paquetes entrantes estrechan el problema a la ruta de vuelta o a la dirección que se le dijo al otro extremo que usara, y una captura vacía significa que los medios nunca llegaron a la interfaz del túnel. Una captura de señalización con sngrep responde a la otra mitad mostrando la línea de conexión SDP tal como se envió.

Compare la dirección de esa línea de conexión con la dirección a la que el otro extremo puede enrutar realmente. Esa única comparación resuelve la mayoría de los informes de audio unidireccional más rápido que cualquier revisión de configuración.

El cifrado se detiene en el borde del túnel

SIP sobre TLS protege el salto de señalización para el que se configuró, SRTP protege los medios cuando ambos extremos lo negocian, y el túnel protege el tráfico entre sus propios extremos. Ninguno de ellos concede los demás. Una llamada cifrada dentro del túnel puede salir de la puerta de enlace en texto claro hacia el PBX, y eso es una decisión de diseño, no un defecto.

Antes de cerrar el ticket, confirme tres cosas en orden: el registro es reciente, el SDP lleva una dirección a la que el otro extremo puede llegar y los paquetes fluyen en ambos sentidos por los puertos de medios. Si alguna es falsa, el túnel no es donde vive el problema. Corrija la ruta que falló y luego repita la misma captura para confirmar el cambio. Conservar las capturas de antes y después convierte el siguiente informe unidireccional en una comprobación de cinco minutos en lugar de una tarde entera.