Treinta y tres interrupciones documentadas de Microsoft Teams desde enero de 2025. Un fallo en cascada de 19 horas en julio que dejó fuera de servicio Exchange Online junto con Teams. Una interrupción grave de RingCentral que obligó al CEO a emitir una disculpa pública. No son casos aislados; son la realidad operativa de depender de un único proveedor de UCaaS para toda tu infraestructura de voz. La pregunta que deberían hacerse las empresas no es si su proveedor de UCaaS volverá a caer, sino qué ocurre con los teléfonos cuando eso sucede.
La resiliencia del SIP trunking se ha convertido en la respuesta arquitectónica a esa pregunta, y los datos del mercado lo reflejan. Data Bridge Market Research valora el mercado global de SIP trunking en 13.850 millones de dólares en 2024, con un crecimiento anual compuesto del 11,48% hacia los 33.050 millones en 2032. Europa es el segundo mercado regional con 4.200 millones de dólares, expandiéndose a un ritmo del 12,4% anual. Ese crecimiento no es nostalgia por el equipamiento on-premise; son empresas construyendo una capa de voz que realmente controlan.
Una encuesta de NetScout reveló que el 97% de las empresas sufrió interrupciones graves relacionadas con UCaaS en 2023, y el 64% estimó pérdidas de al menos 10.000 dólares en ventas y productividad por incidente. Para organizaciones con ingresos superiores a 10.000 millones de dólares, casi la mitad estimó pérdidas de entre 100.000 y más de un millón de dólares. Con esas cifras, el coste de un sistema de respaldo SIP correctamente diseñado se amortiza con la primera interrupción evitada.
Por qué las arquitecturas exclusivamente UCaaS tienen un problema estructural de resiliencia
Las plataformas UCaaS están diseñadas para la simplicidad: un proveedor, una aplicación, una factura. Esa consolidación es genuinamente útil para la colaboración cotidiana. Pero la voz es diferente de la presencia o el intercambio de archivos. Un mensaje de Teams perdido es una molestia; una llamada caída de un cliente, una mesa de operaciones o un contacto de emergencia es un evento de negocio con un coste asociado a cada minuto.
La interrupción de Microsoft de julio de 2025 ilustra el riesgo estructural. Un cambio en la configuración de enrutamiento dentro de la infraestructura de Microsoft desencadenó un fallo en cascada: Exchange Online cayó primero a las 22:20 UTC del 9 de julio, Teams le siguió a primera hora de la mañana del 10 de julio, y la interrupción se prolongó más de 19 horas. El propio Microsoft, durante un incidente separado en Azure, indicó a sus clientes que revisaran sus planes de continuidad de negocio y recuperación ante desastres. Es un proveedor reconociendo, por escrito, que no deberías tratarlo como un punto único de fallo.
Cuando tu proveedor de UCaaS te dice que revises tu plan de continuidad, te está diciendo que el SIP trunking no es un recurso de respaldo heredado. Es el plan de continuidad.
La interrupción de Avaya Cloud Office del 22 de enero de 2025 ilustró lo mismo desde otra perspectiva. Un proveedor que anunciaba un tiempo de actividad del 99,999% quedó sin servicio a primera hora de la tarde y permaneció así durante horas. El CEO de RingCentral confirmó que se trató de un error interno del sistema, no de un ataque externo. Ninguna arquitectura es inmune; la cuestión es si el fallo en una capa arrastra todo lo demás.
Cómo funciona en la práctica el failover de SIP trunk
El failover de SIP trunk es el redireccionamiento automático del tráfico de voz hacia una ruta de respaldo cuando el trunk principal o el proveedor deja de ser accesible. Combinado con la redundancia de SIP trunk, es decir, múltiples rutas independientes mantenidas en paralelo, constituye la base de la telefonía de alta disponibilidad. El punto crítico es que la redundancia debe existir en cada capa: proveedor, red y PBX. Un punto único de fallo en cualquiera de esas capas invalida las demás.
Los componentes de una arquitectura correctamente diseñada son sencillos. Un session border controller (SBC) se sitúa en el perímetro, gestiona la señalización y los medios, y puede configurarse para realizar el failover entre trunks en tiempos inferiores al segundo. Los usuarios de un sistema bien configurado raramente perciben el cambio. El enrutamiento a nivel DNS y el failover de IP añaden una segunda capa. El respaldo a la RTPC añade una tercera. La redundancia multiproveedor garantiza que, si la infraestructura de un operador tiene un problema, el tráfico se desplace a otro antes de que la llamada se corte.
El BGP multihoming es donde la resiliencia a nivel de red se hace concreta. El Border Gateway Protocol permite que las redes upstream reruten el tráfico de forma dinámica cuando una ruta deja de ser accesible, sin intervención manual y sin esperar a abrir un ticket de soporte. Para la voz, donde un retraso de 30 segundos ya equivale a una llamada fallida, la diferencia entre un failover con BGP y un redireccionamiento manual es la diferencia entre un evento transparente y una interrupción visible.
SIP on-premise frente a UCaaS: no es una elección binaria
El planteamiento de SIP on-premise frente a UCaaS pasa por alto la arquitectura que realmente utilizan las empresas más resilientes. UCaaS gestiona la capa de colaboración: presencia, mensajería, vídeo, salas de reuniones. El SIP trunking gestiona la conexión a la RTPC y proporciona la ruta de respaldo cuando la capa UCaaS tiene un problema. Son complementarios, no competidores.
Lo que el SIP trunking te ofrece y que el UCaaS por sí solo no puede darte es independencia del tiempo de actividad de un único proveedor. Tu plataforma UCaaS puede ser completamente inaccesible y las llamadas entrantes pueden seguir llegando a un SBC de respaldo, enrutarse a un grupo de búsqueda o redirigirse al móvil. Las llamadas salientes pueden seguir completándose. La columna vertebral de voz continúa operando porque no comparte un dominio de fallo con la plataforma de colaboración que tiene encima.
La continuidad de la telefonía empresarial, en esta arquitectura, significa que la capa RTPC sobrevive de forma independiente a lo que ocurra en la capa de aplicación. Esa separación es el objetivo de diseño, y el SIP trunking con infraestructura de grado operador es el modo de lograrlo.
Por qué la capa de red importa tanto como el proveedor de trunking
La resiliencia del SIP trunking es tan buena como la red que transporta la señalización y los medios. La latencia, el jitter y la pérdida de paquetes degradan directamente la calidad de las llamadas; la diversidad de rutas determina si un fallo de red arrastra también los trunks. Aquí es donde la infraestructura neutral al operador con alcance real de PoP cambia el cálculo.
Operamos 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en cada ubicación. Para los clientes de SIP trunking, ese peering tiene importancia operativa: cuando un proveedor de UCaaS como Microsoft o Zoom es accesible a través de una interconexión directa en lugar de la internet pública, el dominio de fallo para la señalización es más reducido y la ruta es más predecible. El BGP multihoming a través de esas interconexiones garantiza que un problema de enrutamiento en un upstream no se propague a la capa de voz. El trunk permanece activo porque la ruta hacia la RTPC no depende de la misma infraestructura que acaba de fallar.
Los ahorros de costes de entre el 25% y el 65% respecto a las líneas PRI heredadas siguen siendo el argumento económico más habitual a favor del SIP trunking, y son reales, especialmente para organizaciones multisede con altos volúmenes de llamadas. Pero el argumento de la resiliencia se ha vuelto al menos igual de sólido, y para los sectores regulados donde la telefonía forma parte de la obligación de continuidad operativa, suele ser el factor decisivo.
Qué preguntar antes de tu próxima interrupción
Si tu arquitectura actual enruta toda la voz a través de una única plataforma UCaaS, las preguntas que vale la pena responder ahora son: qué ocurre con las llamadas entrantes cuando esa plataforma no está disponible; cuánto tarda el failover manual; y quién gestiona la relación con la RTPC si el proveedor de UCaaS es el problema. Si las respuestas resultan incómodas, la arquitectura necesita una capa SIP por debajo. No en lugar del UCaaS, sino independiente de él, para que la próxima interrupción de 19 horas sea una molestia de colaboración y no un fallo de telefonía.
