Implementaciones de voz en la nube y el SBC: arquitectura para voz multinube, híbrida y SaaS

Las plataformas en la nube han absorbido la mayoría de las cargas de trabajo empresariales, pero la voz sigue siendo la excepción que confirma la regla. El correo electrónico, el CRM y la colaboración migraron a SaaS con mínima fricción porque toleran latencia, funcionan sobre HTTPS y nunca interactúan con la red telefónica pública. La voz es diferente. Funciona sobre SIP, exige una latencia de ida y vuelta inferior a 150 ms y cada llamada que llega a un número telefónico debe cruzar una interconexión con un operador, gobernada por décadas de regulación de telecomunicaciones e implementaciones SIP específicas de cada proveedor.

El controlador de borde de sesión (SBC) es el componente que resuelve esa brecha. Ya sea que su plataforma de voz funcione completamente en la nube, abarque múltiples proveedores de nube o se extienda entre infraestructura local y una nube pública, el SBC se ubica en el límite donde los troncales SIP se conectan con los servicios en la nube. Termina las conexiones del operador en un lado y las conexiones de la plataforma en la nube en el otro, gestionando la traducción de cifrado, la normalización SIP y la aplicación de seguridad que ni el operador ni la plataforma en la nube proporcionan por sí solos.

Este artículo explica por qué la voz en la nube aún requiere un SBC en el borde de la red, cómo funcionan los tres patrones de implementación dominantes y qué ocurre en el límite de interconexión con el operador para arquitecturas CPaaS, UCaaS e híbridas.

Por qué la voz en la nube aún necesita un borde físico

Las plataformas de voz en la nube gestionan el control de llamadas, la administración de usuarios y funciones cada vez más sofisticadas como agentes de voz con IA y transcripción en tiempo real. Lo que no gestionan es la transferencia al operador. Cada llamada que se origina o termina en la red telefónica pública debe cruzar un límite de troncal SIP donde la plataforma en la nube se conecta con un operador de telecomunicaciones, y ese límite es donde se concentran los problemas.

Los operadores entregan tráfico SIP con implementaciones de encabezados específicas de cada proveedor, soporte de cifrado variable y requisitos de transporte que difieren de un troncal a otro. Un operador puede enviar SIP sobre UDP sin cifrado; otro puede requerir TLS 1.2 con autenticación mutua de certificados. La plataforma en la nube del otro lado tiene sus propios requisitos. Microsoft Teams Direct Routing exige TLS y SRTP en cada conexión. Genesys Cloud requiere formatos de encabezado SIP específicos para su interfaz de troncal BYOC. Twilio Elastic SIP Trunking tiene sus propios requisitos de normalización.

El SBC resuelve esta incompatibilidad operando como un B2BUA que termina completamente el SIP en un lado y lo re-origina en el otro. Cada lado recibe el cifrado, los encabezados, los códecs y el transporte que espera, negociados de forma independiente. Sin un SBC, cada combinación operador-plataforma requiere trabajo de integración personalizado que el proveedor de la plataforma en la nube no realizará y el operador no tiene incentivos para ofrecer.

Más allá de la traducción de protocolo, el SBC proporciona el perímetro de seguridad que las plataformas en la nube asumen que existe pero no implementan por sí mismas. La protección contra DoS a nivel SIP, las listas de bloqueados dinámicas, la defensa contra escaneo de registros SIP y la prevención de fraude telefónico se ejecutan en el SBC antes de que el tráfico llegue a la aplicación en la nube. Exponer una plataforma de voz en la nube directamente al tráfico SIP del operador sin un SBC es el equivalente en voz a colocar una aplicación web en internet público sin un firewall.

Tres patrones de implementación para SBC en la nube

Las implementaciones de SBC en la nube se dividen en tres patrones arquitectónicos. La elección correcta depende de dónde se ejecutan sus cargas de trabajo de voz, dónde se conectan sus operadores y cuánta infraestructura local planea mantener.

Nube pura

En una implementación de nube pura, el SBC se ejecuta como una máquina virtual junto a la aplicación de voz en el mismo proveedor de nube. Este es el patrón más simple: la instancia del SBC se implementa en AWS, Azure, VMware o KVM/Proxmox, los troncales SIP del operador terminan en la interfaz pública del SBC y la plataforma de voz se conecta al SBC a través de la red interna del proveedor de nube. La latencia entre el SBC y la aplicación es mínima porque ambos residen en el mismo centro de datos o zona de disponibilidad.

La nube pura funciona bien para organizaciones que han migrado completamente a una plataforma de voz en la nube y no tienen equipos de telefonía local restantes. Elimina por completo los appliances de SBC de hardware, reemplazando el gasto de capital con un modelo de suscripción que escala según el conteo real de sesiones.

Multinube

Las implementaciones multinube colocan instancias de SBC en dos o más proveedores de nube o regiones. Un MSP que ofrece Teams Direct Routing multitenant podría ejecutar su SBC principal en Azure para obtener la menor latencia hacia Microsoft 365, con una instancia en espera en AWS para diversidad de operadores y redundancia geográfica. Un operador de centro de contacto que ejecuta Genesys Cloud BYOC podría colocar instancias de SBC tanto en US-East como en EU-West para cumplir con los requisitos de residencia de datos y mantener la capacidad de conmutación por error (failover).

El SBC es particularmente adecuado para entornos multinube porque opera como una función de red autónoma. Cada instancia se conecta a sus operadores locales y puntos finales de plataforma en la nube de forma independiente, con reglas de enrutamiento que pueden dirigir tráfico entre instancias según carga, disponibilidad o políticas. La compatibilidad de ProSBC con AWS, Azure, VMware, KVM/Proxmox y bare metal significa que los mismos patrones de software y configuración se aplican independientemente de qué nube aloja una instancia determinada.

Híbrido: local + nube

El modelo híbrido es el patrón más común en la práctica, porque la mayoría de las organizaciones no migran todas las cargas de trabajo de voz a la nube de una sola vez. Una implementación híbrida típica mantiene un PBX local (Avaya, Cisco o FreeSWITCH) para extensiones internas mientras enruta las llamadas externas a través de un SBC alojado en la nube que se conecta tanto al PBX heredado como a una plataforma UCaaS en la nube. El SBC gestiona la normalización SIP entre el dialecto SIP del PBX heredado y los requisitos de la plataforma en la nube, cifra el tráfico que cruza internet público y proporciona un único punto de administración para las conexiones con operadores que sirven a ambos entornos.

Las implementaciones híbridas también sirven como ruta de migración de lo local a la nube completa. La arquitectura basada en NAP del SBC permite a los operadores migrar grupos de troncales uno a la vez, trasladando las conexiones con operadores del tramo local al tramo en la nube de forma progresiva. En cualquier momento, revertir un solo grupo de troncales es un cambio de enrutamiento, no una re-arquitectura.

Interconexión de operadores para CPaaS y UCaaS

El rol del SBC se hace más visible en el límite de interconexión con el operador para plataformas CPaaS y UCaaS. Estas plataformas abstraen la voz en API y servicios gestionados, pero la abstracción se rompe en el límite con la PSTN donde troncales SIP reales transportan llamadas reales a números telefónicos reales.

UCaaS: Teams, Zoom, RingCentral

Las plataformas UCaaS presentan el patrón de integración con SBC más limpio porque el proveedor de la plataforma define los requisitos SIP de forma explícita. Microsoft Teams requiere TLS con un certificado de una CA de confianza, SRTP para todos los medios, monitoreo de heartbeat mediante SIP OPTIONS y formato específico de encabezados SIP. El SBC termina el troncal SIP del operador en un lado (generalmente UDP sin cifrar) y presenta TLS/SRTP compatible con Teams en el otro. ProSBC es compatible con Microsoft Teams Direct Routing y ha sido implementado exitosamente en entornos de Teams DR en redes de MSP, ISP y empresas.

Para los MSP que atienden múltiples clientes, el SBC permite la entrega de voz Teams multitenant desde una sola instancia. El tenant de Microsoft 365 de cada cliente se conecta a través de un NAP dedicado con su propio FQDN de subdominio, certificado TLS y reglas de enrutamiento, mientras comparte las conexiones subyacentes con operadores y la infraestructura del SBC.

CPaaS: Twilio, Telestax, Cloudoni

La interconexión de operadores para CPaaS funciona de manera diferente porque el SBC se ubica entre la plataforma CPaaS y los propios operadores de la organización en un modelo BYOC. En lugar de usar la telefonía incluida del proveedor CPaaS (y pagar tarifas por minuto a gran escala), la organización aporta sus propios troncales SIP y utiliza el SBC para normalizar el tráfico entre sus operadores y el punto final SIP de la plataforma CPaaS.

Este patrón es cada vez más común entre organizaciones que construyen agentes de voz con IA, marcadores automáticos de salida y sistemas IVR programables. La plataforma CPaaS proporciona la lógica de aplicación, pero el SBC proporciona el enrutamiento de operadores, la seguridad, la firma STIR/SHAKEN y el control de costos. Aircall, por ejemplo, utiliza ProSBC en AWS para normalizar tráfico de proveedores SIP internacionales para más de 50,000 usuarios, aprovechando el motor de manipulación de encabezados SIP del SBC y su API RESTful para gestionar la diversidad de operadores en múltiples países.

BYOC para centros de contacto

Las plataformas de centros de contacto en la nube (Genesys Cloud, Five9, NICE CXone, Talkdesk) admiten modelos BYOC donde el cliente proporciona sus propios troncales SIP a través de un SBC. El SBC gestiona la misma normalización de operadores y traducción de cifrado que en el caso UCaaS, con requisitos adicionales de alta densidad de sesiones, manejo de medios de baja latencia e integración con sistemas de prevención de fraude que evalúan las llamadas durante el establecimiento.

Seguridad en el borde de la voz en la nube

Migrar la voz a la nube no elimina la superficie de ataque; la traslada. El SBC se convierte en el perímetro de seguridad entre internet público (donde llega el tráfico SIP del operador) y el entorno en la nube (donde se ejecutan las aplicaciones de voz). Un tratamiento completo de las capacidades de seguridad del SBC está disponible en la guía dedicada de seguridad del SBC, pero las consideraciones específicas de la nube merecen atención particular.

El puente de cifrado es la función de seguridad más fundamental. Las plataformas en la nube exigen TLS y SRTP, mientras que muchos operadores aún entregan tráfico sobre UDP sin cifrar. El SBC termina SIP/RTP sin cifrar en el lado del operador y re-origina TLS/SRTP cifrado en el lado de la nube. ProSBC negocia TLS 1.3 exclusivamente sin retroceso a versiones anteriores, asegurando que el tramo cifrado cumpla con el estándar más robusto disponible. Los pares que no pueden negociar TLS 1.3 se conectan a través de tramos UDP o TCP, donde el SBC aún proporciona inspección a nivel de señalización y anclaje de medios.

La ocultación de topología adquiere importancia adicional en entornos de nube. Los orquestadores de contenedores, los balanceadores de carga y las capas de red en la nube introducen direcciones IP internas que nunca deben filtrarse en los encabezados SIP que cruzan internet público. La arquitectura B2BUA del SBC reemplaza todas las direcciones internas con la IP pública del propio SBC, haciendo que la infraestructura en la nube sea arquitectónicamente invisible para las partes externas.

La prevención de ataques a nivel SIP protege la aplicación en la nube de amenazas que los firewalls de red no pueden abordar. Los ataques de inundación SIP, el escaneo de registros y las explotaciones de mensajes SIP malformados apuntan a la capa de aplicación. El SBC inspecciona el tráfico SIP a nivel de protocolo, aplicando limitación de tasa por método, por origen y por grupo de troncales, con listas de bloqueados dinámicas que bloquean automáticamente las fuentes que exceden los umbrales configurados.

Alta disponibilidad y conmutación por error entre regiones de nube

La voz tolera mal el tiempo de inactividad. Una aplicación web que devuelve un 503 durante treinta segundos causa inconvenientes; una plataforma de voz que interrumpe llamadas durante treinta segundos causa una disrupción operativa y, para los proveedores de servicio, violaciones de SLA con penalizaciones financieras. La alta disponibilidad en implementaciones de SBC en la nube opera en dos niveles: a nivel de instancia y a nivel de región.

La HA a nivel de instancia utiliza un par 1+1 donde una instancia de SBC en espera monitorea la primaria y asume su dirección IP y sesiones activas si la primaria falla. La HA 1+1 de ProSBC funciona en máquinas virtuales estándar sin requerir redes especializadas de nube, lo que permite implementarla en AWS, Azure, VMware o KVM sin modificaciones. La instancia en espera mantiene sincronización de configuración con la primaria, por lo que la conmutación por error (failover) no requiere intervención manual.

La redundancia a nivel de región protege contra fallas de zona de disponibilidad o región de la nube al colocar instancias de SBC en ubicaciones geográficamente separadas. Los registros DNS SRV del lado del operador o el monitoreo de salud basado en SIP OPTIONS dirigen el tráfico a la instancia disponible. Para organizaciones con requisitos estrictos de tiempo de actividad, las implementaciones activo-activo entre regiones distribuyen el tráfico continuamente, con cada instancia gestionando una porción de la carga de llamadas y absorbiendo el tráfico de la otra durante una falla.

Las implementaciones de SBC en la nube también se benefician de la capa de Monitoring as a Service (MaaS), que proporciona paneles en tiempo real, alertas basadas en umbrales y análisis de tendencias históricas en todas las instancias del SBC, independientemente de dónde estén alojadas. MaaS detecta patrones de degradación (jitter creciente en un troncal específico del operador, anomalías en el conteo de registros, capacidad de sesiones acercándose a los límites) antes de que se conviertan en caídas, dando a los equipos de operaciones tiempo para responder antes de que se necesite la conmutación por error.

Preguntas frecuentes

Conclusión

La voz puede ser la última gran carga de trabajo en migrar a la nube, pero la migración ya está en marcha. Lo que distingue las implementaciones exitosas de voz en la nube de las problemáticas es cómo se gestiona el límite con el operador. El SBC proporciona la traducción de protocolo, el puente de cifrado, la aplicación de seguridad y la alta disponibilidad que las plataformas de voz en la nube requieren pero no implementan de forma nativa.

Ya sea que esté implementando una arquitectura de nube pura en un solo proveedor, abarcando múltiples nubes para redundancia y cumplimiento normativo, o manteniendo un entorno híbrido durante una migración gradual, el SBC opera como el punto de control consistente en cada interconexión con el operador. Su arquitectura B2BUA asegura que cada lado de la conexión reciba exactamente el comportamiento SIP, el cifrado y el enrutamiento que requiere, sin exigir que ninguno de los lados se adapte al otro.

Para las organizaciones que evalúan su arquitectura de voz en la nube, el SBC no es un componente opcional que se agrega después de que surgen los problemas. Es la capa fundacional que hace que la interconexión con operadores, la interoperabilidad multiproveedor y la seguridad de voz funcionen correctamente desde el inicio.