El SBC como pasarela de voz IA: arquitectura, enrutamiento y seguridad para voz IA en la PSTN

La voz IA en 2026 se entrega como una pila tecnológica: un motor de conversión de voz a texto (STT) en tiempo real, un orquestador LLM que decide qué decir a continuación y un motor de conversión de texto a voz (TTS) que lo reproduce. Los equipos que implementan voicebots, recepcionistas IA, copilotos de agente y campañas salientes automatizadas pueden construir esa pila con relativa rapidez. Sin embargo, la capa que la mayoría de los equipos omite es la que conecta el clúster de IA con la red telefónica con la que debe comunicarse.

Esa capa es un controlador de borde de sesión (SBC). Un SBC se sitúa entre dos redes SIP, terminando la señalización y los medios en cada lado de forma independiente, y es lo que permite que un clúster de voz IA se comporte como un terminal SIP normal ante un operador y como un operador normal ante el clúster de IA. En este artículo cubrimos lo que el SBC realmente hace frente a una plataforma de voz IA: cómo funcionan el cifrado, el codec, la normalización de encabezados y la ocultación de topología; cómo usar enrutamiento basado en API para consultar a un orquestador qué agente debe responder; cómo se aplica STIR/SHAKEN en llamadas salientes originadas por IA; y por qué la calidad de los medios importa más para un oyente artificial que para uno humano.

Por qué la voz IA necesita un SBC en el borde de la PSTN

El lado del operador y el lado de la IA en una implementación de voz IA discrepan en casi todo lo que importa en un troncal SIP: postura de cifrado, codec, dialecto de encabezados, atestación y accesibilidad IP. El SBC es el dispositivo que les permite discrepar de forma ordenada.

Frontera de cifrado

Un operador PSTN puede entregar SIP sobre UDP con RTP sin cifrar, particularmente en interconexiones heredadas. Una plataforma de voz IA casi siempre espera SIP sobre TLS y SRTP, porque el clúster se ejecuta en una nube pública y la revisión de seguridad para permitir voz en texto plano dentro de una red de inquilinos habría sido rechazada hace tiempo. El SBC termina ambos transportes de forma independiente por tramo y convierte entre ellos de manera transparente. El operador nunca ve las claves del clúster de IA, y el clúster de IA nunca ve el texto plano del operador. Para la mecánica de configuración, consulte la guía de configuración de TLS y SRTP en el SBC y la referencia técnica más detallada sobre SRTP.

Realidades de codec

Las nubes de voz IA varían en lo que aceptan. La mayoría acepta G.711 (PCMU o PCMA) de forma nativa, porque es lo que las pilas SIP de código abierto sobre las que se construyen negocian por defecto. Algunas tienen terminales Opus o G.729, particularmente cuando la plataforma fue diseñada primero para móviles. ProSBC es compatible con G.711 ALAW y ULAW de forma nativa en software y admite Opus, G.729 y AMR-WB mediante transcodificación por hardware. La implicación práctica es directa: si el proveedor de IA acepta G.711, mantenga la llamada en G.711 de extremo a extremo. Cada salto de transcodificación agrega artefactos que los motores STT manejan mal.

Normalización SIP

Las plataformas de voz IA comúnmente se ejecutan sobre FreeSWITCH, Kamailio o Asterisk, y emiten un dialecto SIP que no coincide con el de un operador Tier 1. P-Asserted-Identity, el manejo de From y PAI, los temporizadores de sesión del RFC 4028, los encabezados Diversion y las entradas History-Info, todos necesitan reescritura en la entrada o en la salida. El motor de manipulación de encabezados SIP de ProSBC es configurable por NAP, de modo que las reglas para un grupo de troncales orientado al operador son independientes de las reglas para cada terminal de voicebot. Esa separación es lo que hace posible cambiar de proveedor de voz IA sin tocar la configuración del operador.

Ocultación de topología

Un clúster de IA ejecutándose en una nube pública tiene IP de contenedor privadas, direcciones internas de balanceador de carga y nombres de host de malla de servicios que nunca deberían aparecer en los encabezados Via, Contact o Record-Route visibles para un operador. El SBC reemplaza esas referencias internas con su propia dirección pública, eliminando tanto un riesgo de divulgación de información como las fallas de enrutamiento que ocurren cuando una dirección privada RFC1918 se filtra en una ruta SIP pública.

Arquitectura de referencia: PSTN, SBC, plataforma de voz IA

Recorra el diagrama en ambas direcciones para ver dónde el SBC asume la carga.

Flujo de llamada entrante

Un INVITE del operador llega a la IP pública del SBC. ProSBC valida el origen contra su lista de permitidos, aplica protecciones contra denegación de servicio (DoS) y normaliza el mensaje SIP para que los encabezados que ven los consumidores aguas abajo estén limpios. El motor de enrutamiento entonces ejecuta una consulta HTTP contra el orquestador de agentes con el número de origen, el número de destino, P-Asserted-Identity, el grupo de troncales de origen y cualquier contexto de negocio que el orquestador necesite. La respuesta identifica el siguiente salto, que puede ser un terminal de voicebot específico, una cola en una plataforma de centro de contacto o un agente humano en una PBX de respaldo. El SBC reorigina un nuevo diálogo SIP hacia el destino elegido, esta vez sobre TLS con medios SRTP, presentando la llamada a la IA en el dialecto que espera.

Flujo de llamada saliente

La plataforma de IA realiza una llamada saliente: un recordatorio de cita, una devolución de llamada, un seguimiento iniciado por el agente. El INVITE llega al NAP orientado a la IA de ProSBC. El motor de enrutamiento busca el operador apropiado según el número de destino, aplica cualquier política por inquilino (más sobre multi-inquilino a continuación) y entrega la llamada al servicio de firma STIR/SHAKEN a través de SIP. Una vez que el encabezado Identity está en su lugar, el SBC reorigina hacia el operador con cualquier transporte que ese operador admita.

Bifurcación de medios opcional

Muchas implementaciones de voz IA requieren una segunda copia de los medios para analítica, grabación de cumplimiento o un espejo STT en paralelo. ProSBC admite reproducción y grabación de medios de forma nativa; la bifurcación en tiempo real hacia un destino de streaming externo depende del socio tecnológico. Vale la pena conocer este patrón, porque pedirle al SBC que lo haga de forma limpia suele ser más sencillo que pedirle a la plataforma de IA que haga multicast de sus propios medios.

Enrutamiento basado en API en el momento del INVITE

La capacidad más infrautilizada cuando los equipos colocan una voz IA detrás de un número telefónico es usar el SBC para consultar al orquestador de agentes, en el establecimiento de la llamada, hacia dónde debe ir la llamada. Las tablas de rutas estáticas funcionan para asignaciones predecibles de operador a bot. Fallan cuando la plataforma de bot quiere tomar decisiones de enrutamiento basadas en contexto que el SBC no tiene: identidad del llamante, horario comercial, nivel de atestación, configuración del inquilino, grupo de prueba A/B, o si un agente humano está disponible.

ProSBC expone su motor de enrutamiento a través de una cadena de filtros programable. Un before_filter en una llamada entrante puede emitir una solicitud HTTPS al orquestador con los parámetros de la llamada, esperar hasta un tiempo de espera configurado (normalmente de 500 a 2,500 ms para que los llamantes no experimenten retardo en el establecimiento), y usar la respuesta JSON para elegir el siguiente salto, anular la atestación o adjuntar metadatos que los sistemas aguas abajo consumen. La mecánica, los patrones de redundancia y los modos de falla se cubren en profundidad en la guía de integración de enrutamiento de llamadas con API REST del SBC; la página de solución de integración API del SBC describe la capacidad a nivel de plataforma.

Casos de uso que esto habilita para voz IA

• Enrutamiento VIP a un humano identifica a llamantes de alto valor conocidos a partir de datos del CRM durante el procesamiento del INVITE y los enruta directamente a un agente designado, evitando el bot.
• Enrutamiento de llamadas anómalas envía el tráfico sospechoso (volumen inusual, ANI no coincidente, baja atestación) a un servicio de puntuación de fraude antes de que la llamada llegue al cómputo de IA.
• Enrutamiento por detección de idioma elige un terminal de voicebot en-US, es-MX o fr-FR según la región de origen, el número llamado o una consulta rápida del orquestador contra el historial del llamante.
• Enrutamiento consciente de inquilino dirige el tráfico de cada cliente a su propia configuración de bot en un SBC compartido, con política de codec, atestación y grabación por inquilino.
• Pruebas A/B de versiones de voicebot enruta un porcentaje controlado de tráfico a un modelo candidato y el resto a producción, usando la respuesta del orquestador para registrar en qué grupo cayó cada llamada.

Modos de falla

La consulta de enrutamiento necesita un tiempo de espera explícito y una ruta de respaldo explícita. URL del orquestador primario y secundario, una tabla de rutas estática como respaldo final, y una regla firme de que una respuesta perdida del orquestador nunca bloquee la finalización de la llamada son la línea base. El SBC transporta la llamada; el orquestador toma la decisión. Si el orquestador está caído, el trabajo del SBC es completar la llamada hacia un destino predeterminado razonable, no retener el INVITE en espera.

STIR/SHAKEN para llamadas salientes originadas por IA

Las llamadas salientes a velocidad de máquina son un vector de fraude y un punto de exposición regulatoria. Un bucle de automatización mal configurado puede realizar decenas de miles de llamadas antes de que alguien lo note, y una plataforma de voz IA con un solo inquilino mal comportado puede degradar la atestación de todos los demás que comparten el mismo operador ascendente. La regla de certificado propio de la FCC, vigente desde septiembre de 2025, significa que el proveedor de servicios de voz que opera la plataforma es responsable del nivel de atestación que firma. Eso cambia el cálculo para cualquiera que opere un voicebot saliente.

Cómo el SBC gestiona la firma

ProSBC se integra con TransNexus ClearIP y Neustar a través de SIP tanto para firma como para verificación, que es el patrón implementado en producción para todos los clientes de TelcoBridges que ejecutan STIR/SHAKEN hoy. En una llamada saliente, ProSBC enruta a través de un NAP de firma cuyo service_type está configurado como AUTHENTICATION, recibe el encabezado Identity firmado en una respuesta SIP 302, lo adjunta al INVITE saliente y continúa hacia el operador. El servicio de firma permanece completamente fuera de la ruta de medios. La redundancia se expresa mediante ordenamiento de rutas y Reason Cause Mapping, de modo que una interrupción del servicio de firma nunca bloquea la finalización de la llamada.

Atestación por llamada y controles de fraude

El patrón de atestación correcto para una plataforma de voz IA es por llamada, no por troncal. Una plataforma que mezcla tráfico minorista verificado, tránsito de revendedor y campañas de inquilinos no gestionados necesita que la lógica de enrutamiento establezca la atestación A, B o C según el inquilino de origen y el destino. La arquitectura lo permite porque la cadena de filtros programable que se ejecuta durante el procesamiento del INVITE puede establecer el nivel de atestación como parte de la misma decisión que elige el siguiente salto. La guía de atestación de nivel A cubre los requisitos de KYC para que la atestación de nivel A se sostenga. Para el lado operativo de configurar niveles de atestación por inquilino y campaña en producción, y combinar la atestación con controles de fraude de peaje como límites de CPS por NAP, filtros de destino e integración de puntuación de fraude, consulte la guía de implementación en producción para agentes de voz IA. La página de solución STIR/SHAKEN cubre el contexto más amplio del producto.

La calidad de medios importa más para la IA que para los humanos

Un llamante humano tolera 80 ms de jitter y una ráfaga breve de pérdida de paquetes sin pensarlo. Un motor de conversión de voz a texto lo nota. La tasa de error de palabras del STT aumenta rápidamente con el jitter, la pérdida de paquetes, los artefactos de transcodificación de codec y la cancelación de eco agresiva, y un bot que malinterpreta al llamante responderá de maneras que parecen un fallo de la IA aunque el fallo estuvo en el transporte.

Las métricas que importan

Diferentes partes de la cadena de IA son sensibles a diferentes métricas. El STT es sensible al jitter y la pérdida de paquetes porque ambos producen fonemas caídos o distorsionados. El barge-in es sensible al retardo de ida y vuelta y al retardo post-marcación, porque el bot necesita detectar que el llamante comenzó a hablar y dejar de hablar en aproximadamente 200 ms para que se sienta natural. La reproducción TTS es sensible a la configuración del búfer de jitter en el lado de la IA. ProSBC expone puntuación MOS por llamada, salida CDR, trazas SIP y captura Wireshark en vivo para que los datos existan y permitan correlacionar las quejas de calidad con el tramo de donde provienen. La guía de mejores prácticas de monitoreo VoIP cubre los umbrales de métricas y los flujos de datos del SBC con más detalle.

Opciones de codec para puentes de IA

G.711 nativo es la opción predeterminada más segura cuando el proveedor de IA lo acepta. La transcodificación de Opus en el lado de la IA a G.711 en el lado del operador agrega artefactos con los que los modelos STT no fueron entrenados, y el costo se manifiesta como una caída medible de precisión en producción. Cuando el proveedor de voz IA pública una lista de codec compatibles, trátela como una entrada de enrutamiento en lugar de una suposición. Configure el NAP de cada terminal de IA con la preferencia de codec que realmente necesita y deje que el SBC negocie en consecuencia.

Implementaciones multi-inquilino para plataformas de voz IA

Las plataformas que ejecutan voz IA como servicio se parecen mucho a los operadores CPaaS. El patrón del SBC también es similar. Una instancia de ProSBC puede alojar hasta 1,024 NAP, lo cual es suficiente para varios cientos de inquilinos cuando cada uno obtiene su propio NAP orientado al operador y orientado al bot, más cualquier troncal especializado. Los flujos CDR por inquilino permiten facturar y reportar de forma independiente. La política de atestación por inquilino es importante porque una plataforma de bot SaaS puede tener un inquilino ejecutando tráfico minorista de nivel A y otro haciendo saliente de alto volumen de nivel C desde la misma infraestructura de cómputo; tratarlos de forma idéntica es lo que provoca que el operador mayorista comience a filtrar. El patrón arquitectónico es esencialmente el mismo que se describe en la guía de Teams Direct Routing multi-inquilino, con el clúster de IA sustituyendo al entorno Microsoft 365 del inquilino. La página de solución CPaaS y SBC describe el patrón más amplio. Para la planificación de capacidad, el dimensionamiento por inquilino y el comportamiento de ráfagas que generan las cargas de trabajo de IA, la guía de producción para agentes de voz IA a través de SBC cubre el lado operativo de esta arquitectura.

Seguridad en la frontera de la pasarela de IA

El SBC frente a una plataforma de voz IA está expuesto a internet en el lado del operador y al tráfico que la red de la nube de IA pueda generar en el otro. Ambas superficies importan. La voz IA también introduce amenazas específicas de los modelos generativos, incluyendo suplantación de identificador de llamadas con deepfake, clonación de voz e inyección de prompts; la guía de implementación en producción cubre esos patrones de ataque específicos de la IA y las defensas a nivel del SBC en detalle.

Protecciones del lado del operador

La limitación de tasa consciente de SIP, la lista de bloqueados dinámica con lista gris basada en porcentajes, la protección contra escaneo de registro SIP, y la mitigación integrada de DoS y DDoS son la línea base. La descripción general de seguridad del SBC cubre el enfoque por capas; la guía de prevención de ataques DoS SIP cubre los tipos específicos de inundación y cómo el SBC los detecta antes de que alcancen al clúster de IA.

Protecciones del lado de la IA

Una automatización mal comportada no necesita ser maliciosa para ser costosa. Los límites de llamadas concurrentes por NAP en el grupo de troncales orientado a la IA contienen los bucles desbocados a un máximo predecible. TLS mutuo entre el SBC y la plataforma de IA eleva el nivel de autenticación de conexión, particularmente cuando el clúster de IA está en una cuenta de nube separada u operado por un equipo diferente al del SBC.

Comportamiento observable

La mayoría de los incidentes de voz IA parecen problemas de calidad al principio y resultan ser problemas de configuración tras una inspección más cercana. Las herramientas de CDR, traza SIP y captura en vivo del SBC son donde terminan la mayoría de esas investigaciones. Conectar esos flujos de datos a la misma plataforma de observabilidad que ya alimenta el resto de la infraestructura de voz es el prerrequisito para detectar problemas antes de que los clientes lo hagan.

Preguntas frecuentes

Conclusión

La voz IA no cambia lo que hace un SBC. Eleva la exigencia sobre las funciones que un SBC siempre ha cumplido. El cifrado, la normalización de encabezados, la atestación, el enrutamiento programable y la observabilidad se vuelven más críticos cuando la entidad al otro extremo del troncal SIP es una máquina que gestiona miles de conversaciones al día y la línea regulatoria sobre atestación se está trazando alrededor de su cuenta de proveedor.

La elección arquitectónica está entre tratar al SBC como un traductor pasivo detrás del cual la IA simplemente se ubica, y tratarlo como la capa configurable de transporte y confianza que permite a una plataforma de voz IA comportarse como un terminal de operador real. El segundo enfoque es lo que hace que una implementación se sostenga a volumen de producción.