Controlador de borde de sesión (SBC): guía completa para evaluar un SBC de software

Un controlador de borde de sesión (SBC) es el elemento de red que se ubica en el límite entre dos redes de voz IP, gobernando cada sesión SIP que lo atraviesa: terminando la señalización y los medios en un lado, aplicando políticas de seguridad y protocolos, y reoriginando una nueva sesión en el otro.

Esta guía está dirigida a ingenieros y tomadores de decisiones que evalúan sus opciones de SBC. Cubre las capacidades esenciales que un SBC de producción debe ofrecer, por qué la industria está migrando de los equipos de hardware a los controladores de borde de sesión basados en software, los modelos de implementación disponibles, qué segmentos de compradores se benefician más y las características que deben priorizarse al comparar proveedores.

¿Qué es un controlador de borde de sesión?

En esencia, un controlador de borde de sesión es un agente de usuario back-to-back (B2BUA) implementado en el límite entre dos redes SIP. Termina completamente cada sesión entrante, aplica políticas de seguridad e interoperabilidad, y reorigina una nueva sesión en el otro lado, otorgando al operador control independiente sobre la señalización, los medios y el cifrado en cada tramo. Para una explicación completa de los fundamentos del SBC, cómo funciona la arquitectura B2BUA y en qué se diferencian los SBC de los firewalls y los proxies SIP, consulte ¿Qué es un controlador de borde de sesión (SBC)?

Las secciones siguientes se enfocan en lo que importa cuando se evalúa un SBC para producción: las cinco áreas de capacidad esenciales, las ventajas y desventajas operativas entre hardware y software, los modelos de implementación disponibles actualmente y las características que separan a una plataforma de nivel operador de un dispositivo SIP de borde básico.

¿Qué hace un controlador de borde de sesión?

Las funciones que realiza un SBC se dividen en cinco categorías. Al evaluar proveedores, estas son las áreas donde la calidad de implementación varía más y donde las diferencias tienen el mayor impacto en la confiabilidad en producción.

Seguridad y control de acceso

La seguridad es la razón más común por la que las organizaciones implementan un SBC. En el borde de la red, el SBC actúa como el punto único de entrada para todo el tráfico SIP, lo que lo convierte en el lugar natural para aplicar políticas de seguridad.

Protección contra DoS y DDoS detecta y bloquea ataques volumétricos (inundaciones SIP, tormentas de registro e intentos de denegación de servicio distribuido) antes de que lleguen a la infraestructura de procesamiento de llamadas detrás del SBC. Listas de bloqueados dinámicas permiten que el SBC bloquee automáticamente direcciones IP o números de llamada que exhiben comportamiento sospechoso, mientras que las listas de control de acceso estáticas definen qué fuentes tienen permitido enviar tráfico en primer lugar. Protección contra escaneo de registros SIP identifica y bloquea intentos de registro por fuerza bruta, un precursor común del fraude telefónico. Ocultación de topología asegura que las direcciones IP internas nunca se filtren en los encabezados SIP externos, evitando que los atacantes mapeen su red.

Cuando el SBC opera como B2BUA, también proporciona una demarcación natural para el cifrado. Puede terminar la señalización SIP cifrada con TLS en un tramo y reoriginarla en el otro, con un certificado diferente, un conjunto de cifrado diferente, o sin cifrado en absoluto, dependiendo de lo que requiera cada lado. Lo mismo aplica para los medios: el SBC actúa como puente entre SRTP y RTP sin cifrar de forma transparente, de modo que un operador que entrega medios sin cifrar puede conectarse a una plataforma que exige cifrado sin que ninguno de los lados cambie su configuración.

Interoperabilidad SIP y normalización

No hay dos implementaciones SIP idénticas. Los operadores, proveedores de PBX y plataformas de colaboración interpretan el RFC de SIP de forma diferente, agregan encabezados propietarios y manejan los casos extremos a su manera. El SBC resuelve estas incompatibilidades mediante la manipulación de encabezados SIP, inspeccionando y reescribiendo encabezados por grupo de troncales para que cada lado reciba SIP que entienda.

Las tareas comunes de normalización incluyen corregir los encabezados Via y Contact que contienen direcciones IP privadas, remapear encabezados P-Asserted-Identity (PAI) para la presentación del identificador de llamadas, eliminar extensiones propietarias que un lado no reconoce y ajustar parámetros de temporizador de sesión (RFC 4028) que de otro modo causarían desconexiones prematuras de llamadas.

Manejo de medios y transcodificación

El SBC controla el plano de medios además de la señalización. Ancla los medios a través de su propia dirección IP, asegurando que los paquetes RTP atraviesen el SBC en lugar de fluir directamente entre terminales, lo cual es esencial para el puente de cifrado, la interceptación legal, la grabación de llamadas y el monitoreo de calidad.

Cuando dos terminales usan códecs incompatibles, el SBC realiza transcodificación de medios para convertir entre ellos. Para implementaciones IP a IP, esto puede significar convertir entre códecs de banda estrecha (G.711, G.729) y códecs de banda ancha (AMR-WB, Opus) para que los terminales móviles y WebRTC puedan interoperar con la infraestructura PSTN tradicional.

Enrutamiento de llamadas y aplicación de políticas

Más allá del enrutamiento SIP básico, un SBC proporciona un motor de enrutamiento programable que toma decisiones basadas en el número llamante, el número llamado, la hora del día, la utilización del grupo de troncales y consultas de datos externos. El control de admisión de llamadas previene la sobresuscripción limitando el número de sesiones simultáneas por grupo de troncales o en todo el sistema. El enrutamiento de menor costo dirige las llamadas por la ruta disponible más económica, con conmutación por error automática a rutas alternativas cuando un operador no está disponible.

Los SBC avanzados exponen una capa de API que permite a los operadores integrar lógica externa (consultas CRM, bases de datos de portabilidad numérica, motores de calificación de fraude y sistemas de facturación) directamente en la decisión de enrutamiento de llamadas, ejecutada durante la fase de señalización para que no haya impacto en la calidad de los medios.

Cumplimiento normativo

Las telecomunicaciones son una industria regulada, y el SBC es frecuentemente el punto de aplicación para los requisitos de cumplimiento. La autenticación de identificador de llamadas STIR/SHAKEN, exigida por la FCC bajo la TRACED Act, requiere que los proveedores de servicios de voz firmen criptográficamente las llamadas salientes y verifiquen las entrantes. El SBC se integra con servicios externos de firma para adjuntar o validar tokens de identidad digital en el encabezado SIP INVITE.

Las capacidades de detección de fraude permiten que el SBC inspeccione patrones de llamadas en tiempo real, califique las llamadas por riesgo y bloquee el tráfico fraudulento antes de que genere cargos. La generación de registros de detalle de llamada (CDR) proporciona el rastro de facturación y auditoría que los reguladores y los equipos financieros requieren.

SBC de hardware vs. SBC de software: el cambio en la industria

Durante la mayor parte de la historia del SBC, el dispositivo fue un equipo de hardware propietario: una caja dedicada de AudioCodes, Oracle (Acme Packet), Ribbon Communications o Cisco, con chips DSP dedicados para transcodificación y un límite de capacidad fijo determinado por el hardware adquirido.

Ese modelo está cambiando. El software de controlador de borde de sesión que se ejecuta en máquinas virtuales estándar, instancias de nube y servidores commodity ahora ofrece las mismas capacidades de seguridad, interoperabilidad y enrutamiento de nivel operador, sin el gasto de capital, los ciclos de renovación de hardware y la dependencia del proveedor que conllevan los equipos dedicados.

Por qué los proveedores de servicios están migrando a SBC de software

La migración del hardware a los controladores de borde de sesión basados en software está impulsada por cinco realidades operativas.

Gasto de capital versus gasto operativo es el impulsor más inmediato. Un SBC de hardware requiere una gran compra inicial, un contrato de mantenimiento y una renovación de hardware cada cinco a siete años. Un SBC de software se ejecuta en infraestructura que ya posee o alquila, con precios por suscripción que escalan según el uso real. Para los proveedores de servicios que gestionan decenas o cientos de clientes, la diferencia en el costo total de propiedad es significativa.

Velocidad de implementación importa en mercados competitivos. Un controlador de borde de sesión virtual puede implementarse en VMware, KVM/Proxmox, AWS o Azure en minutos, no en las semanas o meses requeridos para adquirir, enviar, montar en rack y configurar un equipo de hardware. Para los MSP que incorporan nuevos clientes o los ISP que responden a una solicitud de interconexión con un operador, esta velocidad se traduce directamente en ingresos.

Escalabilidad elástica elimina las conjeturas de planificación de capacidad. Un SBC en la nube escala la capacidad de sesiones hacia arriba o hacia abajo sin cambiar hardware. Cuando el tráfico crece, se aumenta el nivel de licencia. Cuando un proyecto termina, se reduce. Los equipos de hardware no ofrecen nada de esta flexibilidad; se paga por la capacidad máxima se use o no.

Independencia de plataforma elimina la dependencia de un único proveedor que ha definido al mercado de SBC durante décadas. Un SBC de software se ejecuta en el hipervisor, proveedor de nube o servidor bare metal que el operador elija, y migrar entre plataformas no requiere reemplazar hardware.

Actualizaciones continuas cierran la brecha entre ciclos de lanzamiento. Los SBC de software reciben actualizaciones de funcionalidad y parches de seguridad a través de pipelines estándar de implementación de software, no a través de actualizaciones de firmware vinculadas al hardware que requieren ventanas de mantenimiento y a veces acceso físico.

Cuándo el hardware aún tiene sentido

Los SBC de hardware conservan ventajas en escenarios específicos. Las implementaciones que requieren transcodificación de muy alta densidad (miles de conversiones simultáneas de códec entre AMR-WB y G.711, por ejemplo) aún se benefician del hardware DSP dedicado. Algunos entornos regulatorios exigen equipos físicos en las instalaciones. Y las organizaciones con inversiones existentes en hardware pueden optar por operar sus equipos actuales hasta el fin de vida útil antes de migrar a software.

La ruta práctica para la mayoría de los proveedores de servicios es un enfoque híbrido: SBC de software para nuevas implementaciones, instancias de nube y cargas de trabajo elásticas, con recursos de transcodificación por hardware agregados solo donde la conversión de códec a escala lo demande.

Cómo funciona un controlador de borde de sesión en una red VoIP

Un SBC opera en el borde de una red de voz, ubicándose entre la infraestructura interna de confianza y las redes externas no confiables. En un entorno de proveedor de servicios, esto típicamente significa una o más instancias del SBC posicionadas entre la plataforma de conmutación central del proveedor y el mundo exterior: interconexiones con operadores en un lado, terminales de suscriptores en el otro.

El SBC de interconexión

Un SBC de interconexión gestiona la interconexión entre dos proveedores de servicios o entre un proveedor de servicios y un operador PSTN. Cada llamada que entra o sale de la red atraviesa este SBC. Aplica seguridad a nivel de troncal (TLS, SRTP, control de acceso), normaliza SIP entre los sistemas de ambos proveedores, genera CDR para la facturación entre operadores y aplica control de admisión de llamadas para evitar que cualquier par individual consuma más capacidad de la contratada.

El SBC de acceso

Un SBC de acceso se ubica entre los terminales de suscriptores (teléfonos IP, PBX, plataformas de centro de contacto, herramientas de colaboración) y la infraestructura central del proveedor de servicios. Maneja el recorrido de NAT para terminales detrás de firewalls de clientes, aplica límites de sesión por suscriptor, establece puentes de cifrado entre la red del suscriptor y la central del proveedor, y proporciona una capa de protección contra equipos de clientes comprometidos o mal configurados.

Flujo de llamada VoIP a través del SBC

Cuando una llamada llega al SBC, la secuencia de procesamiento sigue una ruta predecible. El SBC primero valida la fuente contra su lista de control de acceso y verifica patrones de DoS. Luego inspecciona el SIP INVITE, aplicando las reglas de manipulación de encabezados para el grupo de troncales entrante. Si la verificación STIR/SHAKEN está configurada, el SBC envía el encabezado Identity al servicio de verificación. El motor de enrutamiento determina la ruta de salida basándose en reglas configuradas, consultas de datos externos o lógica impulsada por API. El SBC construye un nuevo SIP INVITE para el tramo de salida, aplicando las reglas de manipulación de encabezados para el grupo de troncales de destino, negociando códecs y estableciendo cifrado si es requerido. Una vez que la parte llamada responde, el SBC ancla los medios a través de su propia dirección, actuando como puente entre cualquier formato de cifrado y códec que utilice cada lado.

Durante toda la llamada, el SBC monitorea la calidad (puntuaciones MOS, jitter, pérdida de paquetes), genera estadísticas en tiempo real y escribe un CDR cuando la sesión finaliza.

Modelos de implementación de SBC

El software moderno de controlador de borde de sesión es compatible con múltiples modelos de implementación, cada uno adecuado para diferentes requisitos operativos.

SBC virtual en instalaciones propias

El SBC se ejecuta como una máquina virtual en el propio hipervisor del operador (VMware ESXi, KVM o Proxmox). Este modelo le da al operador control total sobre el hardware anfitrión, la configuración de red y la ruta de datos. Es el modelo preferido para proveedores de servicios con infraestructura existente de centro de datos, para implementaciones en entornos regulados que requieren procesamiento de datos en las instalaciones, y para organizaciones que necesitan integrar el SBC con equipos TDM en la misma instalación.

SBC en la nube

Un controlador de borde de sesión nativo en la nube se ejecuta en AWS, Microsoft Azure u otro proveedor de nube pública. Este modelo elimina por completo la necesidad de un centro de datos y permite implementaciones geo-redundantes en múltiples regiones de nube para máxima resiliencia. Los SBC en la nube son la opción natural para proveedores que atienden bases de clientes distribuidas, para integraciones CPaaS donde la plataforma de voz ya reside en la nube, y para organizaciones que desean evitar cualquier compromiso con hardware.

SBC en bare metal

Para los operadores que desean máximo rendimiento sin una capa de hipervisor, el SBC puede ejecutarse directamente en servidores commodity x86. Este modelo extrae la mayor densidad posible de sesiones de un hardware dado y es común en implementaciones de interconexión de alta capacidad donde cada sesión cuenta.

Implementaciones híbridas

Muchos proveedores de servicios combinan modelos: un SBC en las instalaciones para interconexiones locales con operadores e integración TDM, junto con instancias de SBC en la nube para sitios remotos, recuperación ante desastres o capacidad elástica de desbordamiento. La misma imagen de software y sintaxis de configuración en todos los modelos de implementación hace que esto sea práctico.

¿Quién necesita un controlador de borde de sesión?

Cualquier organización que opere una red de voz basada en SIP en el límite entre dos dominios de confianza necesita un SBC. Ya sea que implemente un SBC empresarial para proteger un entorno de voz corporativo o un SBC de nivel operador para gestionar decenas de miles de sesiones en una red de proveedor de servicios, los requisitos fundamentales son los mismos: seguridad, interoperabilidad y aplicación de políticas. En la práctica, cuatro segmentos de compradores representan la gran mayoría de las implementaciones de SBC.

Proveedores de servicios de Internet (ISP)

Los ISP que ofrecen servicios de voz necesitan un SBC para interconectarse con operadores upstream, proteger su infraestructura de conmutación de amenazas externas, cumplir con STIR/SHAKEN y gestionar la normalización SIP requerida al agregar tráfico de múltiples pares operadores. Para los ISP que reemplazan plataformas heredadas (implementaciones de OpenSIPs que han crecido más allá de su alcance original, sistemas MetaSwitch/Perimeter que carecen de mitigación DDoS, o hardware en fin de vida de Ribbon u Oracle), un SBC de software proporciona una ruta de reemplazo moderna y rentable.

Proveedores de servicios gestionados (MSP)

Los MSP que ofrecen voz hospedada, UCaaS o Enrutamiento directo de Microsoft Teams (Direct Routing) a clientes empresariales necesitan un SBC como punto central de gestión de tráfico y seguridad. Una sola implementación de SBC puede atender a decenas o cientos de clientes finales, con grupos de troncales, reglas de enrutamiento y políticas de seguridad por inquilino. El SBC también permite al MSP ofrecer servicios de valor agregado (grabación de llamadas, protección contra fraude, cumplimiento normativo) que diferencian su oferta de la reventa de voz commodity.

Proveedores de plataformas UCaaS y CCaaS

Los proveedores de software que construyen plataformas de comunicaciones unificadas o centros de contacto necesitan un SBC para manejar la capa de troncales SIP, seguridad e interoperabilidad, permitiendo que sus equipos de desarrollo se concentren en la lógica de aplicación en lugar de la integración con operadores. En arquitecturas CPaaS y BYOC, donde la plataforma se integra con Twilio, RingCentral, Genesys o similares, el SBC normaliza el tráfico de múltiples operadores y proporciona el perímetro de seguridad que la plataforma en sí no incluye.

Centros de contacto

Las operaciones de centros de contacto, ya sea en las instalaciones o migrando a plataformas en la nube como Genesys Cloud, Five9 o NICE, implementan SBC para proteger su infraestructura de voz, gestionar altos volúmenes de sesiones simultáneas, asegurar la calidad de servicio para llamadas orientadas al cliente y mantener el cumplimiento con los requisitos de grabación y auditoría. Para implementaciones BYOC (Bring Your Own Carrier) de centros de contacto en la nube, el SBC es el puente entre los operadores elegidos por la organización y la plataforma en la nube.

Características clave de un SBC que debe evaluar

Al comparar proveedores de SBC, estas son las capacidades que afectan más directamente la confiabilidad en producción, el costo operativo y la flexibilidad a largo plazo.

Arquitectura B2BUA

Una implementación completa de B2BUA, donde el SBC termina y reorigina tanto la señalización como los medios en cada tramo, es innegociable para implementaciones en producción. Un proxy SIP no puede realizar manipulación de encabezados, cifrado independiente por tramo, ocultación de topología ni anclaje de medios. Si el SBC que está evaluando opera como proxy en lugar de B2BUA, no puede ofrecer las funciones de seguridad e interoperabilidad descritas en esta guía.

Profundidad de seguridad

Vaya más allá de las afirmaciones tipo checklist. Evalúe si el SBC proporciona mitigación de DoS/DDoS en tiempo real (no solo limitación de velocidad), listas de bloqueados dinámicas que reaccionan automáticamente a patrones de tráfico, protección contra escaneo de registros SIP y listas de control de acceso granulares a nivel de grupo de troncales. La compatibilidad con cifrado debe incluir TLS para señalización y SRTP para medios, con la capacidad de actuar como puente entre tramos cifrados y no cifrados de forma transparente.

Motor de manipulación de encabezados SIP

La calidad del motor de manipulación de encabezados del SBC determina qué tan efectivamente maneja entornos multi-proveedor. Evalúe si las reglas pueden aplicarse por grupo de troncales, si el motor admite coincidencia de patrones basada en regex, y si puede manejar transformaciones complejas como la inserción condicional de encabezados basada en parámetros de llamada.

API y programabilidad

Un SBC moderno debe exponer una API REST para gestión de configuración, monitoreo de estado y recuperación de CDR. Más allá de eso, evalúe si el SBC permite enrutamiento programable: la capacidad de ejecutar lógica personalizada (consultas HTTP externas, consultas a bases de datos, calificación de fraude) durante la fase de señalización de cada llamada. Esta capacidad transforma al SBC de un dispositivo estático de aplicación de políticas en un borde programable que se adapta a los requisitos del negocio en tiempo real.

Flexibilidad de implementación

Confirme que el SBC se ejecuta en las plataformas que su infraestructura utiliza hoy y podría utilizar mañana: VMware, KVM/Proxmox, AWS, Azure y bare metal. Un SBC de software que lo ata a un único hipervisor o proveedor de nube introduce el mismo tipo de dependencia de proveedor que imponen los equipos de hardware.

Alta disponibilidad

Para infraestructura de voz en producción, la alta disponibilidad 1+1 activo/standby es un requisito básico. Evalúe cómo funciona la conmutación por error, qué estado se preserva durante la conmutación y si la alta disponibilidad está disponible en todos los tamaños de implementación, no solo para licencias de nivel empresarial.

Modelo de precios

Los SBC de hardware conllevan grandes costos de capital iniciales más mantenimiento anual. Los SBC de software típicamente utilizan precios por suscripción (por sesión, por servidor o por mes). Evalúe el costo total de propiedad a tres a cinco años, incluyendo contratos de soporte, licenciamiento de alta disponibilidad y funciones adicionales. Precios transparentes y publicados son una señal fuerte de que el proveedor confía en su propuesta de valor.

Integración STIR/SHAKEN

Con las reglas de la FCC que ahora requieren que los proveedores firmen llamadas con sus propios certificados STIR/SHAKEN, evalúe cómo el SBC se integra con los servicios de firma. Un modelo de integración abierto, donde el SBC funciona con cualquier servicio de firma de terceros (TransNexus, Neustar, entre otros) en lugar de atarlo a un socio elegido por el proveedor, brinda la flexibilidad de cambiar de proveedor si los precios o las capacidades cambian.

Capacidad	SBC de hardware	SBC de software
Velocidad de implementación	Semanas a meses	Minutos a horas
Escalabilidad elástica	Fija por hardware	Escalado bajo demanda
Modelo de precios	Gran CAPEX + mantenimiento	Suscripción OPEX
Elección de plataforma	Solo hardware del proveedor	VMware, KVM, AWS, Azure, bare metal
Alta disponibilidad a pequeña escala	Frecuentemente solo nivel empresarial	Disponible en todos los niveles
Transcodificación por hardware	DSP integrado	DSP externo o software (depende del códec)
Ciclo de actualización	Firmware + ventanas de mantenimiento	Implementación de software estándar

Preguntas frecuentes

¿Qué es un controlador de borde de sesión en términos simples?

Un controlador de borde de sesión es un dispositivo o software que se ubica en el borde de una red de voz y controla cada llamada que cruza el límite: asegurando el tráfico, traduciendo entre implementaciones SIP, cifrando medios y aplicando políticas de enrutamiento. Para una introducción detallada, consulte ¿Qué es un controlador de borde de sesión (SBC)?

¿Cuál es la diferencia entre un SBC y un firewall?

Un firewall opera en la capa de red: filtra paquetes basándose en direcciones IP, puertos y protocolos. Un SBC opera en la capa de aplicación: entiende la señalización SIP y los medios RTP, puede inspeccionar y modificar el contenido de las sesiones de voz, aplicar políticas específicas por llamada y actuar como puente entre diferentes estándares de cifrado. Un firewall no puede realizar normalización SIP, transcodificación de medios, ocultación de topología ni control de admisión de llamadas. En redes de voz en producción, ambos son necesarios: el firewall para seguridad general de red, el SBC para seguridad e interoperabilidad específicas de voz.

¿Necesito un SBC para Microsoft Teams?

Sí, si utiliza Enrutamiento directo (Direct Routing) para conectar Teams a sus propias troncales SIP. Microsoft requiere un SBC certificado o compatible que admita TLS 1.2 para señalización, SRTP para medios, configuración basada en FQDN y heartbeats SIP OPTIONS. El SBC maneja la traducción de protocolos entre el SIP de su operador y el dialecto SIP de Teams, el puente de cifrado entre RTP del operador y SRTP de Teams, y la normalización de encabezados que Teams requiere. Sin un SBC, el Enrutamiento directo no funciona.

¿Cuál es la diferencia entre un SBC de hardware y un SBC de software?

Un SBC de hardware es un equipo propietario con capacidad fija y chips DSP dedicados. Un SBC de software se ejecuta en máquinas virtuales, instancias de nube o servidores commodity, ofreciendo precios por suscripción, escalabilidad elástica y flexibilidad de implementación. Ambos proporcionan las mismas funciones esenciales del SBC: seguridad, interoperabilidad, enrutamiento y cumplimiento. La elección depende de su modelo de infraestructura, preferencia de presupuesto (CAPEX vs. OPEX) y si necesita transcodificación acelerada por hardware a gran escala.

¿Cuántas sesiones puede manejar un SBC de software?

Los SBC de software de nivel operador modernos pueden manejar decenas de miles de sesiones simultáneas en una sola instancia de servidor. La capacidad real depende de los recursos de CPU y memoria del servidor, si la transcodificación está activa y la complejidad de la lógica de enrutamiento aplicada por llamada. Para implementaciones que requieren más capacidad, múltiples instancias de SBC pueden implementarse detrás de un balanceador de carga o en una configuración de clúster.

¿Es necesario un SBC para el cumplimiento de STIR/SHAKEN?

La FCC requiere que los proveedores de servicios de voz firmen las llamadas salientes y verifiquen las entrantes usando el marco STIR/SHAKEN. El SBC es el punto de aplicación más común para este requisito porque ya procesa cada SIP INVITE en el borde de la red. El SBC se integra con un servicio externo de firma para adjuntar tokens de identidad criptográficos a las llamadas salientes y verificar tokens en las llamadas entrantes. Los proveedores ahora deben usar sus propios certificados STIR/SHAKEN para la firma, en lugar de depender del certificado de un tercero.

Lecturas adicionales

Para explorar cómo un SBC de software transforma las arquitecturas de comunicaciones en la nube, desde la escalabilidad elástica y la alta disponibilidad geo-redundante hasta el media bypass y la integración CPaaS, lea nuestra guía detallada sobre SBC para comunicaciones en la nube.

Para comprender cómo el Enrutamiento directo de Microsoft Teams (Direct Routing) conecta Teams a la PSTN a través de un SBC, incluyendo los requisitos de TLS, SRTP y normalización SIP que lo hacen funcionar, lea nuestro recorrido detallado sobre ¿Qué es Teams Direct Routing?.

Implemente un SBC de software con ProSBC

ProSBC es un controlador de borde de sesión de software de nivel operador diseñado para proveedores de servicios. Ofrece la arquitectura completa B2BUA, motor de manipulación de encabezados SIP, protección contra DoS/DDoS, listas de bloqueados dinámicas y capacidades de enrutamiento programable discutidas a lo largo de esta guía, ejecutándose en VMware, KVM/Proxmox, AWS, Azure o bare metal con precios por suscripción desde $1.40 por sesión por año.

ProSBC es compatible con Enrutamiento directo de Microsoft Teams (Direct Routing), se integra con servicios de firma STIR/SHAKEN incluyendo TransNexus ClearIP, y expone una API REST y scripts de enrutamiento basados en Ruby para lógica de llamadas personalizada. La alta disponibilidad (1+1 activo/standby) está disponible en todos los tamaños de implementación, y el ProSBC Lab, una licencia permanente y gratuita de 3 sesiones que le permite probar el conjunto completo de funcionalidades en su propio entorno antes de comprometerse.

Para los operadores que prefieren no gestionar el SBC por sí mismos, el ProSBC Managed Service proporciona una implementación completamente gestionada con HA 1+1, soporte 24/7 y configuración de extremo a extremo, hospedada en la plataforma de su elección o por TelcoBridges.