Las infraestructuras SIP modernas dependen cada vez más de balanceadores de carga, proxies inversos y servicios de borde en la nube para ofrecer escalabilidad, seguridad y distribución geográfica. El problema clásico de esta arquitectura es que estos componentes intermedios ocultan la dirección IP real del cliente al servidor SIP de backend: lo que llega a OpenSIPS es la IP del balanceador, no la del teléfono o softphone original. OpenSIPS 4.0 resuelve este problema con la introducción del soporte nativo del Protocolo Proxy.

El Protocolo Proxy fue desarrollado originalmente por HAProxy Technologies como un mecanismo ligero para que proxies y balanceadores transmitan la IP y el puerto originales del cliente al servidor de destino. En lugar de depender de cabeceras a nivel de aplicación — que pueden no existir o no ser confiables — el Protocolo Proxy antepone una pequeña cabecera a la conexión de transporte con los metadatos de la conexión original: IP y puerto del cliente, IP y puerto de destino, y familia de transporte. Hoy es compatible con plataformas como Cloudflare, AWS, Google Cloud, Azure, HAProxy, NGINX y Envoy, entre otros.

La implementación inicial en OpenSIPS 4.0 soporta el Protocolo Proxy v1, tanto en conexiones entrantes como salientes, sobre UDP, TCP, TLS, WebSocket (WS) y WebSocket seguro (WSS).

En el escenario de conexiones entrantes, el caso típico es OpenSIPS detrás de un servicio de borde como Cloudflare que reenvía conexiones TCP o TLS. Sin Protocolo Proxy, OpenSIPS sólo ve la IP de Cloudflare como origen, lo que impide hacer autenticación correcta, aplicar políticas de ruteo basadas en IP real o detectar clientes abusivos. Con el protocolo habilitado, Cloudflare antepone una cabecera del tipo PROXY TCP4 203.0.113.10 198.51.100.5 50612 5061 antes del mensaje SIP. OpenSIPS parsea esa cabecera y expone la información al script de ruteo mediante la nueva variable $proxy_protocol, que contiene los datos reales del cliente. Desde ese momento, todos los módulos y la lógica de ruteo pueden tomar decisiones basadas en el endpoint real, aunque la conexión provenga de Cloudflare.

En el escenario de conexiones salientes, el caso de uso es OpenSIPS operando como proxy o SBC y reenviando tráfico hacia otra plataforma SIP upstream. Al insertar la cabecera del Proxy Protocol en las conexiones salientes, el sistema de destino mantiene visibilidad completa del endpoint original del cliente, aunque la conexión provenga ahora de OpenSIPS. Este patrón es especialmente común cuando OpenSIPS actúa como SBC realizando NAT traversal, terminación TLS, topology hiding o filtrado de seguridad, pero se quiere que los sistemas upstream sigan tomando decisiones con base en la IP real del cliente.

El soporte del Protocolo Proxy en OpenSIPS 4.0 es una incorporación que responde a una necesidad real de las infraestructuras VoIP actuales: integrar servidores SIP con la capa de red moderna — balanceadores, CDN, plataformas cloud — sin perder trazabilidad del cliente original. La solución es elegante porque el problema se resuelve a nivel de transporte, antes incluso de que OpenSIPS procese el primer byte SIP, lo que la hace transparente para el resto de la lógica de la plataforma.