La infraestructura de voz es el único sistema en el que “lo restauramos en una hora” no es una respuesta aceptable. Una caída del datacenter que deja tus SIP trunks fuera de línea no pone en pausa tu centro de llamadas, no aplaza las comunicaciones de tu mesa de trading ni espera amablemente a que tus ingenieros terminen el desayuno. Corta llamadas, bloquea líneas entrantes y, en sectores regulados, genera un incidente que hay que explicar. Diseñar correctamente el failover de SIP trunk implica abordar el fallo en cada capa de forma simultánea, no solo contratar un segundo trunk con el mismo operador.
Este artículo recorre la arquitectura desde los cimientos: qué falla realmente, dónde debe vivir la redundancia y cómo los mecanismos de detección y conmutación determinan si tu ventana de failover se mide en segundos o en minutos de silencio total.
Qué es realmente un SIP trunk y dónde se rompe
Un SIP trunk reemplaza los circuitos PRI físicos de la telefonía TDM heredada con una conexión IP lógica que transporta tanto la señalización como el media. Donde un PRI te ofrecía un número fijo de canales sobre cobre o fibra dedicados, un SIP trunk es una ruta gobernada por políticas entre tu infraestructura de voz (PBX, plataforma UCaaS o softswitch) y un operador o pasarela PSTN. Esa ruta es tan resiliente como la red sobre la que corre, y no más.
Un despliegue de SIP trunking en producción tiene cuatro componentes que pueden convertirse cada uno en un punto de fallo: el Session Border Controller en el perímetro de red, la conexión o conexiones con el operador upstream, la infraestructura de voz orientada al cliente y el motor de enrutamiento y políticas que gobierna el flujo de llamadas entre todos ellos. La mayoría de los post-mortems de incidentes trazan el fallo hasta exactamente una de estas capas, mientras las demás funcionaban bien. Ese es el problema: una sola capa sin cubrir tumba el sistema entero.
El Session Border Controller es el ancla arquitectónica. Se sitúa en el límite entre tu red de confianza y el lado orientado al operador, gestionando de forma independiente la señalización y el media en cada tramo. Se encarga del cumplimiento de seguridad, la normalización de protocolos, la terminación del cifrado y el enrutamiento de grupos de trunk. Es también el lugar natural para implementar la detección de fallos, porque ve ambos lados de la ruta de llamada de forma simultánea.
Las tres capas donde debe vivir la redundancia
Una alta disponibilidad robusta de SIP trunk requiere redundancia en la capa de proveedor, la capa de red y la capa de PBX o softswitch. Cubrir solo dos de las tres deja un único punto de fallo que tarde o temprano se ejercitará.
Capa de proveedor: tu proveedor de SIP trunk necesita operar proxies SIP con redundancia geográfica en múltiples ubicaciones físicas. Si terminan todo el tráfico a través de un único emplazamiento, tu trunk secundario con ese mismo proveedor no ofrece ninguna protección ante un evento a nivel de datacenter. La diversidad de doble operador, donde tus trunks principal y secundario terminan en instalaciones de operadores distintos, es la postura mínima viable para empresas en las que el tiempo de inactividad de voz es inaceptable.
Capa de red: aquí es donde el multihoming BGP se vuelve crítico y donde la capa de infraestructura separa los despliegues de voz serios de los que solo parecen redundantes en un diagrama. Si tu SBC se conecta a internet o a las redes del operador a través de un único proveedor upstream, una retirada de BGP o el fallo de un enlace upstream deja fuera de línea tanto tu trunk SIP principal como el secundario, independientemente de cuántos hayas aprovisionado. El multihoming BGP con proveedores upstream independientes en el mismo emplazamiento físico, o en emplazamientos geográficamente separados, garantiza que un fallo de enrutamiento que afecte a una ruta no elimine toda la accesibilidad.
Capa de PBX y softswitch: la propia plataforma de procesamiento de llamadas debe tolerar el fallo de un sitio. Esto implica o bien un par de softswitches con redundancia geográfica y estado sincronizado, o bien un diseño donde el enrutamiento de entrantes a nivel del operador pueda redirigir a una plataforma secundaria sin necesidad de que la primaria esté suficientemente sana como para redirigirlo ella misma.
Una arquitectura de failover es tan robusta como su capa más débil sin cubrir. Dos SIP trunks del mismo operador, terminando en el mismo datacenter, sobre la misma ruta de red upstream, no es redundancia. Es la apariencia de redundancia.
Detección de fallos: los mecanismos que determinan tu ventana de conmutación
El mecanismo principal de detección del estado de un SIP trunk es el keepalive OPTIONS. El SBC envía peticiones SIP OPTIONS periódicas al peer del operador upstream; una respuesta 200 OK indica que el trunk está sano, mientras que respuestas 4xx/5xx o timeouts disparan un contador de fallos. Cuando los fallos consecutivos superan un umbral configurado, el trunk se marca como no disponible y el tráfico se desplaza hacia la siguiente ruta disponible.
El intervalo de sondeo determina tu ventana de detección en el peor caso. Los fabricantes suelen establecer por defecto un intervalo de OPTIONS de 60 segundos. Con esa configuración, el tiempo de detección en el peor caso supera por sí solo el minuto antes de que comience siquiera la lógica de conmutación. Para entornos donde la continuidad de voz importa, el rango recomendado es de 30 a 60 segundos con conteos de reintento agresivos. En Asterisk con PJSIP, el parámetro qualify_frequency=30 envía OPTIONS cada 30 segundos; combinarlo con qualify_timeout=3 marca un contacto como no disponible con suficiente rapidez como para que entornos bien configurados completen una conmutación en 5 a 30 segundos en lugar de varios minutos.
Las comprobaciones de estado a nivel de red mediante sondas ICMP o TCP hacia las IPs de los routers de borde del operador complementan la detección en la capa SIP, pero no deben reemplazarla. Un router de borde del operador que responde a ICMP mientras su proxy SIP no responde superará las comprobaciones de la capa de red y fallará las de la capa SIP. La monitorización RTCP y RTCP-XR de pérdida de paquetes, jitter e informes similares al MOS añade una tercera dimensión: la calidad de la ruta de media puede degradarse mucho antes de que un trunk sea completamente inalcanzable. Correlacionar las tres capas ofrece una visión que ningún método de sondeo individual puede proporcionar.
Activo-pasivo frente a activo-activo: las compensaciones reales
El modo activo-pasivo (1+1) mantiene un trunk transportando tráfico en vivo mientras un segundo permanece en caliente, listo para tomar el relevo. Es predecible de operar, fácil de razonar durante un incidente y deja capacidad ociosa en estado estable. Para la mayoría de los despliegues empresariales, es el punto de partida correcto.
El modo activo-activo en dos sitios ejecuta tráfico concurrente en ambas ubicaciones, habitualmente con balanceo de carga en el lado del operador que distribuye llamadas por geografía, por tenant o mediante DNS ponderado por salud. La conmutación es más rápida porque el tráfico ya fluye por ambas rutas. Pero el coste en complejidad es real: la consistencia de la ruta de media se vuelve más difícil cuando la latencia entre sitios afecta a la calidad de voz, la negociación de codecs debe ser idéntica en ambas regiones y, para los contact centers donde el contexto de la llamada importa (transferencias activas, anclajes de grabación, supervisión), mantener un estado consistente en dos sitios activos es un problema de ingeniería no trivial.
Existe además una restricción crítica que se pasa por alto con frecuencia en los diseños de SBC con redundancia geográfica. La mayoría de las implementaciones de par de alta disponibilidad de SBC requieren que ambos nodos estén en la misma subred de capa 2 para funcionar como par activo-pasivo, porque dependen de ARP gratuito para anunciar una nueva MAC para la IP compartida tras el failover. La mayoría de los datacenters geográficamente separados están separados por diseño en capa 3. No puedes dividir un par HA convencional de SBC entre dos sitios físicamente distintos y esperar que el mecanismo de HA funcione como lo haría dentro de una única instalación. La arquitectura debe contemplar esto: bien tratando cada sitio como un SBC independiente con sus propias conexiones de operador y la lógica de failover gestionada en la capa de enrutamiento, bien usando plataformas SBC que soporten explícitamente la redundancia geográfica con estado sobre enlaces de capa 3.
BGP failover para VoIP: qué necesita hacer realmente la capa de red
El BGP failover para VoIP no consiste solo en tener dos proveedores upstream. Requiere que tu espacio de direcciones IP se anuncie desde múltiples sistemas autónomos o mediante múltiples rutas upstream, de modo que una retirada en una ruta no haga inalcanzable tu SBC. Para las llamadas entrantes, el operador necesita poder alcanzar la IP de tu SBC independientemente de qué enlace upstream esté sano. Para las llamadas salientes, tu SBC necesita una ruta por defecto que sobreviva a un único fallo upstream sin requerir intervención manual.
En DIVERSITY, nuestras instalaciones carrier-neutral en Madrid, Múnich, Helsinki y Ámsterdam operan con multihoming BGP sobre proveedores upstream independientes en cada sitio, y contamos con certificación Tier III y un SLA contractual de disponibilidad del 99,9%, no un compromiso de marketing. La certificación ISO 27001 y el estatus carrier-neutral significan que los clientes que ejecutan SIP trunks a través de nuestra infraestructura pueden traer sus propios operadores o usar los nuestros, con la redundancia de red integrada en la instalación en lugar de añadida a posteriori. La soberanía aquí es una garantía a nivel contractual: la infraestructura, el enrutamiento y los datos permanecen bajo jurisdicción europea.
Cómo encaja todo en la arquitectura
Una infraestructura de voz que sobrevive a la caída de un datacenter tiene este aspecto: instancias duales de SBC en dos sitios geográficamente separados, cada uno con conexiones de operador independientes a al menos dos proveedores de SIP trunk, y cada sitio conectado a internet mediante multihoming BGP con ASNs upstream separados. Los keepalives OPTIONS se ejecutan con intervalos de 30 segundos y umbrales de reintento cortos. El enrutamiento de números entrantes a nivel del operador apunta a ambas direcciones de SBC, con DNS ponderado por salud o lógica de redirección SIP para desplazar el tráfico cuando un sitio se vuelve inalcanzable. El PBX o softswitch o bien replica el estado entre sitios, o bien está diseñado para aceptar llamadas en cualquier ubicación sin necesidad de que la otra esté sana.
La prueba de la arquitectura no es si parece correcta en un diagrama. Es si puedes dejar un datacenter fuera de línea durante una ventana de mantenimiento, observar cómo fallan las sondas OPTIONS, ver cómo se completa la conmutación y confirmar que las llamadas en curso sobreviven y las nuevas se conectan. Si no has ejecutado esa prueba, tienes un diseño de failover, no una capacidad de failover.
