¿Qué es un SIP proxy? Arquitectura, B2BUA vs. proxy e interoperabilidad SIP empresarial

Tiene un PBX Cisco en el centro de datos, un centro de contacto Avaya en una subred separada y un proveedor de SIP trunk en la nube que habla un dialecto de SIP ligeramente diferente al de ambos sistemas. La búsqueda de un “SIP proxy” que haga que estos sistemas se comuniquen de manera confiable es el punto de partida de muchas implementaciones SIP, y a menudo es donde los ingenieros descubren que un SIP proxy ligero no es la herramienta adecuada para el trabajo.

Un SIP proxy, en el sentido estricto del RFC 3261, es un servidor que reenvía solicitudes SIP hacia su destino sin terminar completamente la sesión de llamada. Se ubica en la ruta de señalización, decide hacia dónde enrutar las solicitudes y las pasa; no renegocia cómo se establece la llamada, no reescribe encabezados para compatibilidad entre fabricantes ni controla la ruta de medios. En un entorno homogéneo de un solo fabricante, esa transparencia es exactamente lo que usted necesita. En los entornos multifabricante y multioperador que caracterizan la mayoría de las implementaciones empresariales y de proveedores de servicios, se necesita algo que pueda intervenir de forma activa.

Esta página cubre la arquitectura de los SIP proxy, las diferencias críticas entre un proxy y un agente de usuario back-to-back (B2BUA), dónde pertenece cada uno en una red real, y por qué la mayoría de las interconexiones de operadores y las implementaciones SIP empresariales necesitan las capacidades completas de un controlador de borde de sesión (SBC).

Cómo funciona un SIP proxy

Un SIP proxy es un intermediario de red que enruta mensajes de señalización SIP entre agentes de usuario (UA, incluyendo teléfonos, softclients, sistemas PBX y cualquier terminal que hable SIP). Su función principal es resolver un SIP URI a una dirección de red y reenviar la solicitud un salto más cerca del destino.

El proxy agrega un encabezado Via a cada solicitud SIP a medida que pasa, registrando su dirección en la ruta de señalización. Las respuestas del destinatario viajan de regreso a través de la misma cadena de encabezados Via, y cada proxy elimina su propia entrada a medida que la respuesta pasa. Esto crea una ruta de señalización rastreable y reversible sin requerir que el proxy mantenga estado alguno sobre la llamada en sí.

Proxy sin estado vs. proxy con estado

Un proxy sin estado procesa cada mensaje SIP de forma aislada. Lee el URI de solicitud, aplica la lógica de enrutamiento, reenvía el mensaje y lo olvida. No hay estado de transacción, ni registro de llamada, ni correlación entre una solicitud y su respuesta. Los proxy sin estado son rápidos y escalables horizontalmente, pero no tienen la capacidad de hacer nada que requiera conocimiento de la llamada como un todo: ni bifurcación, ni autenticación, ni enrutamiento de respaldo.

Un proxy con estado rastrea transacciones SIP (el intercambio completo de una solicitud y sus respuestas) y, opcionalmente, rastrea el diálogo (la llamada completa desde el INVITE hasta el BYE). Esto permite a los proxy con estado realizar funciones como bifurcación paralela (enviar un INVITE a múltiples destinos simultáneamente), reenrutamiento autenticado y distribución rudimentaria de carga. La mayoría de la infraestructura SIP en producción utiliza proxy con estado cuando se utilizan proxy.

Lo que ni los proxy sin estado ni los proxy con estado pueden hacer: modificar el cuerpo SDP para cambiar preferencias de códec, reescribir encabezados SIP para acomodar incompatibilidades entre fabricantes, terminar la ruta de medios para aplicar cifrado u ocultar la topología de red interna de partes externas.

El modelo de reenvío: Via, Route y Record-Route

Tres encabezados SIP definen cómo participan los proxy en una sesión:

Via es el mecanismo de rastreo. Cada proxy agrega su dirección (y un parámetro branch único) al encabezado Via en el camino de ida, y las respuestas eliminan las entradas Via en orden inverso. Así es como una respuesta sabe hacia dónde ir.

Route es una instrucción de enrutamiento precargada: una lista de direcciones de proxy por las que la solicitud debe pasar, consumida una por una.

Record-Route es cómo un proxy con estado se inserta en el diálogo en curso. Al agregarse al encabezado Record-Route, el proxy asegura que verá todas las solicitudes posteriores en el mismo diálogo, manteniéndose en la ruta de señalización durante toda la vida de la llamada. Un proxy que no agrega Record-Route solo verá el INVITE inicial, no los re-INVITE a mitad de llamada ni el BYE.

Ninguno de estos mecanismos le otorga al proxy la capacidad de cambiar lo que contiene la solicitud. Gobiernan el enrutamiento, no el contenido.

B2BUA vs. SIP proxy: diferencias arquitectónicas clave

Un agente de usuario back-to-back (B2BUA) adopta un enfoque fundamentalmente diferente. En lugar de reenviar solicitudes, un B2BUA termina el diálogo SIP del llamante, actuando como servidor de agente de usuario (UAS), y origina un diálogo SIP completamente nuevo hacia el destinatario, actuando como cliente de agente de usuario (UAC). Los dos tramos son completamente independientes. El B2BUA puede cambiar cualquier cosa: los encabezados SIP, la oferta SDP, la lista de códecs, el protocolo de transporte, la ruta de medios.

Esta diferencia arquitectónica tiene consecuencias de gran alcance para lo que el dispositivo puede y no puede hacer.

Lo que un B2BUA puede hacer y un proxy no

Dado que un B2BUA termina y re-origina, tiene visibilidad y control completos sobre ambos tramos de señalización. Esto permite:

Manipulación de encabezados SIP. Un B2BUA puede agregar, modificar o eliminar cualquier campo de encabezado SIP. En la práctica, esto significa normalizar implementaciones incompatibles entre fabricantes: convertir un formato de encabezado SIP con formato Cisco a uno que un sistema Avaya acepte, o eliminar encabezados propietarios que un SIP trunk de operador rechaza.

Ocultación de topología. En un SIP proxy, los encabezados SIP del llamante reflejan las direcciones reales de la red interna. Un B2BUA reemplaza todo el direccionamiento interno con su propia dirección externa, ocultando la topología interna por completo. Este es un requisito de seguridad para cualquier implementación orientada al operador o a internet.

Renegociación de códec. Cuando dos terminales ofrecen listas de códecs incompatibles en su SDP, un B2BUA puede modificar el intercambio de oferta/respuesta SDP para negociar un códec que ambos lados acepten, o invocar transcodificación si no existe un códec común.

Anclaje de medios. Un B2BUA puede ubicarse en la ruta de medios, aceptando y reenviando paquetes RTP, lo que permite cifrado/descifrado SRTP, conversión de RTP a SRTP, grabación de medios y puntuación de calidad MOS.

La compensación: complejidad vs. control

Un SIP proxy es más sencillo de implementar y agrega menor sobrecarga de procesamiento por llamada, lo cual es apropiado para enrutamiento interno de alto volumen en un entorno homogéneo. Un B2BUA agrega algo de sobrecarga de procesamiento por llamada, incrementa el estado y requiere más configuración. A cambio, proporciona la superficie de control necesaria para hacer funcionar redes SIP heterogéneas.

Para cualquier cosa orientada a internet o a un operador, el modelo B2BUA no es opcional. El modelo de proxy simplemente no puede satisfacer los requisitos de seguridad e interoperabilidad.

Normalización SIP: el problema que un proxy no puede resolver

El estándar SIP (RFC 3261 y sus documentos complementarios) define el protocolo. No exige que cada fabricante implemente cada función de la misma manera. En la práctica, dos sistemas que afirman cumplir con SIP frecuentemente discrepan en el formato de encabezados, el orden de códecs en el SDP, el método de señalización DTMF, el comportamiento de UPDATE vs. re-INVITE, el manejo de temporizadores de sesión y docenas de otros detalles.

Incompatibilidades SIP comunes en entornos multifabricante

Las siguientes son problemáticas de interoperabilidad reales encontradas en redes de voz en producción:

Señalización DTMF. Algunos terminales envían dígitos DTMF como audio dentro de banda (RFC 2833 / RFC 4733 en el flujo RTP). Otros usan mensajes SIP INFO. Otros más utilizan señalización fuera de banda mediante el formato telephone-event del SDP. Cuando dos sistemas usan métodos diferentes, los tonos DTMF se pierden por completo, un problema que destruye la funcionalidad de IVR, el acceso al buzón de voz y las conferencias.

Orden de códecs. Una oferta SDP lista los códecs en orden de prioridad. Algunos fabricantes requieren que el primer códec de la lista sea el que prefieren; otros eligen el códec de mayor calidad en común independientemente de la posición. Cuando una discrepancia en el orden de códecs resulta en la selección de un códec subóptimo, la calidad de la llamada se degrada de maneras difíciles de diagnosticar.

Formato de encabezados Via y Contact. Ciertos fabricantes de PBX colocan parámetros adicionales en los encabezados Via o Contact que los SIP trunk descendentes rechazan como malformados. Otros fabricantes eliminan parámetros que son obligatorios. En cualquier caso, las llamadas fallan, o fallan de forma intermitente, dependiendo de la ruta de la llamada.

Temporizadores de sesión. El RFC 4028 define temporizadores de sesión para detectar llamadas colgadas. No todos los terminales los admiten, y diferentes implementaciones de valores Session-Expires entran en conflicto. Un B2BUA puede normalizar el comportamiento de los temporizadores en ambos tramos.

Encabezados P-Asserted-Identity y PAI. Los encabezados de identidad del llamante varían significativamente entre fabricantes y operadores. Un B2BUA puede normalizarlos para compatibilidad con STIR/SHAKEN, asegurando que la información de identidad correcta se presente en la capa de atestación.

Motor de manipulación de encabezados SIP

La solución a lo anterior es un motor de manipulación de encabezados SIP: un sistema basado en reglas que define, para cada tramo de llamada o grupo de trunks, exactamente qué encabezados se agregan, modifican o eliminan a medida que las llamadas pasan. Las reglas de manipulación operan sobre mensajes SIP entrantes y salientes de forma independiente, lo que permite tratamientos específicos por fabricante en cada lado del B2BUA.

Esta es la función central de normalización que hace del SBC B2BUA el dispositivo adecuado para entornos multifabricante. Sin ella, cada incompatibilidad entre fabricantes requiere una solución alternativa con reglas de firewall, un cambio de configuración en el terminal del fabricante, o una llamada que simplemente no funciona.

SIP proxy en arquitecturas de operadores y empresas

En la práctica, los SIP proxy aparecen en redes de producción, pero en roles específicos donde sus limitaciones son aceptables.

Dónde se utilizan los SIP proxy:

• Como front-ends de registro SIP, distribuyendo solicitudes REGISTER a un grupo de servidores de registro
• Como balanceadores de carga internos entre un clúster de servidores de aplicaciones idénticos en una plataforma homogénea (todos ejecutando el mismo software, mismo fabricante, mismo perfil de códec)
• Como capas de resolución DNS basadas en SIP en plataformas de operadores a gran escala, donde la decisión de enrutamiento es traducción de direcciones pura sin necesidad de modificación de contenido

Dónde los SIP proxy se quedan cortos:

• Cualquier interconexión operador-empresa, donde el SIP trunk del operador habla un dialecto de SIP y el PBX empresarial habla otro
• Cualquier implementación que requiera TLS para señalización SIP, lo cual exige terminar la sesión TLS y re-originarla, exactamente lo que un proxy no hace
• Cualquier implementación que requiera cifrado de medios con SRTP, lo cual requiere anclaje de medios
• Cualquier implementación expuesta a DoS/DDoS: un proxy sin estado no ofrece protección; reenviará el tráfico de inundación con la misma facilidad que el tráfico legítimo

El controlador de borde de sesión (SBC) es la clase de dispositivo definida específicamente para abordar estos requisitos en los bordes de red. Un SBC utiliza la arquitectura B2BUA internamente y superpone seguridad, control de acceso, gestión de topología y normalización.

Para un desglose detallado de cómo los SBC se conectan a trunks de operadores, consulte la guía SBC SIP Trunk. Para profundizar en las capacidades de seguridad en la capa SIP, puede dirigirse al pilar de seguridad VoIP.

Registro y autenticación SIP

Los SIP proxy y los SBC manejan el registro SIP de manera diferente, y la diferencia importa tanto para la seguridad como para las operaciones.

Un registrador SIP es la entidad que acepta solicitudes REGISTER y asocia un AOR SIP (Address of Record, un SIP URI como [email protected]) con una dirección de contacto (la dirección IP actual del terminal). En implementaciones clásicas, el registrador es una función de servidor independiente, a menudo co-ubicada con un proxy.

Un SBC con arquitectura B2BUA puede realizar reenvío de registro SIP: acepta solicitudes REGISTER de los terminales, las reenvía como proxy al registrador del operador y mantiene el mapeo de registro localmente. Esto le otorga al SBC visibilidad completa del estado de registro de cada terminal detrás de él sin requerir cambios en el registrador ascendente.

Más importante aún, un SBC puede realizar protección contra escaneo de registros SIP: detectar ataques de inundación de registros (intentos automatizados de fuerza bruta contra credenciales mediante el envío de grandes volúmenes de solicitudes REGISTER) y bloquearlos en el borde antes de que lleguen al registrador o al PBX. Un SIP proxy ligero no tiene mecanismo para distinguir una inundación de registros del tráfico legítimo; reenvía ambos por igual.

Estos no son requisitos marginales. El escaneo de registros SIP es uno de los vectores de ataque más comunes contra infraestructura SIP expuesta a internet. Cualquier dispositivo ubicado en el borde de una red necesita protección activa contra este tipo de ataques.

SIP proxy en el contexto de Microsoft Teams Direct Routing

Microsoft Teams Direct Routing es el mecanismo que conecta a los usuarios de Teams Phone con la red telefónica pública conmutada (PSTN) a través de un SIP trunk gestionado por el cliente. Microsoft exige que el dispositivo que conecta Teams al SIP trunk sea un controlador de borde de sesión certificado (no un SIP proxy).

Las razones son directas. Teams requiere:

• TLS para señalización SIP en ambos tramos, el que mira hacia Teams y el que mira hacia el operador. Terminar una sesión TLS requiere que el dispositivo actúe como terminal TLS, algo que un proxy transparente no puede hacer. Un SBC B2BUA termina TLS en ambos tramos de forma independiente.
• SRTP para cifrado de medios en el tramo que mira hacia Teams. Esto requiere anclaje de medios, solo posible con un B2BUA.
• Normalización SIP entre el dialecto SIP de Teams y el dialecto del SIP trunk del operador. La implementación SIP de Microsoft Teams tiene requisitos de encabezados específicos que la mayoría de los SIP trunk de operadores no satisfacen de forma nativa.
• Traversal de NAT y ocultación de topología, asegurando que las direcciones de la red interna no se filtren en la ruta de señalización de Teams.

Un SIP proxy no satisface ninguno de estos requisitos. Microsoft prueba los SBC contra el conjunto completo de requisitos SIP de Teams: manejo de encabezados, compatibilidad con códecs, DTMF, comportamiento de registro y cumplimiento de TLS/SRTP. Para más información sobre cómo ProSBC se conecta a Microsoft Teams Direct Routing, consulte nuestra página de producto.

Preguntas frecuentes

¿Cuál es la diferencia entre un SIP proxy y un controlador de borde de sesión?

Un SIP proxy reenvía solicitudes SIP sin terminar la sesión de llamada. No puede modificar encabezados SIP para normalización entre fabricantes, aplicar cifrado de medios ni ocultar la topología de red interna. Un controlador de borde de sesión (SBC) utiliza una arquitectura B2BUA para terminar y re-originar completamente tanto los tramos de señalización como los de medios. Esto le otorga control total sobre manipulación de encabezados, negociación de códecs, cifrado de medios (SRTP), ocultación de topología, protección DoS/DDoS y control de acceso, todo lo cual es necesario en cualquier interfaz de operador o borde de red multifabricante.

¿Puede un SIP proxy manejar la interoperabilidad SIP multifabricante?

Los SIP proxy ligeros son más adecuados para entornos homogéneos de un solo fabricante. La interoperabilidad multifabricante (donde un PBX Cisco, un sistema Avaya y un SIP trunk de operador implementan encabezados SIP, DTMF y negociación de códecs de manera diferente) requiere un SBC B2BUA con un motor de manipulación de encabezados SIP que pueda normalizar el tráfico de cada fabricante de forma independiente.

¿Microsoft Teams Direct Routing requiere un SBC o un SIP proxy?

Microsoft Teams Direct Routing requiere un controlador de borde de sesión certificado. Un SIP proxy no puede terminar sesiones TLS, anclar medios SRTP ni realizar la normalización SIP entre Teams y los SIP trunk de operadores que el programa de certificación de Microsoft valida. Microsoft mantiene una lista de proveedores de SBC certificados para Teams Direct Routing.

¿Qué es un B2BUA?

Un agente de usuario back-to-back (B2BUA) es una entidad SIP que actúa como servidor de agente de usuario (UAS) en el tramo entrante y como cliente de agente de usuario (UAC) en el tramo saliente. Termina el diálogo SIP del llamante y origina un nuevo diálogo hacia el destinatario. A diferencia de un SIP proxy, el B2BUA tiene control total sobre ambos tramos, lo que le permite reescribir encabezados SIP, renegociar códecs, anclar medios y aplicar cifrado de forma independiente en cada lado.

¿Cuándo conviene usar un SIP proxy en lugar de un SBC?

Un SIP proxy es apropiado para enrutamiento interno en un entorno de un solo fabricante donde todos los terminales hablan el mismo dialecto SIP y donde no se requieren límites de seguridad, normalización de encabezados, control de medios ni protección DoS. Cualquier implementación orientada a internet, a un SIP trunk de operador o a un entorno multifabricante necesita las capacidades B2BUA completas de un SBC.

¿Para qué se utiliza un servidor SIP proxy en redes empresariales?

En redes empresariales, un servidor SIP proxy maneja el enrutamiento interno de llamadas entre terminales que comparten la misma implementación SIP. Resuelve SIP URI a direcciones de red, distribuye registros y puede realizar balanceo de carga básico a través de un clúster de servidores idénticos. No proporciona la normalización de encabezados, el cifrado de medios ni la aplicación de seguridad necesarios en los límites de red. Para tráfico entre fabricantes o hacia operadores, un SBC reemplaza o complementa al proxy.

¿Es un SIP proxy lo mismo que un gateway SIP?

No. Un SIP proxy enruta señalización SIP entre terminales SIP sin conversión de protocolo. Un gateway SIP convierte entre SIP y un protocolo o tipo de red diferente, como PSTN/TDM, H.323 o WebRTC. Un SBC combina enrutamiento tipo proxy con traducción de protocolo tipo gateway y agrega seguridad a nivel de sesión, convirtiéndolo en el dispositivo estándar en los límites de red donde se necesitan tanto enrutamiento como conversión.

¿Puede un SIP proxy realizar balanceo de carga?

Un SIP proxy con estado puede distribuir solicitudes INVITE entre múltiples destinos usando round-robin, distribución ponderada o selección basada en prioridad. Sin embargo, no puede realizar balanceo de carga con reconocimiento de sesión (enrutamiento basado en conteos de llamadas actuales, métricas de calidad o estado de los terminales) porque no mantiene estado de sesión más allá del nivel de transacción. Para distribución con reconocimiento de sesión, el motor de enrutamiento de un SBC ofrece mayor control.

Conclusión

Los SIP proxy son un componente fundamental de la arquitectura SIP, pero su rol está definido con precisión. Enrutan solicitudes. No terminan sesiones, no modifican contenido, no protegen redes ni normalizan implementaciones incompatibles. En los entornos donde esas limitaciones no importan (redes internas homogéneas, plataformas de un solo fabricante, niveles de enrutamiento puro), funcionan bien. En los entornos que constituyen la mayoría de las implementaciones reales de redes de voz, no.

Las interconexiones de operadores, Microsoft Teams Direct Routing, la voz empresarial multifabricante, la integración de plataformas CPaaS y cualquier implementación expuesta a tráfico de internet requieren la superficie de control completa de un controlador de borde de sesión (SBC) B2BUA: manipulación de encabezados SIP, ocultación de topología, anclaje de medios y cifrado, protección DoS/DDoS y el control de acceso para aplicar todo lo anterior.

Más allá del rol de reenvío del SIP proxy, el SBC se extiende a un territorio que el modelo de proxy no puede alcanzar: los bordes de red complejos, multifabricante y orientados al operador donde la normalización, la seguridad y el control total de sesión son obligatorios.