El precio por puesto en un presupuesto de PBX alojada parece claro. Treinta puestos a 15 dólares al mes, quizás 20 si quieres grabación de llamadas. Entonces tu equipo de infraestructura hace una pregunta sencilla: ¿qué ocurre con el tráfico de voz si el sitio principal cae? Ahí es donde el modelo de precios empieza a desmoronarse en silencio y el coste real de la redundancia en una centralita virtual comienza a aflorar.
No es una preocupación exclusiva de las grandes empresas. Cualquier organización que opere en dos o más sitios europeos necesita failover geográfico para voz. Y la diferencia entre la tarifa presupuestada y lo que realmente se paga una vez configurado correctamente ese failover es, según estimaciones conservadoras, entre un 20 y un 40 por ciento más que la cifra anunciada.
La licencia de PBX en sí suele representar solo el 40 por ciento del gasto total en comunicaciones. El resto corresponde a trunking, SBCs, configuración de failover, conectividad de respaldo y la carga operativa de gestionarlo todo entre sitios. Los proveedores no ocultan esto de forma malintencionada; fijan el precio del núcleo y dejan que la arquitectura revele el resto.
Las tres capas de redundancia que los proveedores cotizan de forma selectiva
La alta disponibilidad real en una PBX en la nube requiere redundancia en cada capa del stack. Si falla una capa, las demás no la compensan. Las tres capas son: el proveedor de troncal SIP, la propia PBX y la conexión a internet en cada sitio. Cada una añade coste y, por lo general, se vende por separado.
En la capa de troncal, un proveedor SIP con redundancia geográfica opera proxies en varios centros de datos y desvía el tráfico automáticamente cuando una ubicación cae. Esta es la forma más transparente de failover porque no requiere cambios en la configuración de tu PBX. Sin embargo, la capacidad de proxy SIP con redundancia geográfica no siempre está incluida en el precio estándar de la troncal; con frecuencia forma parte de un nivel superior.
En la capa de PBX, necesitas varias troncales configuradas con enrutamiento por prioridad, de modo que la PBX detecte fallos mediante heartbeats SIP OPTIONS y redirija las llamadas a través de una troncal secundaria. Aquí es donde se acumula la complejidad de configuración, especialmente en despliegues multisitio donde cada sitio puede tener su propia relación de troncal y su propio camino de failover.
En la capa de red, necesitas conectividad dual con dos ISP y SD-WAN o enrutamiento basado en políticas para conmutar el tráfico SIP entre rutas. El modo de fallo más habitual en una interrupción de voz no es la PBX ni el proveedor de troncal: es la conexión a internet. La conectividad de respaldo mediante failover celular suele requerir hardware adicional de entre 300 y 700 dólares, más una suscripción de servicio de 50 a 150 dólares al mes por sitio.
Un único punto de fallo en cualquier capa compromete todo el sistema. La redundancia que se detiene en el nivel de troncal no es alta disponibilidad; es una mitigación parcial disfrazada de solución.
Dónde deja de funcionar el cálculo por usuario
La redundancia geográfica entre varios centros de datos añade aproximadamente entre 3 y 5 dólares por usuario al mes sobre el coste base del puesto, según cifras del mercado de 2025 y 2026. Las capacidades de failover automático, cuando requieren niveles de servicio premium o trabajo de configuración dedicado, pueden conllevar un coste de implementación único de entre 500 y 2.000 dólares. No son casos excepcionales; son componentes estándar de cualquier arquitectura que tome el tiempo de actividad en serio.
El session border controller es un coste que sorprende a muchos equipos que evalúan opciones de PBX alojada por primera vez. El trunking SIP requiere un SBC incluso en despliegues en la nube, y una unidad SBC individual cuesta alrededor de 1.000 dólares antes de las cuotas mensuales. Un despliegue de SBC en clúster para redundancia, que es la arquitectura correcta para el failover multisitio, multiplica esa cifra. El SBC se sitúa entre tu PBX y tus troncales, gestiona el traversal NAT, aplica la política de seguridad y es el componente que hace que el failover entre proveedores de troncal sea operativamente manejable. No es opcional si quieres voz fiable entre sitios.
Los entornos multioperador añaden otra dimensión. Si tu proveedor tiene precios competitivos en una región pero presencia limitada en otra, acabarás gestionando una segunda relación con un proveedor. Eso implica contratos de troncal SIP separados, configuraciones de SBC separadas, rutas de escalado de soporte separadas y facturación separada. La economía por puesto que resultaba atractiva en una evaluación de una sola región deja de ser válida en cuanto se tiene en cuenta la carga de gestionar dos stacks de voz paralelos.
La redundancia on-premises no es una alternativa más barata
Los equipos que han gestionado PBX on-premises a veces asumen que pueden construir redundancia de forma más económica administrando su propio hardware. Los números no lo respaldan. Una estrategia de hot-site para PBX on-premises requiere un segundo conjunto de hardware idéntico en una ubicación geográficamente separada, mantenido y sincronizado con el principal. Para la mayoría de las organizaciones de tamaño medio, duplicar el gasto de capital no es viable, y el coste operativo de mantener el sitio secundario al día con los cambios de configuración es una carga continua que no siempre se ve.
La PBX en la nube elimina el problema del gasto de capital, pero traslada el coste a las capas de suscripción y configuración, donde resulta menos visible. Ninguno de los dos modelos elimina el coste de la redundancia; simplemente lo hacen visible de forma diferente. La pregunta es qué modelo hace ese coste más predecible y más fácil de gestionar a lo largo del tiempo.
Lo que cambia realmente una presencia multisitio carrier-neutral
El problema central de la mayoría de los precios de redundancia en PBX alojada es que están diseñados bajo la premisa de un único proveedor y una única región. Cuando necesitas failover entre sitios geográficamente separados, estás trabajando en contra del modelo de precios, no a favor de él.
Nuestra infraestructura de telecomunicaciones opera en instalaciones carrier-neutral en Madrid, Múnich, Helsinki y Ámsterdam, con peering directo en cada sitio. Esa presencia significa que el failover de troncal SIP entre sitios no atraviesa la red interna de un único proveedor; utiliza rutas genuinamente independientes con relaciones de peering independientes. Para un cliente que gestiona un despliegue de voz europeo multisitio, esa distinción tiene importancia operativa: un fallo que tumbe la infraestructura regional de un proveedor no se propaga al camino de respaldo.
El mercado de trunking SIP alcanzó los 73.000 millones de dólares en 2025 y va camino de los 158.000 millones en 2030, impulsado en parte por los cierres de la PSTN como la migración programada en el Reino Unido para finales de enero de 2027. Las organizaciones que han aplazado las decisiones sobre infraestructura de voz las están tomando ahora bajo presión de tiempo, que es exactamente el momento en que la brecha entre un precio presupuestado y una arquitectura completamente redundante tiende a subestimarse.
Cómo evaluar los costes de redundancia de una PBX alojada con precisión
Al presupuestar un despliegue de PBX en la nube para operaciones europeas multisitio, la evaluación debe cubrir como mínimo: la redundancia geográfica en la capa de troncal y si está incluida o forma parte de un nivel superior; los costes del SBC y si se requiere un despliegue en clúster para tu arquitectura de failover; el hardware de conectividad de respaldo por sitio y los costes de servicio recurrentes; los costes de implementación para la configuración y las pruebas de failover; y la carga operativa de gestionar relaciones multioperador si tu proveedor no tiene cobertura nativa en todos tus sitios.
Un modelo de coste total realista será entre un 40 y un 60 por ciento más alto que la tarifa por puesto anunciada en cualquier despliegue que tome en serio el failover geográfico. Eso no es un motivo para evitar la PBX en la nube; es un motivo para incluir el coste completo de la arquitectura en el caso de negocio desde el principio, en lugar de descubrirlo después de firmar el contrato.
