Troncales SIP: arquitectura, seguridad y guía de SBC para proveedores de servicios

Las troncales SIP han reemplazado a los PRI como el método estándar para conectar la infraestructura de voz a la red telefónica pública conmutada (PSTN). Para los proveedores de servicios (proveedores de servicios de Internet (ISP) que construyen plataformás de troncales SIP, proveedores de servicios gestiónados (MSP) que revenden servicios de voz, proveedores de UCaaS que integran telefonia en sus plataformas), las decisiones tecnológicas van mucho más allá de elegir un proveedor de troncales. La arquitectura, la interoperabilidad entre implementaciónes de operadores, la seguridad en el borde de la red y la integración con plataformás de colaboración como Microsoft Teams y Zoom Phone determinan si una implementación de troncales SIP escala de manera confiable o se convierte en una carga operativa.

Esta guía esta escrita para los equipos que construyen y operan infraestructura de troncales SIP, no para empresas que buscan un proveedor de troncales SIP. Cubre la arquitectura de una implementación de troncales SIP en producción, el rol de un controlador de borde de sesión (SBC) en cada etapa de la ruta de la llamada, las consideraciones de seguridad que surgen al exponer SIP a la internet pública, y los desafios de interoperabilidad que aparecen cuando multiples proveedores, codecs y certificaciónes de plataforma convergen en una sola red.

¿Qué son las troncales SIP?

Las troncales SIP utilizan el protocolo de inicio de sesión para entregar llamadas de voz sobre una red IP en lugar de circuitos TDM dedicados. Una troncal SIP es una conexión lógica entre dos terminales SIP, generalmente entre el SBC de un proveedor de servicios y el SBC de un operador, o entre un SBC y un IP-PBX, que transporta tanto la señalización (establecimiento de llamada, finalizacion, eventos durante la llamada) como los medios (el audio de voz real) sobre el mismo transporte IP.

Para los proveedores de servicios, las troncales SIP no son un producto que se compra, sino la infraestructura que se construye. Un ISP que entrega servicios de voz a clientes empresariales aprovisiona y gestióna troncales SIP entre su propia red y los operadores ascendentes, entre su SBC y los sistemás PBX en las instalaciones de los clientes, y cada vez más entre su infraestructura y las plataformás de colaboración en la nube que requieren interconexión certificada con SBC.

El modelo económico es fundamentalmente diferente al del PRI. Las troncales SIP no estan vinculadas a circuitos físicos: la capacidad escala agregando sesiónes a un SBC basado en software en lugar de ordenar nuevas instalaciones de hardware. Las decisiones de enrutamiento se toman en software, la conmutación por error (failover) entre operadores es automática, y la misma infraestructura de SBC puede servir troncales SIP, Enrutamiento directo de Microsoft Teams, Zoom Phone BYOC e interconexiónes con PBX heredados simultáneamente.

Arquitectura de troncales SIP: cómo funcióna

Una implementación de troncales SIP en producción tiene cuatro componentes principales: el SBC en el borde de la red, una o más conexiónes con operadores ascendentes, la infraestructura de voz orientada al cliente (sistemás PBX, plataformás UCaaS o softphones) y el motor de enrutamiento y politicas que gobierna como fluyen las llamadas entre ellos.

El SBC como punto de control central

El controlador de borde de sesión es el ancla arquitectónica de toda implementación de troncales SIP. Se ubica en el límite entre la red de confianza del proveedor de servicios y el lado no confiable orientado al operador o a internet, gestiónando de forma independiente la señalización y los medios en cada tramo de una llamada.

En una arquitectura B2BUA, el SBC termina completamente la sesión SIP entrante del operador y genera una nueva sesión independiente hacia el PBX o la plataforma del cliente. Esta terminación y regeneración completa le otorga al SBC autoridad total sobre cada encabezado SIP en ambos tramos, lo que permite la manipulación de encabezados SIP, la ocultación de topologia, la negociación de cifrado independiente y la renegociación de codecs, funciones que un proxy SIP simple no puede realizar.

Interconexión con operadores

Un proveedor de servicios típico se conecta a multiples operadores ascendentes para lograr redundancia, optimizacion de costos y cobertura geografica. Cada troncal de operador termina en un grupo de troncales dedicado (NAP) en el SBC, con su propia configuración de transporte SIP, preferencias de codec y reglas de manipulación de encabezados. El motor de enrutamiento del SBC seleccióna el operador apropiado según el número marcado, la hora del dia, el costo o decisiones de enrutamiento externas provenientes de una API.

Troncales orientadas al cliente

En el lado del cliente, el SBC termina troncales hacia sistemás IP-PBX (FreePBX, 3CX, Asterisk, Broadsoft), plataformás UCaaS hospedadas o infraestructura de centros de contacto. Cada grupo de troncales del cliente tiene su propia configuración: diferentes codecs, diferentes requisitos de encabezados SIP, diferentes perfiles de seguridad. El SBC normaliza entre el dialecto SIP del cliente y el del operador, de modo que ninguno de los dos lados necesite adaptarse al otro.

Enrutamiento y politicas

El motor de enrutamiento es donde la implementación de troncales SIP de un proveedor de servicios se vuelve inteligente. El enrutamiento basado en reglas dirige las llamadas entre operadores utilizando enrutamiento de menor costo (LCR), conmutación por error basada en prioridades o motores de decision externos consultados via API. El control de admision de llamadas previene la sobresuscripción de troncales. La aplicación de politicas aplica limites de velocidad, listas de bloqueados y reglas de detección de fraude antes de que una llamada llegue al operador.

Troncales SIP vs. PRI: comparacion para proveedores de servicios

La transición de PRI a troncales SIP no es opcional para la mayoria de los proveedores de servicios. Los plazos de desmantelamiento de la PSTN se estan acelerando a nivel mundial, y la economía de mantener infraestructura TDM junto con redes IP ya no tiene sentido. Pero vale la pena comprender la comparacion en detalle, porque la ruta de migración y las diferencias operativas afectan cómo se disena la plataforma de troncales SIP.

	Troncales SIP	PRI
Escalamiento de capacidad	Agregue sesiónes en software; sin ordenes de circuitos	23/30 canales fijos por circuito físico
Redundancia multioperador	Conmutación por error definida por software entre operadores	Requiere circuitos físicos duplicados
Flexibilidad geografica	El SBC se puede implementar en cualquier lugar (nube, local, hibrido)	Vinculado al punto de terminación del circuito físico
Integración con plataformás	Teams Direct Routing, Zoom BYOC, Webex Calling	Requiere pasarela de medios para la conversión a IP
Modelo de costos	Suscripción por sesión (OPEX)	Recurrente por circuito + CAPEX de hardware
Cifrado	TLS/SRTP compatible de forma nativa	Sin cifrado nativo
Compatibilidad con STIR/SHAKEN	Encabezados de identidad en la señalización SIP	Requiere implementación fuera de banda

Migración de PRI a SIP para proveedores de servicios

Para los ISP e ILEC que aun operan infraestructura TDM, la ruta de migración típicamente implica implementar una pasarela de medios junto con un SBC. La pasarela de medios convierte la señalización y los medios TDM a SIP, mientras que el SBC se encarga del enrutamiento, la seguridad y la interconexión con operadores en el lado IP. Esto permite una migración por fases, convirtiendo circuitos un grupo de troncales a la vez, sin interrumpir el servicio existente.

Las pasarelas Tmedía y ProSBC de TelcoBridges se implementan juntos en exactamente esta configuración a traves de redes de operadores en todo el mundo, manejando la conversión de TDM a SIP mientras el SBC gestióna el enrutamiento, el cifrado y la interoperabilidad del lado IP.

El rol del controlador de borde de sesión en las troncales SIP

Toda implementación de troncales SIP en producción requiere un SBC. Esto no es una recomendacion, es un requisito arquitectónico. El SBC es el punto de aplicación de seguridad, interoperabilidad, cumplimiento regulatorio y politicas de enrutamiento. Sin el, cada terminal SIP en la red debe manejar individualmente la negociación de cifrado, la normalización de encabezados, la detección de fraude y la lógica de conmutación por error, una configuración que no escala y que no se puede gestiónar de forma centralizada.

Aplicación de seguridad en el borde de la red

Un SBC expuesto a la internet pública es la primera línea de defensa contra ataques basados en SIP. La mitigacion integrada de denegación de servicio (DoS) y DDoS bloquea los ataques de inundación SIP antes de que lleguen al nucleo de telefonia. La protección contra escaneo de registros SIP detecta y detiene los ataques de enumeración de registros. Las listas de bloqueados dinámicas y el control de acceso a llamadas permiten una respuesta en tiempo real a eventos de fraude sin necesidad de desconectar el SBC. Estas no son funciones opcionales; son requisitos operativos para cualquier implementación SIP expuesta a internet.

Normalización SIP e interoperabilidad

Ninguna implementación de SIP es identica a otra. El operador A envia encabezados P-Asserted-Identity en un formato que el operador B rechaza. Un fabricante de PBX incluye encabezados X- propietarios que una plataforma UCaaS elimina silenciosamente, causando que las funciones dejen de operar. El manejo de temporizadores de sesión (RFC 4028) difiere entre terminales, lo que provoca que las llamadas se desconecten despues de un intervalo fijo.

El motor de manipulación de encabezados SIP del SBC resuelve estas incompatibilidades aplicando tratamientos basados en reglas por grupo de troncales. Cada operador, PBX o plataforma obtiene su propio perfil de normalización, y el SBC traduce entre ellos para que la llamada funcióne independientemente de como cada proveedor haya decidido interpretar los RFC de SIP.

Terminación y traduccion de cifrado

Las troncales SIP requieren cada vez más cifrado, pero los requisitos difieren según el tramo. Microsoft Teams exige TLS para la señalización y SRTP para los medios. Una troncal de operador puede entregar RTP sin cifrar sobre UDP. El SBC termina el cifrado en cada tramo de forma independiente: TLS/SRTP hacia Teams, RTP sin cifrar hacia el operador. La conversión ocurre de forma transparente en el límite del SBC, y ninguno de los lados necesita cambiar su configuración para adaptarse al otro.

Inteligencia de enrutamiento

El motor de enrutamiento del SBC es lo que convierte una coleccion de troncales SIP en una plataforma de voz gestiónada. El enrutamiento de menor costo seleccióna al operador más económico para cada destino. La conmutación por error basada en prioridades asegura que las llamadas se dirijan a un operador de respaldo en milisegúndos si la troncal principal falla. El enrutamiento via API permite que sistemás externos (plataformás de facturación, bases de datos CRM, motores de detección de fraude) influyan en las decisiones de enrutamiento en tiempo real durante la fase de señalización, antes de que la llamada sea contestada.

Cumplimiento regulatorio

El cumplimiento de STIR/SHAKEN requiere que el SBC firme las llamadas salientes con un token de identidad criptográfico y verifique los tokens en las llamadas entrantes. El SBC se integra con servicios de firma externos para manejar la atestación (niveles A, B o C) e inyecta el encabezado Identity en la señalización SIP. Para los proveedores de servicios que operan en Estados Unidos, la regla de certificado propio de la FCC (vigente desde septiembre de 2025) exige que los proveedores firmen las llamadas usando su propio certificado STIR/SHAKEN en lugar de depender del de un tercero, lo que convierte la integración del SBC con la infraestructura de firma en un requisito regulatorio directo.

Seguridad de troncales SIP

Exponer las troncales SIP a la internet pública introduce una superficie de amenazas bien documentada. Esta seccion cubre los controles de seguridad que un SBC aplica en el borde de la red. Para un tratamiento integral de la seguridad VoIP, incluyendo arquitecturas de detección de fraude, prevencion de fraude telefónico y mitigacion avanzada de amenazas, consulte la cobertura dedicada de seguridad VoIP.

Cifrado de señalización y medios

TLS cifra la señalización SIP, previniendo la interceptacion de información de establecimiento de llamadas (quien esta llamando a quien, desde que direcciónes, a traves de que rutas). SRTP cifra los medios de voz en si, protegiendo el contenido de la llamada contra la interceptacion. Juntos, proporcionan protección de extremo a extremo para la troncal SIP, y el SBC gestióna ambos de forma independiente por grupo de troncales, de modo que los requisitos de cifrado pueden diferir entre el tramo del operador y el tramo del cliente sin que ninguno de los lados necesite ajustarse.

Ocultación de topologia

Sin ocultación de topologia, los encabezados SIP filtran direcciónes IP internas a partes externas. Un atacante que capture la señalización SIP puede mapear la red interna, identificar terminales específicos y atacarlos directamente. El SBC reemplaza las direcciónes internas en los encabezados Contact, Via y Record-Route con su propia dirección pública, presentando un único punto de contacto al mundo exterior mientras mantiene la topologia interna invisible.

Mitigacion de DoS/DDoS

Los ataques de inundación SIP, el escaneo de registros SIP y la denegación de servicio basada en INVITE son realidades cotidianas para la infraestructura SIP expuesta a internet. La limitacion de velocidad integrada del SBC, el control de conexiónes y las listas de bloqueados dinámicas absorben estos ataques en el borde antes de que consuman recursos en la plataforma de telefonia interna.

Control de acceso a llamadas y prevencion de fraude

Las listas de bloqueados dinámicas de rangos IP o patrones de números llamantes/llamados, incluyendo listas grises basadas en porcentaje para tráfico anómalo, permiten una respuesta en tiempo real a eventos de fraude. Para los proveedores de servicios, la calificación de fraude por llamada mediante integración con socios validados de detección de fraude (TransNexus, SecureLogix, YouMail) detecta el fraude telefónico y los patrones de llamadas automatizadas antes de que generen exposicion en la facturación.

Interoperabilidad y normalización SIP

La interoperabilidad SIP es el desafio operativo más persistente en las redes de voz multifabricante. Los RFC de SIP definen un marco flexible, y esa flexibilidad significa que cada proveedor, operador y plataforma implementa el protocolo de manera ligeramente diferente. Cuando dos terminales con diferentes implementaciónes de SIP intentan comúnicarse, las llamadas fallan, las funciones dejan de operar o las sesiónes se desconectan inesperadamente, a menos que un SBC normalice entre ellos.

Problemás comunes de interoperabilidad

Encabezados SIP propietarios son la fuente más frecuente de fallas de interoperabilidad. El operador A incluye encabezados P- personalizados que el operador B rechaza como malformados. Un fabricante de PBX envia encabezados X- que una plataforma UCaaS elimina silenciosamente, rompiendo las funciones de llamada que dependen de ellos.

Formato de P-Asserted-Identity (PAI) varia entre proveedores y es crítico para la presentación de identificación de llamadas y la atestación STIR/SHAKEN. Si el terminal de origen formatea PAI de manera diferente a lo que espera el terminal de destino, la visualización del identificador de llamadas fallá o la atestación baja de A a C.

Manejo de temporizadores de sesión bajo RFC 4028 se implementa de forma inconsistente. Algunos terminales esperan que el llamante renueve la sesión, otros esperan que lo haga el llamado. Un comportamiento de temporizador de sesión no coincidente causa que las llamadas se desconecten despues de un intervalo fijo, un problema que solo se manifiesta en producción bajo duraciones de llamada específicas.

Fallas en la negociación de codecs ocurren cuando los terminales no pueden acordar un codec de audio comun. Un operador movil que ofrece AMR-WB y un PBX empresarial que solo es compatible con G.711 no lograran negociar a menos que el SBC transcodifique entre ellos.

Como el SBC resuelve la interoperabilidad

El motor de manipulación de encabezados SIP del SBC aplica reglas por grupo de troncales para agregar, modificar o eliminar encabezados SIP en cada tramo de la llamada. Cada operador, PBX y plataforma obtiene su propio perfil de normalización dentro de su configuración de grupo de troncales. Cuando una llamada cruza entre dos grupos de troncales, el SBC traduce el dialecto SIP de uno al dialecto que el otro espera, de forma transparente, sin que ningun terminal necesite cambiar su configuración.

Para la interoperabilidad de codecs, el SBC realiza transcodificación en tiempo real entre formatos incompatibles. ProSBC es compatible con transcodificación basada en software para variantes de G.711, manejando la conversión en el límite del SBC de modo que cada terminal utilice su codec preferido sin compromisos.

Enrutamiento directo de Microsoft Teams con un SBC

El Enrutamiento directo de Microsoft Teams es el caso de uso de SBC de mayor demanda en el mercado norteamericano de MSP. Conecta el sistema telefónico de Teams a cualquier operador PSTN a traves de un SBC gestiónado por el cliente, sin depender de los planes de llamadas de Microsoft y otorgando al proveedor de servicios control total sobre la selección de operador, la lógica de enrutamiento y la infraestructura de telefonia.

Lo que Teams requiere del SBC

Teams aplica requisitos SIP estrictos que las troncales SIP estándar y los proxies SIP no pueden cumplir. El SBC debe terminar TLS (minimo 1.2) en el tramo de señalización hacia Teams usando un certificado de una autoridad certificadora de confianza de Microsoft. Todos los medios deben ser SRTP: Teams rechaza RTP sin cifrar. El SBC debe responder a los latidos SIP OPTIONS para mantener su estado “en linea” en el Centro de administración de Teams. Y el SBC debe normalizar los encabezados SIP entre el dialecto SIP del operador y las expectativas específicas de Teams, incluyendo la multiplexación RTCP-en-RTP.

Un SBC B2BUA maneja todo esto de forma nativa: termina completamente la sesión del operador en un lado y genera una sesión compatible con Teams en el otro, gestiónando TLS, SRTP, normalización de encabezados y ocultación de topologia de forma independiente en cada tramo.

Por que los MSP e ISP eligen el Enrutamiento directo

Para los proveedores de servicios, el Enrutamiento directo es una jugada de plataforma. Una sola instancia de SBC puede servir a multiples inquilinos empresariales con enrutamiento aislado por inquilino, aprovechando los propios contratos de operador del proveedor y las tarifas negociadas. El proveedor controla la infraestructura de voz (conmutación por error, detección de fraude, grabación de llamadas, cumplimiento) en lugar de delegarla a los planes de llamadas de Microsoft o al programa Operator Connect.

Para comprender el proceso completo de extremo a extremo de conectar Teams a la PSTN, incluyendo requisitos de licenciamiento, configuración del Centro de administración de Teams y configuración del lado del SBC, consulte la guía complementaria.

Zoom Phone BYOC e integración con Webex Calling

Microsoft Teams no es la única plataforma de colaboración que requiere integración con SBC. Zoom Phone BYOC (Bring Your Own Carrier) y Cisco Webex Calling admiten conectividad PSTN mediada por SBC, cada uno con sus propios requisitos de certificación y específicaciones SIP.

Zoom Phone BYOC

Zoom Phone BYOC permite a los proveedores de servicios conectar sus propias troncales de operador a la plataforma de telefonia en la nube de Zoom a traves de un SBC certificado. La arquitectura es similar al Enrutamiento directo de Teams: el SBC termina la troncal del operador en un lado y una troncal orientada a Zoom en el otro, manejando el cifrado, la normalización y el enrutamiento entre ellos. Para los proveedores de servicios que ya operan infraestructura de troncales SIP, agregar Zoom BYOC es una configuración incremental de grupo de troncales en el mismo SBC que sirve sus interconexiónes con operadores e implementaciónes de Teams.

Webex Calling

Cisco Webex Calling es compatible con la implementación de Local Gateway, donde un SBC gestiónado por el cliente conecta la nube de Webex con operadores PSTN o sistemás PBX locales. El SBC maneja la interoperabilidad SIP entre la implementación SIP de Webex y la del operador, con perfiles de cifrado y normalización por troncal.

Consolidación de SBC multiplataforma

La ventaja operativa para los proveedores de servicios es la consolidación. Una sola implementación de SBC nativo en la nube, con suficiente capacidad de grupos de troncales, puede terminar troncales de operadores, servir inquilinos de Enrutamiento directo de Teams, entregar Zoom Phone BYOC y conectar clientes de Webex Calling, todo a traves de grupos de troncales aislados con sus propios perfiles de seguridad, codec y normalización. Esto elimina la necesidad de dispositivos SBC separados por plataforma y centraliza el enrutamiento, la seguridad y el monitoreo en un único plano de gestión.

Migración de PRI a SIP: guía práctica para proveedores de servicios

El desmantelamiento de la PSTN se esta acelerando a nivel mundial. La infraestructura PRI heredada esta siendo retirada, y los proveedores de servicios que aun dependen de circuitos TDM enfrentan tanto una fecha límite regulatoria como una realidad económica: mantener redes TDM e IP en paralelo es cada vez más costoso.

La arquitectura de migración

Una migración de PRI a SIP para un proveedor de servicios típicamente involucra dos componentes trabajando juntos: una pasarela de medios que convierte la señalización y los medios TDM a SIP, y un SBC que maneja el enrutamiento, la seguridad y la interconexión con operadores del lado IP.

La pasarela de medios termina los circuitos PRI (T1/E1) y convierte el tráfico TDM a SIP. El SBC recibe el tráfico SIP de la pasarela y lo enruta a operadores ascendentes, clientes empresariales o plataformás UCaaS, aplicando toda la seguridad, normalización e inteligencia de enrutamiento que una implementación SIP en producción requiere.

Estrategia de migración por fases

El enfoque más seguro es una migración troncal por troncal: convertir un circuito PRI a la vez, validar la calidad de llamada y el enrutamiento, y luego continuar con el siguiente. El motor de enrutamiento del SBC puede manejar tanto troncales heredadas (provenientes de la pasarela) como troncales SIP nativas simultáneamente, permitiendo una transición gradual sin interrupción del servicio.

Para los ILEC y operadores rurales con mandatos gubernamentales de proveer servicio telefónico, la ruta de migración debe preservar el enrutamiento 911/E911 y la portabilidad numérica local durante toda la transición. El motor de enrutamiento del SBC y la compatibilidad de señalización de la pasarela de medios (SS7, ISDN PRI, CAS) aseguran la continuidad durante el período de transición.

Preguntas frecuentes

Conclusion

Las troncales SIP son la base de la infraestructura de voz moderna para proveedores de servicios. La tecnologia en si es madura, pero las decisiones de arquitectura (donde se ubica el SBC, cómo se estructuran los perfiles de normalización, que controles de seguridad operan en el borde y como la inteligencia de enrutamiento se conecta con sistemás externos) determinan si una implementación escala de manera confiable a traves de operadores, plataformás y clientes.

El SBC es el componente arquitectónico innegociable. Aplica seguridad en el borde de la red, resuelve los problemás de interoperabilidad SIP que surgen en cada entorno multifabricante, gestióna el cifrado de forma independiente por grupo de troncales y proporciona la inteligencia de enrutamiento que convierte una coleccion de troncales SIP en una plataforma de voz gestiónada. Para los proveedores de servicios que entregan voz a clientes empresariales, dan soporte a Enrutamiento directo de Teams y Zoom Phone BYOC, y mantienen el cumplimiento regulatorio con STIR/SHAKEN, el SBC es la infraestructura que hace que todo funcióne desde un único punto de control.

Lectura adicional

Para comprender cómo funcióna la manipulación de encabezados SIP en la práctica, desde la normalización de proveedores hasta la correccion de P-Asserted-Identity y el manejo de temporizadores de sesión, lea Manipulación de encabezados SIP: qué es y por que su SBC la necesita.

Para entender por que un proxy SIP no puede reemplazar a un SBC B2BUA en entornos de troncales SIP en producción, y cuando cada uno es la eleccion arquitectónica correcta, consulte ¿Qué es un proxy SIP?.