Qué es SIP ALG y por qué debería desactivarlo

Usted configura un nuevo teléfono VoIP, se registra correctamente y la primera llamada de prueba conecta. Luego el audio es unidireccional, o la llamada se cae exactamente a los treinta segundos, o el teléfono muestra “Sin servicio” una hora después sin razón aparente. Verifica el proveedor SIP, las credenciales, los codecs, las reglas del firewall, y todo parece correcto. La falla casi nunca está en ninguno de esos lugares. Se trata de una única configuración en el router frente al teléfono, habilitada por defecto, llamada SIP ALG.

SIP ALG (Application Layer Gateway) es una función integrada en la mayoría de los routers de consumo y pequeñas empresas que inspecciona el tráfico SIP a medida que lo atraviesa y reescribe partes de él. La intención es ayudar a que VoIP funcione a través de Network Address Translation. En la práctica, es la causa más común de fallas VoIP inexplicables en redes empresariales, y la recomendación estándar en toda la industria es desactivarlo. En las secciones siguientes, explicaremos qué intenta hacer SIP ALG, por qué corrompe SIP en lugar de ayudar, cómo reconocer y confirmar los síntomas, cómo desactivarlo en routers comunes y qué resuelve correctamente el problema subyacente una vez eliminado.

Qué hace realmente SIP ALG

Para entender por qué SIP ALG causa problemas, comience con el problema que fue diseñado para resolver. SIP transporta direcciones IP y puertos dentro del cuerpo del mensaje, no solo en los encabezados del paquete, lo cual se deriva de cómo el estándar SIP (RFC 3261) y el payload SDP describen una sesión. Un teléfono en una red privada (por ejemplo 192.168.1.50) escribe esa dirección privada en su señalización SIP y en el SDP que describe dónde quiere recibir audio. Cuando el router realiza NAT y envía el paquete a la internet pública, reescribe el encabezado IP para que el origen aparezca como la dirección pública del router. La dirección privada oculta dentro del mensaje SIP queda intacta, porque NAT ordinario solo edita los encabezados de los paquetes, no los payloads.

El resultado es un mensaje SIP que le indica al otro lado que envíe la señalización y el audio a 192.168.1.50, una dirección que no significa nada en la internet pública. Las respuestas y el audio no llegan a ninguna parte. SIP ALG fue creado para parchar esta brecha. Lee dentro del mensaje SIP mientras pasa por el router, encuentra las direcciones privadas en los encabezados y el SDP, y las reescribe con la dirección pública del router para que el otro lado tenga un destino alcanzable al cual responder. En teoría es una idea razonable, y es la razón por la que los fabricantes de routers lo envían habilitado por defecto: permite que un único teléfono VoIP detrás de un router básico funcione sin ninguna configuración adicional.

El problema es que hacer esto correctamente requiere analizar SIP de forma completa y consistente, un protocolo con muchos tipos de mensajes, encabezados opcionales, plegado de líneas, formas compactas de encabezados y variaciones de fabricantes. El firmware de los routers de consumo realiza una versión rápida y superficial de ese análisis, y ahí es donde falla.

Por qué SIP ALG rompe SIP

SIP ALG falla no porque reescribir direcciones sea una mala idea, sino porque las implementaciones lo hacen de forma incompleta e inconsistente. Varios modos de falla distintos aparecen una y otra vez.

Reescrituras de direcciones incompletas e inconsistentes

Un ALG que reescribe la dirección en un encabezado pero la omite en otro deja el diálogo SIP describiendo dos rutas de retorno diferentes. El Via header puede ser corregido mientras el Contact header no lo es, o la dirección de señalización se corrige mientras la dirección de medios en el SDP se omite. Los dos lados de la llamada entonces discrepan sobre dónde deben ir los paquetes, y los síntomas dependen de qué encabezado fue alterado.

SDP alterado y audio unidireccional o sin audio

El SDP transporta la dirección y el puerto donde cada lado espera recibir audio RTP. Cuando un ALG reescribe la dirección SDP incorrectamente, o reescribe la señalización pero no el SDP, la llamada conecta y los teléfonos suenan, pero el audio no tiene un destino válido. Esto produce la clásica falla de audio unidireccional, donde una parte puede escuchar y la otra no, o llamadas que conectan en completo silencio. La misma familia de síntomas se cubre desde la perspectiva del operador en la guía de resolución de problemas VoIP.

Registro fallido y reescritura del Contact

Cuando un teléfono se registra, el Contact header indica al proveedor dónde enviar las llamadas entrantes. Un ALG que reescribe la dirección del Contact de forma inconsistente, o que pierde el seguimiento del registro al reescribir el manejo de expiración, causa que los registros fallen o caduquen silenciosamente. El teléfono muestra “Sin servicio”, las llamadas entrantes nunca suenan porque el proveedor las envía a una dirección que ya no funciona, y los registros se recuperan y fallan en un ciclo que parece aleatorio desde afuera.

Llamadas que se cortan después de aproximadamente treinta segundos

Una llamada que se establece correctamente y luego se corta en un intervalo consistente, frecuentemente alrededor de treinta segundos, es una señal característica de señalización intra-diálogo alterada. La actualización de sesión o el acuse de recibo que debería mantener la llamada activa se envía a una dirección que el ALG reescribió incorrectamente, por lo que nunca llega y uno de los lados finaliza la llamada.

SIP cifrado lo hace inútil y dañino

Cuando la señalización SIP está protegida con TLS, el router no puede leer el cuerpo del mensaje en absoluto, por lo que el ALG no tiene nada que inspeccionar o reescribir. En el mejor de los casos no proporciona asistencia útil de señalización; en el peor, interfiere con el manejo de NAT o el estado de sesión de formas que interrumpen la llamada. Cualquier despliegue que utilice TLS y SRTP, lo que incluye Microsoft Teams Direct Routing y la mayoría de las interconexiones modernas de operadores, no obtiene ningún beneficio de SIP ALG y solo hereda sus efectos secundarios.

Síntomas que apuntan a SIP ALG

SIP ALG rara vez se anuncia. Se presenta como un conjunto de fallas intermitentes y difíciles de reproducir que sobreviven a cada cambio que usted hace en el teléfono, el proveedor y las credenciales. Los siguientes síntomas, especialmente en combinación, apuntan fuertemente a un ALG en la ruta:

• Audio unidireccional donde una parte puede escuchar a la otra pero no al revés, o llamadas que conectan en silencio.
• Llamadas que se cortan en un intervalo consistente, frecuentemente alrededor de treinta segundos, después de un establecimiento limpio.
• Fallas de registro donde los teléfonos muestran “Sin servicio” o alternan entre registrado y fuera de línea sin patrón alguno.
• Llamadas entrantes que no suenan mientras las salientes funcionan, porque el proveedor no puede alcanzar la dirección que el ALG anunció.
• Transferencia, espera o DTMF fallidos, donde la señalización a mitad de llamada que modifica la sesión es la parte que se corrompe.
• Fallas que se mueven con el router, donde los mismos teléfonos y proveedor funcionan perfectamente en una red diferente.

Cómo confirmar que SIP ALG es el culpable

Debido a que los síntomas se superponen con fallas ordinarias de NAT y firewall, vale la pena confirmar SIP ALG específicamente en lugar de desactivar configuraciones al azar. El método confiable es comparar los mensajes SIP en cada lado del router. Capture el tráfico SIP tal como el teléfono lo envía en el lado privado, luego capture los mismos mensajes al salir del router en el lado público, y compare las direcciones del Contact, Via y SDP.

Si las direcciones dentro del mensaje han cambiado entre las dos capturas, y cambiado de una forma inconsistente o que apunta a una dirección inalcanzable, un ALG está reescribiendo el tráfico. Un dispositivo NAT limpio deja el payload SIP intacto y solo reescribe los encabezados de los paquetes. Leer estas capturas es una habilidad en sí misma, y la misma técnica localiza la mayoría de las fallas de señalización, no solo el comportamiento del ALG. Para el conjunto de herramientas de diagnóstico del operador que cubre trazas de llamadas y captura de paquetes, la guía de resolución de problemas VoIP detalla el proceso diagnóstico.

Cómo desactivar SIP ALG

SIP ALG se oculta bajo diferentes nombres en diferentes equipos, lo cual es parte de la razón por la que tan frecuentemente pasa desapercibido. Dependiendo del fabricante aparece como SIP ALG, SIP Transformations, SIP Helper, SIP Inspection, VoIP passthrough, o una entrada SIP en una página de configuración de NAT o capa de aplicación. En gateways basados en Linux es el helper de seguimiento de conexiones nf_conntrack_sip. La tabla a continuación indica dónde encontrarlo en las plataformas comunes.

Después de desactivar SIP ALG, reinicie el router si el cambio no surte efecto de inmediato, vuelva a registrar los teléfonos y realice llamadas de prueba en ambas direcciones para confirmar audio bidireccional y que la llamada se mantenga más allá del intervalo donde solía cortarse. Si los síntomas persisten, la causa es un problema separado de NAT o firewall y no el ALG.

Cuando desactivar SIP ALG no es suficiente

Desactivar SIP ALG elimina lo que corrompe su señalización, pero no hace desaparecer el problema original de NAT. Las direcciones privadas dentro de los mensajes SIP todavía necesitan ser conciliadas con las direcciones públicas que el otro lado realmente ve. Para un único teléfono detrás de un router básico, el keep-alive de NAT del propio teléfono y la detección de far-end NAT del proveedor generalmente cubren esa brecha una vez que el ALG está fuera del camino. A la escala de un operador, un MSP o cualquier proveedor que termina troncales SIP desde muchas redes que no controla, el problema de NAT debe resolverse deliberadamente en el borde de la red en lugar de dejarlo a la mejor estimación de un router.

Este es el rol que desempeña un Session Border Controller (SBC). Un SBC se sitúa en la frontera entre redes y maneja la señalización y los medios en cada lado como una función diseñada. Debido a que opera como un back-to-back user agent, termina el diálogo de señalización entrante y origina uno nuevo hacia el otro lado, de modo que controla cada dirección en cada encabezado en ambos tramos de forma determinística en lugar de editar un paquete en tránsito. Realiza detección de far-end NAT sobre las direcciones desde las que realmente llega el tráfico, ancla los medios para que el audio fluya hacia su propia dirección pública alcanzable, y aplica manipulación de encabezados SIP como reglas configuradas en lugar de una suposición fija. Esa es la diferencia entre un ALG de router y un SBC: la misma categoría de trabajo, realizada como control deliberado de señalización en lugar de una reescritura opaca. Para ver cómo esto encaja en el panorama más amplio de por qué un ALG de firewall no es un sustituto de un SBC, consulte la comparación detallada en la guía de seguridad SBC.

Preguntas frecuentes

Conclusión

SIP ALG es una función bien intencionada que intenta resolver un problema real, que SIP transporta direcciones privadas que NAT no reescribe, y lo resuelve mal al editar señalización en vivo basado en un análisis superficial del protocolo. El resultado es audio unidireccional, llamadas que se cortan con un temporizador, registros que caducan y llamadas entrantes que nunca suenan, todo lo cual sobrevive a cualquier otro paso de resolución de problemas que usted tome. En prácticamente cualquier red empresarial, la acción correcta es encontrar la configuración, bajo cualquier nombre que el fabricante le haya dado, y desactivarla.

Desactivarla elimina la corrupción pero deja el problema de NAT subyacente. Para un único teléfono la red generalmente se las arregla; a escala de proveedor el trabajo corresponde a un Session Border Controller que maneja el cruce de NAT, los medios y el direccionamiento SIP como funciones deliberadas y configuradas en lugar de una suposición transparente. Conocer la diferencia es lo que convierte una tarde persiguiendo un fantasma en una solución de cinco minutos.