La decisión sobre telefonía en sucursales parece engañosamente sencilla: comprar trunks o suscribirse a un servicio alojado. En la práctica, la elección entre SIP trunking y VoIP alojado define la arquitectura de control de llamadas, el comportamiento ante fallos y la residencia de datos durante años. Equivocarse significa pagar por mantener equipos locales que ya no encajan en tu infraestructura, o haber cedido la soberanía del procesamiento de llamadas a una plataforma cuya ruta de audio no puedes mapear del todo.

Esta guía analiza las diferencias estructurales, los modos de fallo más relevantes a escala de sucursal y las consideraciones de cumplimiento que se han vuelto innegociables en los sectores regulados.

La división arquitectónica fundamental

El SIP trunking y el VoIP alojado resuelven problemas distintos. Con SIP trunking, tu organización posee y opera la capa de control de llamadas: una IP-PBX ocupa el centro, los Session Border Controllers gestionan la seguridad y la QoS en el perímetro, y el proveedor de SIP trunk suministra la conectividad de operador. El proveedor termina las llamadas; tú las enrutas. Con VoIP alojado, el proveedor opera todo el sistema telefónico. Lo consumes como servicio; la lógica de PBX, los planes de marcación y el procesamiento de llamadas residen en la infraestructura del proveedor.

Esa distinción tiene consecuencias directas en cada decisión que tome la sucursal. El SIP trunking es un producto de conectividad que se añade a la infraestructura que ya controlas. El VoIP alojado es un sistema gestionado que reemplaza la infraestructura que, de otro modo, tendrías que operar tú mismo.

El perfil de CAPEX refleja esto con claridad. Un despliegue de SIP trunking requiere hardware de IP-PBX, teléfonos IP de grado empresarial, licencias de SBC y el tiempo de ingeniería necesario para integrarlos. Las implementaciones de VoIP alojado suelen completarse en días o semanas con una interrupción mínima; las transiciones a SIP trunking exigen una planificación cuidadosa, una migración por etapas y pruebas de failover antes de tocar el tráfico en producción. Ninguno es intrínsecamente superior; la respuesta correcta depende de lo que tu organización ya posea y del grado de control operativo que quiera conservar.

Supervivencia de sucursales y arquitectura de failover

Las sucursales introducen un modo de fallo que los despliegues centralizados pueden ignorar: la pérdida de WAN. Cuando cae el enlace entre una sucursal y la PBX central, el control de llamadas desaparece a menos que lo hayas previsto.

El SIP trunking aborda esto mediante gateways de supervivencia locales. Un gateway local en la sucursal mantiene la funcionalidad básica de llamadas con independencia del sistema central. Cuando falla la ruta de trunk principal, las llamadas se redirigen automáticamente a través de trunks de respaldo, operadores alternativos o la PSTN. Desde la perspectiva del llamante, la conmutación es transparente. Las instituciones sanitarias y financieras mantienen habitualmente un respaldo PSTN como ruta de último recurso, en parte porque sus obligaciones regulatorias así lo exigen y en parte porque ningún failover definido por software es incondicional.

Un plan de recuperación ante desastres de voz que no se ha probado trimestralmente es un documento, no una capacidad. Los objetivos de RTO/RPO definidos, los escenarios de fallo mapeados, el clustering de SBC y la lógica de enrutamiento redundante solo demuestran su valor bajo carga controlada antes de que se necesiten en condiciones reales.

El VoIP alojado gestiona la supervivencia de sucursales de forma diferente. Como el control de llamadas reside en la infraestructura del proveedor, la resiliencia de la sucursal depende por completo de la redundancia de red y la distribución geográfica del proveedor. Un proveedor con una densa red de puntos de presencia y failover regional automático puede ofrecer una supervivencia sólida sin ningún gateway local. Un proveedor que opera en una sola región no puede hacerlo. Aquí la topología de red importa tanto como la lista de funcionalidades del producto.

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 despliegues de sucursales enrutados a través de nuestro producto Telecom, esa densidad de peering significa que las rutas de audio se mantienen cortas y los destinos de failover están geográficamente próximos, lo que marca la diferencia práctica entre una redirección de 200 milisegundos y una que cruza un océano.

Requisitos de seguridad en 2025

La línea base de seguridad para los despliegues SIP ha avanzado considerablemente. Enviar SIP sobre el puerto UDP 5060 con RTP en texto claro ya no es una práctica aceptable. Los despliegues modernos requieren TLS 1.2 o 1.3 para la señalización y SRTP o DTLS-SRTP para los medios. La firma STIR/SHAKEN en las llamadas salientes es ya una expectativa; los operadores bloquean cada vez más el tráfico sin firmar o mal etiquetado, por lo que un trunk sin firmar es una responsabilidad creciente, no solo una carencia.

Los proveedores de VoIP alojado absorben la mayor parte de esta complejidad: el cifrado, la firma y la gestión de SBC son problema del proveedor. Con SIP trunking, son tuyos. Eso no es un argumento en contra del SIP trunking para organizaciones con la capacidad de ingeniería necesaria para gestionarlo; es un argumento para tener claridad sobre lo que implica realmente el compromiso operativo.

Residencia de datos y RGPD: lo que significa realmente la ruta de audio

Los sistemas de VoIP y telefonía en la nube procesan datos personales: registros de llamadas, grabaciones de audio, identificación de llamante y metadatos de geolocalización. Bajo el RGPD, cualquier transferencia internacional de esos datos requiere una base jurídica conforme al Capítulo V (artículos 44 a 50), con garantías adecuadas. Las multas por infracciones alcanzan los 20 millones de euros o el 4 % de la facturación global anual, la cifra que sea mayor, y un Acuerdo de Tratamiento de Datos conforme al artículo 28 es obligatorio independientemente de la arquitectura.

La residencia de datos en la UE no es técnicamente exigida por el RGPD, que es tecnológicamente neutro en principio. Pero mantener los datos dentro de la UE elimina por completo la obligación de transferencia del Capítulo V: sin evaluación del impacto de la transferencia, sin cláusulas contractuales tipo y con menores expectativas de las autoridades de supervisión respecto a salvaguardas adicionales. Para la mayoría de las organizaciones, esa simplificación vale más que la flexibilidad marginal de un proveedor fuera de la UE.

El matiz que los compradores pasan por alto: un sistema alojado en la UE puede seguir enrutando audio a través de infraestructura de operador que toca puntos de presencia fuera de la UE. La región de alojamiento y la ruta de audio no son lo mismo. Antes de firmar cualquier contrato de voz empresarial, pide al proveedor el diagrama de la ruta de audio, no solo la región donde se almacenan los registros de llamadas o los datos de inferencia. Si no pueden facilitarlo, esa es tu respuesta.

Sectores regulados: obligaciones derivadas de DORA y NIS2

Para las organizaciones del sector financiero, DORA (Reglamento UE 2022/2554, aplicable desde enero de 2025) añade una capa de supervisión de terceros que afecta directamente a la decisión de adquirir VoIP alojado. DORA exige marcos formales de riesgo TIC, una supervisión estructurada de todos los proveedores terceros de TIC y un Registro de Información completo que cubra cada acuerdo con proveedores. El reglamento excluye explícitamente los servicios telefónicos analógicos tradicionales de su definición de proveedor tercero de TIC, pero el VoIP alojado en la nube pertenece a una categoría diferente: cualquier proveedor que preste servicios TIC cubiertos está dentro del ámbito de aplicación. Las entidades financieras deben confirmar con asesoría jurídica cómo se clasifica su acuerdo de telefonía específico antes de firmar.

NIS2 (Directiva UE 2022/2555, en vigor desde octubre de 2024) es relevante en el lado del proveedor. Los operadores de telecomunicaciones y los proveedores de infraestructura en la nube están clasificados explícitamente como entidades esenciales o importantes bajo NIS2. Un proveedor de VoIP alojado que sirva a empresas de la UE está sujeto a los requisitos de gestión de riesgos de seguridad de NIS2 y a la obligación de notificación de incidentes en 24 horas. Solicitar a un proveedor potencial su clasificación NIS2 y la documentación de respuesta ante incidentes es una parte razonable de la diligencia debida, no una petición excepcional.

Cómo elegir la arquitectura adecuada

El SIP trunking encaja en organizaciones que ya operan una IP-PBX, manejan grandes volúmenes de llamadas en múltiples ubicaciones y cuentan con el equipo de ingeniería para gestionar SBCs, cifrado y lógica de failover. El control es real, pero también lo es la superficie operativa.

El VoIP alojado encaja en organizaciones que consolidan la infraestructura de sucursales, reducen su huella local o adoptan un modelo de consumo en el que la telefonía es un servicio, no un sistema que mantener. La contrapartida es la dependencia de la calidad de red del proveedor, su alcance geográfico y sus compromisos de residencia de datos.

Para las empresas que consolidan sobre nube soberana, la decisión rara vez gira en torno a las funcionalidades. Gira en torno a dónde reside el control de llamadas, por dónde viaja el audio y si la topología de red del proveedor puede realmente ofrecer el comportamiento de failover que promete el diagrama de arquitectura. Son preguntas de ingeniería y merecen respuestas de ingeniería antes de que se firme el contrato.