Los teléfonos IP se utilizan ampliamente en la comunicación empresarial, sistemas de despacho, centros de llamadas, campus, sitios industriales, hoteles y redes de servicio público. La mayoría de los teléfonos IP modernos utilizan el protocolo SIP, lo que facilita su registro en servidores SIP, plataformas IP PBX, sistemas softswitch y plataformas de comunicación unificada. Sin embargo, durante la implementación, puede aparecer un problema común: el audio unidireccional.

El audio unidireccional significa que una llamada está conectada, pero solo una de las partes puede escuchar a la otra. La señalización SIP puede parecer normal, el teléfono puede sonar y la llamada puede ser contestada con éxito, pero el flujo de voz no viaja correctamente en ambas direcciones. Este problema suele estar relacionado con NAT, la transmisión RTP, las políticas de firewall, SIP ALG, la negociación de códecs, la configuración del endpoint o los ajustes de medios del servidor.

Comience por la diferencia entre señalización y medios

Una llamada telefónica SIP contiene dos partes importantes: señalización y medios. La señalización SIP se utiliza para el registro, marcación, timbre, establecimiento de llamada y finalización de llamada. RTP se utiliza para transmitir el flujo de voz real después de que se establece la llamada. Esta diferencia es la clave para entender por qué puede ocurrir el audio unidireccional.

En muchos casos, la parte SIP tiene éxito porque la red permite el puerto SIP predeterminado, a menudo UDP o TCP 5060. El teléfono puede registrarse, marcar y contestar llamadas normalmente. Pero los puertos RTP utilizados para la voz son diferentes del puerto de señalización SIP. Si la ruta RTP está bloqueada, mal enrutada, traducida incorrectamente o enviada a la dirección IP incorrecta, la llamada puede conectarse sin una voz bidireccional normal.

Por lo tanto, la solución de problemas no debe detenerse en el estado de registro SIP. Un teléfono registrado con éxito puede seguir teniendo problemas de medios. Los ingenieros deben verificar si ambas partes pueden enviar y recibir paquetes RTP durante la llamada.

NAT es una fuente común de problemas de dirección de audio

NAT permite que los dispositivos dentro de una red de área local accedan a redes externas a través de una dirección IP pública. Esto es común en oficinas empresariales, sucursales, hoteles, fábricas y ubicaciones remotas. Cuando un teléfono IP o un servidor SIP está detrás de NAT, el dispositivo puede anunciar una dirección IP privada en la información SIP o SDP. La parte remota puede entonces intentar enviar paquetes RTP a una dirección privada inalcanzable.

Esta es una de las causas más comunes del audio unidireccional, especialmente cuando el servidor SIP está implementado en la red pública y los teléfonos IP se encuentran en diferentes entornos LAN. La llamada puede establecerse, pero el flujo de medios no puede regresar al dispositivo interno correcto.

Para solucionar esto, la implementación debe utilizar un diseño adecuado de recorrido NAT. Los métodos comunes incluyen STUN, TURN, RTP simétrico, mapeo de direcciones públicas, reenvío de puertos, implementación de SBC o retransmisión de medios a través del servidor SIP. La mejor opción depende de la topología de red y de si el sistema está implementado dentro de una red privada, a través de redes públicas o entre múltiples sitios sucursales.

Las reglas de firewall deben incluir el tráfico RTP

La política de firewall es otra razón frecuente para el audio unidireccional. Muchos administradores solo abren el puerto de señalización SIP y olvidan el rango de puertos RTP. Como resultado, los teléfonos pueden registrarse y se pueden crear llamadas, pero los paquetes de voz no pueden atravesar el firewall.

RTP suele utilizar puertos UDP. El rango de puertos depende de la configuración del teléfono, la PBX, el servidor SIP, el SBC o la plataforma de medios. En muchos entornos SIP, RTP puede usar rangos como UDP 16384-32768 u otro rango personalizado definido por el administrador del sistema. El rango exacto debe verificarse tanto en la configuración del teléfono como en la del servidor.

Para un audio bidireccional confiable, las reglas de firewall deben permitir los puertos UDP de medios requeridos en ambas direcciones. Si la implementación involucra múltiples VLAN, túneles VPN, enrutadores de sucursales, servidores en la nube o mapeo de IP públicas, se debe verificar cada segmento de red. Un solo segmento bloqueado puede crear síntomas de audio unidireccional o sin audio.

El enrutamiento RTP necesita una ruta de medios clara

La voz del teléfono IP se transporta mediante flujos RTP. Si la dirección de destino RTP, la dirección de origen, el puerto o la ruta de enrutamiento son incorrectos, el audio puede funcionar solo en una dirección. Esto puede ocurrir no solo en escenarios de red pública sino también dentro de una LAN privada.

Por ejemplo, el teléfono y el servidor pueden usar diferentes rangos de puertos RTP, o el servidor puede esperar que los medios pasen a través de un proxy de medios mientras el endpoint intenta enviar medios directamente a otro teléfono. Algunos sistemas admiten medios directos entre endpoints, mientras que otros requieren que todo el tráfico RTP pase a través del servidor o SBC. Si este modo se configura incorrectamente, puede aparecer audio unidireccional.

Durante la implementación, el equipo del proyecto debe confirmar si la ruta de voz es de endpoint a endpoint, de endpoint a servidor o de endpoint a SBC. Todos los dispositivos en el flujo de llamada deben usar direcciones IP alcanzables y configuraciones de puerto RTP compatibles.

SIP ALG puede ayudar o romper la llamada

Muchos enrutadores y firewalls incluyen una función SIP ALG. Está diseñada para inspeccionar y modificar paquetes SIP para que el tráfico SIP pueda pasar NAT más fácilmente. En teoría, esto suena útil. En la práctica, SIP ALG a veces puede modificar incorrectamente la información SIP o SDP y causar audio unidireccional, llamadas fallidas o registro inestable.

Si una red ya utiliza un SBC adecuado, mapeo de direcciones públicas, STUN o un mecanismo de retransmisión de medios, SIP ALG puede volverse innecesario o incluso dañino. En muchos casos de solución de problemas, deshabilitar SIP ALG en enrutadores o firewalls puede resolver los problemas de audio unidireccional.

La elección correcta depende del diseño de la red. Si se utiliza SIP ALG, debe probarse cuidadosamente. Si el sistema ya tiene un método controlado de recorrido NAT, deshabilitar SIP ALG suele ser una mejor opción.

La negociación de códecs debe ser consistente

Los teléfonos IP suelen admitir múltiples códecs de voz, como G.711, G.729, G.722 y otros formatos de audio. Estos códecs se seleccionan durante la negociación SIP. Si las dos partes no comparten un códec compatible, la llamada puede no tener audio, tener audio distorsionado o un comportamiento de medios inestable.

La falta de coincidencia de códecs no siempre es la primera causa del audio unidireccional, pero aún así debe verificarse. Esto es especialmente importante cuando se utilizan juntos teléfonos de diferentes proveedores, softphones, pasarelas, plataformas PBX y sistemas de grabación.

Una solución práctica es priorizar los códecs comunes en todos los dispositivos. Por ejemplo, G.711 se usa a menudo en entornos LAN debido a su simplicidad y calidad de voz, mientras que los códecs comprimidos pueden usarse cuando el ancho de banda es limitado. La estrategia de códecs debe coincidir con la condición real de la red.

La configuración del lado del teléfono no debe ignorarse

Algunos problemas de audio unidireccional son causados por la configuración del endpoint. El teléfono IP puede tener una configuración incorrecta del puerto RTP, modo NAT, ajustes de cuenta SIP, opciones de retransmisión de medios, configuración de la interfaz de red local o prioridad de códec. En algunos casos, el teléfono también puede estar silenciado, el cable del auricular puede estar flojo o la configuración del altavoz y el micrófono puede ser incorrecta.

Cuando solo uno o varios teléfonos tienen el problema, la comparación de endpoints es útil. Los ingenieros pueden comparar un teléfono que funciona con un teléfono problemático y verificar la configuración de la cuenta SIP, la dirección de red, el rango de puertos RTP, la lista de códecs, el modo de recorrido NAT, la versión del firmware y el estado del dispositivo de audio.

Este método suele ser más rápido que cambiar inmediatamente la configuración global del servidor. Si el problema se limita a un endpoint, la causa raíz suele estar más cerca de ese endpoint o de su red local.

La configuración del servidor y del proxy de medios afecta a todas las llamadas

La configuración del servidor SIP también puede causar audio unidireccional. La dirección del servidor de medios, el modo de proxy RTP, la dirección IP externa, la dirección IP interna, el rango de puertos, la política de medios directos, el manejo de NAT y la configuración de retransmisión pueden afectar la ruta RTP.

Estos ajustes deben modificarse con cuidado porque los cambios globales en el servidor pueden afectar a muchos usuarios al mismo tiempo. Si solo algunos teléfonos tienen audio unidireccional, es mejor analizar la topología de red y la configuración del endpoint antes de cambiar los parámetros centrales del servidor.

Cuando el problema es complejo, la captura de paquetes y los registros del servidor son útiles. Al verificar la información SIP/SDP y el flujo de paquetes RTP, los ingenieros pueden ver qué dirección IP y puerto se están anunciando, a dónde se envía el flujo RTP y si la otra parte lo recibe.

Las interfaces de red múltiples pueden enviar los medios por el camino equivocado

Algunos teléfonos IP, servidores SIP, pasarelas o plataformas de comunicación tienen múltiples interfaces de red. Por ejemplo, un servidor puede tener una interfaz para la LAN, otra para una red pública y otra para una red de gestión. Si el servicio de medios selecciona la interfaz incorrecta, los paquetes RTP pueden enviarse por la ruta equivocada.

Esto puede crear una situación en la que la señalización parece normal pero el audio no puede regresar correctamente. El dispositivo puede anunciar la dirección IP incorrecta en SDP, o puede enviar paquetes RTP desde una interfaz de red inesperada.

Para evitar esto, el equipo del proyecto debe confirmar la dirección de enlace correcta, la tabla de enrutamiento, la puerta de enlace predeterminada, la interfaz de medios y el mapeo NAT. Los entornos con múltiples NIC deben documentarse claramente durante la implementación.

Un flujo de trabajo práctico para la solución de problemas

Un proceso estructurado de solución de problemas es mejor que los cambios aleatorios de parámetros. Primero, confirme si el problema ocurre en todas las llamadas o solo en ciertos teléfonos. Segundo, verifique si las llamadas afectadas son internas, externas, entre sitios, basadas en VPN o de red pública. Tercero, verifique si el registro SIP y el establecimiento de llamadas son normales.

Después de eso, concéntrese en RTP. Verifique las políticas de firewall, los rangos de puertos RTP, la configuración de recorrido NAT, el estado de SIP ALG, la negociación de códecs, el modo de retransmisión de medios y la configuración de IP externa del servidor. Si el problema sigue sin estar claro, use la captura de paquetes para confirmar si los paquetes RTP se envían y reciben en ambas direcciones.

Una buena solución de problemas se basa en la ruta de la llamada. Una vez que la ruta completa esté clara, el problema del audio unidireccional será mucho más fácil de localizar.

Planificación para un audio bidireccional estable

La mejor solución es reducir la posibilidad de audio unidireccional durante la etapa de diseño. Para implementaciones LAN pequeñas, mantenga la red simple y asegúrese de que los teléfonos, la PBX y las pasarelas utilicen configuraciones RTP consistentes. Para implementaciones de múltiples sitios, planifique el recorrido NAT, las reglas de firewall, el enrutamiento VPN y la ubicación del SBC antes de instalar los teléfonos.

Para implementaciones de red pública o PBX en la nube, suele ser mejor utilizar un retransmisor de medios o SBC para controlar la ruta RTP. Esto evita muchos problemas relacionados con NAT y mejora la compatibilidad entre diferentes entornos de red.

La documentación también es importante. El puerto SIP, el rango de puertos RTP, la política de códecs, el método NAT, la dirección IP del servidor, la configuración del proxy de medios y las reglas de firewall deben registrarse para el mantenimiento futuro.

Conclusión

El audio unidireccional en los sistemas de telefonía IP generalmente no es causado por un solo problema fijo. Puede deberse a la traducción NAT, puertos RTP bloqueados, políticas de firewall incorrectas, interferencia de SIP ALG, falta de coincidencia de códecs, configuración del endpoint, configuración de medios del servidor o enrutamiento de múltiples interfaces de red.

Una buena solución comienza con la comprensión de la diferencia entre la señalización SIP y los medios RTP. El registro y la marcación pueden funcionar normalmente mientras la transmisión de voz falla. Al verificar la ruta de medios paso a paso, los equipos del proyecto pueden localizar el problema más rápidamente y construir un sistema de comunicación de voz IP más estable.