VoIP e IA: agentes de voz con IA a través del SBC

Los agentes de voz con IA han pasado de los videos de demostración a los números telefónicos en producción. Los recepcionistas con IA atienden llamadas para consultorios dentales, los marcadores de salida de Vapi, Retell y Bland contactan a miles de consumidores por hora, y los centros de contacto enrutan el primer tramo de cada llamada de cliente a través de un pipeline de speech-to-text y modelo de lenguaje antes de que un humano hable. El clúster de voz con IA es la parte del stack que recibe la atención del marketing. El controlador de borde de sesión (SBC) es la parte que determina si algo de eso realmente funciona en la PSTN.

Este artículo cubre lo que cambia cuando el terminal al otro lado de su troncal SIP es un modelo de lenguaje en lugar de un humano, y las decisiones prácticas de configuración que afectan la latencia, la atestación, la exposición al fraude y la planificación de capacidad. Está escrito para operadores de infraestructura de voz que evalúan cómo llevar agentes de IA a producción, no para equipos de producto de IA que eligen un proveedor de voicebot. Para la arquitectura de referencia, que muestra cómo el SBC conecta la PSTN con un clúster de voz con IA, y cómo se ven el cifrado, la negociación de códec, la normalización SIP y la ocultación de topología a nivel de componente, consulte El SBC como gateway de voz para IA.

Cómo los agentes de voz con IA cambian el patrón de tráfico

Un centro de contacto tradicional tiene una curva bastante estable. Las llamadas llegan durante el día, los agentes inician sesión por turnos, los conteos de sesiones simultáneas se mueven dentro de una banda predecible. Los agentes de voz con IA introducen varios patrones de tráfico que la planificación de capacidad de centros de contacto no cubre de forma natural, y todos llegan primero al SBC.

Marcación de salida en ráfagas

Una campaña de salida con IA puede disparar varios cientos de llamadas por segundo desde un arranque en frío, mantener un pico de decenas de miles de sesiones simultáneas durante una hora, y luego caer a cero. El marcador no se autorregula como lo hace una sala llena de humanos. Dimensionar el SBC contra el promedio diario es el modo de falla aquí; el pico de ráfaga es lo que determina si sus grupos de troncales SIP, la capacidad del NAP y los límites de CPS se sostienen. El límite de CPS por NAP configurado contra cada operador es generalmente la restricción que falla primero en producción, y debe configurarse antes del lanzamiento.

Entrada siempre activa

Un recepcionista con IA atiende cada llamada a toda hora, sin cola fuera de horario ni desbordamiento a buzón de voz. El heartbeat SIP OPTIONS del SBC, la salud de registro y la validez del certificado deben mantenerse sin ventana de mantenimiento, y la misma higiene de almacén de confianza que aplica a una implementación de Teams Direct Routing aplica a cualquier terminal TLS al que se conecte un bot.

Expresiones cortas, llamadas largas

Los agentes de IA hablan en turnos cortos y frecuentes. El flujo de medios consiste en muchas ráfagas pequeñas de RTP separadas por silencio, con la detección de actividad de voz activándose frecuentemente. El comportamiento del buffer de jitter ajustado para conversación humana interactúa negativamente con este patrón, especialmente cuando el SBC también está transcodificando entre códecs. Use el perfil de jitter y códec por NAP del SBC para coincidir con lo que la plataforma de IA realmente emite, y verifique con captura de paquetes antes de ir a producción. Adivinar en esta capa es la causa más común de barge-in recortado.

El presupuesto de latencia para una llamada de IA conversacional

La IA conversacional se siente natural cuando el tiempo de respuesta de extremo a extremo se mantiene por debajo de aproximadamente 800 ms. Pasado ese punto, el llamante comienza a preguntar “¿sigues ahí?” o habla encima del bot. Pasados los 1.5 segundos, la llamada suena rota. El presupuesto de latencia se construye a partir de varias etapas, y el SBC es responsable de dos de ellas.

A dónde van los milisegundos

Un viaje de ida y vuelta típico se divide aproximadamente así: 50 a 150 ms de transporte de red del llamante al clúster de IA, 150 a 350 ms de ASR para producir una transcripción utilizable, 150 a 800 ms de inferencia del modelo de lenguaje, 200 a 600 ms de síntesis TTS, y 50 a 150 ms de vuelta al llamante. El SBC contribuye a la primera y última etapa más cualquier transcodificación que realice en cada tramo.

Lo que el SBC controla en ese presupuesto

Tres configuraciones del SBC importan más. Elección de códec decide si el SBC decodifica y recodifica cada paquete RTP (transcodificación Opus a G.711 por hardware) o pasa el flujo sin modificar (G.711 en ambos tramos); la transcodificación por hardware agrega aproximadamente 20 ms por tramo y el pass-through agrega unos pocos. Profundidad del buffer de jitter intercambia latencia por tolerancia a la pérdida de paquetes, y las llamadas de IA requieren el buffer más superficial que aún sobreviva el jitter real de su operador, que generalmente es menor que el valor predeterminado. Anclaje de medios versus pass-through decide si el SBC puede bifurcar audio para grabación (anclado) o reduce el salto a costa de renunciar a la grabación durante la llamada (pass-through).

Lo que el SBC no puede corregir es la plataforma de IA en sí. Si un bot se siente lento y el SBC está configurado correctamente, el problema está más arriba. Mida el ASR-to-first-token y TTS-to-first-audio en las propias métricas de la plataforma antes de culpar a la red.

Selección de códec en el límite IA-PSTN

La incompatibilidad de códec es el problema de producción más común en nuevas implementaciones de voz con IA. El operador ofrece G.711 o G.729. La plataforma de IA prefiere Opus, a veces acepta L16 de banda ancha, y puede degradar silenciosamente a G.711 si se le solicita. El SBC se ubica en el medio y decide qué se negocia en cada lado.

Lo que requiere el lado PSTN

El tráfico PSTN entrante en Norteamérica llega abrumadoramente como G.711 PCMU o PCMA; algunos proveedores de troncales SIP ofrecen G.729 para ahorrar ancho de banda. ProSBC maneja G.711 nativamente por software. La transcodificación de Opus, G.729 y AMR requiere DSP por hardware a través de la línea de productos Ttrans actualmente; la transcodificación por software para códecs adicionales está en el roadmap para fines de 2026. Construya el plan de implementación alrededor de esa restricción en lugar de lo que está en un roadmap futuro. La referencia de arquitectura cubre dónde encaja la negociación de códec en el flujo general de llamada SBC a IA.

Lo que requiere el lado IA

La mayoría de las plataformas comerciales de voz con IA aceptan G.711 directamente en un tramo SIP y manejan el sobremuestreo internamente a su tasa de muestreo preferida. Las plataformas basadas en WebRTC esperan Opus y DTLS-SRTP por defecto, pero la mayoría también exponen un terminal SIP que acepta G.711. El patrón práctico es terminar el operador en G.711 con SDES-SRTP, terminar la IA en G.711 con TLS/SRTP, y dejar que el SBC maneje TLS y SRTP de forma independiente en cada tramo. La transcodificación solo es necesaria cuando una plataforma de IA específica rechaza G.711 o cuando los requisitos de calidad de audio empujan hacia Opus de extremo a extremo.

La cuestión del DTMF

Los IVR con IA que solicitan entrada por teclado dependen de que el DTMF sobreviva el cambio de códec. RFC 4733 (anteriormente RFC 2833) envía DTMF como eventos telefónicos fuera de banda dentro del flujo RTP en lugar de como tonos de audio dentro de la banda. Si la negociación SDP del SBC elimina el tipo de payload de evento telefónico durante la oferta/respuesta de códec, el bot deja de escuchar “presione 1.” Confirme en una llamada de prueba antes del lanzamiento que el payload de evento telefónico se negocia de extremo a extremo y que la plataforma de IA está configurada para escucharlo.

Enrutamiento programable: consultando al orquestador a dónde va la llamada

Las implementaciones de voz con IA rara vez usan tablas de enrutamiento estáticas. Qué agente atiende una llamada dada depende del número marcado, la campaña, la hora del día, la detección de idioma en la primera expresión, el historial del llamante con la marca, y cada vez más, un orquestador de IA que decide en tiempo real si enrutar la llamada a un bot, escalar a un humano o transferir a un bot diferente especializado en el tema. El SBC necesita una forma de hacer esa consulta sin reconstruir la tabla de enrutamiento en cada cambio.

El patrón de consulta HTTP

La integración de enrutamiento de llamadas por API REST de ProSBC maneja esto directamente. Cuando llega un INVITE, el script de enrutamiento emite una consulta HTTP al orquestador con el número llamante, el número marcado, el identificador del NAP y cualquier otro parámetro de llamada relevante. El orquestador devuelve una respuesta JSON especificando el NAP de destino, reescrituras opcionales de encabezados y prioridad de enrutamiento. Todo el intercambio ocurre en la fase de señalización antes de la negociación de medios, por lo que no agrega nada a la latencia de audio.

Lo que esto permite para la voz con IA

Un solo SBC puede atender una docena de campañas de agentes de IA, cada una con su propia lógica de enrutamiento, sin cambios de configuración estáticos. Las nuevas campañas se convierten en nuevas entradas en la base de datos del orquestador en lugar de nuevos NAP en ProSBC. La conmutación por error de un bot a un humano ocurre en el orquestador sin requerir que el SBC recargue. Las pruebas A/B de dos modelos de voz se convierten en una regla de enrutamiento, no en un cambio de implementación. La referencia de arquitectura cataloga patrones de enrutamiento adicionales, incluyendo enrutamiento VIP a un humano, enrutamiento de llamadas anómalas a través de un servicio de calificación de fraude, y enrutamiento por detección de idioma, con el flujo de solicitud-respuesta para cada uno.

Límites que definir

Mantenga el timeout de la consulta al orquestador ajustado (500 a 1500 ms) y defina una ruta de contingencia explícita cuando la consulta falle. La contingencia debe aterrizar en un lugar seguro: un IVR genérico, una cola humana predeterminada o un tratamiento de ocupado, dependiendo del caso de uso. Dejar que las llamadas queden en espera mientras se espera una respuesta lenta del orquestador es el peor modo de falla aquí. ProSBC permite definir URL primaria y secundaria para la consulta HTTP para que el propio orquestador pueda implementarse de forma redundante.

Fraude y confianza en el borde de voz con IA

Los modelos generativos de voz introducen patrones de ataque en los que la capa del SBC históricamente no había necesitado pensar. Algunos son problemas reciclados de fraude en telecomunicaciones con una nueva cara, otros son genuinamente nuevos, y el SBC es el punto de control adecuado para la mayoría de ellos.

Deepfake de identificador de llamadas y clonación de voz

Un atacante que clona la voz de un CEO y usa una llamada firmada con PASSporT sintetizado contra un equipo de finanzas tiene un pretexto más convincente que cualquier campaña de vishing anterior a la IA. La defensa es la misma que para cualquier suplantación de identificador de llamadas: atestación STIR/SHAKEN en la capa del SBC, combinada con socios de calificación de fraude que detectan llamadas de alto riesgo antes de que suenen. La integración de producción STIR/SHAKEN de ProSBC utiliza redirección basada en SIP hacia TransNexus ClearIP o Neustar, donde el STI-AS actúa como servidor de redirección SIP y devuelve un 302 con el encabezado Identity en la ruta exitosa. El lado de terminación recibe una señal clara sobre cuánto respalda el originador al número llamante, que es la única respuesta honesta a un deepfake en la capa del operador.

Salida originada por IA y atestación

A los reguladores les importa cómo se atestan las llamadas de salida originadas por IA. Una llamada realizada por un marcador con IA en nombre de un cliente final no verificado no debería llevar atestación de nivel A; eso es una representación errónea que pone en riesgo tanto la reputación como la exposición ante la FCC. El motor de enrutamiento programable de ProSBC establece el nivel de atestación por llamada, por campaña o por NAP, de modo que un solo SBC que maneja tráfico para múltiples inquilinos de IA puede firmar las llamadas de cada inquilino al nivel apropiado según el estado de verificación de ese inquilino. El patrón de enrutamiento por nivel de atestación cubre esto en profundidad.

Inyección de prompt y abuso específico de IA

Los agentes de voz con IA tienen una superficie de ataque única: un llamante puede pronunciar instrucciones que el modelo de lenguaje interpreta como comandos del sistema. El SBC no resuelve la inyección de prompt directamente, pero sí controla qué llamadas llegan al bot en primer lugar. Las listas de bloqueados dinámicas, la protección contra escaneo de registros y los límites de CPS por NAP reducen el tráfico de sondeo que la capa de IA tiene que ver. Los mismos controles aplican al fraude telefónico específico de IA, donde un marcador secuestrado puede generar grandes volúmenes de llamadas fraudulentas internacionales; los filtros de destino por NAP, los bloqueos de prefijos de tarifa premium y la integración de calificación de fraude con TransNexus, SecureLogix o YouMail son las defensas estándar.

Dónde aterrizan los agentes de voz con IA en el SBC

Tres formas de implementación representan casi todo el tráfico de voz con IA en producción. Cada una tiene diferentes implicaciones para el SBC.

Recepcionista con IA para un cliente SMB o MSP

El caso más simple: un número entrante, un agente de IA, un inquilino. Un solo NAP en el lado del operador, un solo NAP en el lado de la IA, manejo básico de SIP y códec. Para un MSP que ofrece agentes de voz con IA por inquilino, el multiplicador es la cantidad de clientes, no la complejidad por cliente. Una sola instancia de ProSBC con 1,024 NAP disponibles puede hospedar cientos de recepcionistas con IA en paralelo, cada uno con su propio enrutamiento, grabación y tratamiento STIR/SHAKEN.

Centro de contacto con IA en primera línea

El bot maneja los primeros 30 segundos de cada llamada, identifica al llamante, clasifica la solicitud y la resuelve o la transfiere a un humano. Este es el patrón de comunicaciones en la nube aplicado a agentes de IA. El rol del SBC es el mismo que para un centro de contacto tradicional, más la consulta al orquestador en el momento del INVITE para decidir cola de bot o humano según el número marcado, la hora o el historial previo del llamante. Comparado con una implementación de Enrutamiento directo de Teams, el flujo de IA de centro de contacto se beneficia más del anclaje de medios para grabación y menos del media bypass.

Marcador de salida con IA

La forma más exigente. Un marcador impulsado por campañas genera los patrones de ráfaga descritos anteriormente, y cada llamada debe llevar el nivel de atestación correcto, el identificador de llamadas y el manejo de exclusión voluntaria. El motor de enrutamiento programable de ProSBC establece los tres por llamada, y el límite de CPS por NAP protege al operador de ser saturado. Si la plataforma de IA está hospedada por un tercero, el tramo del marcador al SBC frecuentemente usa WebRTC o SIP/TLS sobre Internet público, con TLS/SRTP terminando en el SBC. La planificación de capacidad apunta al pico de ráfaga de la campaña.

Grabación, cumplimiento y consentimiento de dos partes

Los flujos de llamadas asistidos por IA deben lidiar con las reglas de consentimiento en las jurisdicciones donde operan. Los estados con consentimiento de dos partes requieren que se informe al llamante que la llamada está siendo grabada o procesada por un sistema de IA, y el SBC es frecuentemente la capa que demuestra que la divulgación ocurrió. El patrón práctico es anclar los medios en el SBC, bifurcar el audio (o solo el tramo entrante) hacia un destino de grabación seguro, y registrar la marca de tiempo del aviso de consentimiento y la respuesta del llamante. Si una llamada es cuestionada posteriormente, la grabación muestra que la divulgación se realizó y el llamante continuó.

La redacción de PII y PCI reside en la capa de la plataforma de IA o en un servicio de redacción separado, pero el SBC controla si el audio original llega a ellos en primer lugar. El modo pass-through ahorra carga de medios del SBC pero renuncia al rastro de auditoría. Para implementaciones hospedadas en un SBC de software ejecutándose en AWS, Azure o KVM, el destino de la bifurcación de grabación puede ser un endpoint de almacenamiento en la nube o un servicio de grabación dedicado; al SBC no le importa dónde aterrizan los bytes, solo que la bifurcación esté configurada.

Preguntas frecuentes

Conclusión

Los agentes de voz con IA funcionan en producción cuando la capa entre la plataforma de IA y la red telefónica se comporta como una pieza seria de infraestructura de telecomunicaciones en lugar de una demo SIP. El SBC es lo que convierte al clúster de IA en algo en lo que un operador confiará, atestará y enrutará. También es lo que protege a la capa de IA de las realidades más complejas del tráfico PSTN: variación de códec, deriva de atestación, sondeo de fraude y ráfagas que ningún clúster de inferencia de IA quiere absorber directamente.

El SBC adecuado para voz con IA no es un “SBC de IA.” Es un SBC programable, multiinquilino, con una API REST limpia, control de códec y enrutamiento por NAP, integración STIR/SHAKEN que se ajusta a patrones de producción reales, y suficiente margen de capacidad para el comportamiento de ráfaga que generan las cargas de trabajo de IA. La pregunta de infraestructura para una implementación de voz con IA es la misma pregunta para cualquier implementación seria de voz, solo con tolerancias más ajustadas en latencia, atestación y confianza.