Por qué las pruebas de carga de IA de voz deben seguir la ruta real de la llamada

Si tu plataforma de centro de contacto atiende primero cada llamada y después transfiere a los llamantes a un agente de voz con IA, una prueba de carga que marque directamente a la IA te dice muy poco. Demuestra que la IA puede atender muchas llamadas. No demuestra que tu operador, tu plataforma de control de llamadas, la transferencia al agente y la transferencia de vuelta aguanten en los picos de volumen. La mayoría de los fallos en este tipo de despliegue se producen en las uniones entre sistemas, y esas uniones solo reciben tráfico cuando las llamadas siguen la ruta de producción.

Para el método general (aumento progresivo de la concurrencia, percentiles de latencia, conjuntos de pruebas de regresión), consulta nuestra guía sobre pruebas de carga de agentes de voz. Este artículo trata los despliegues en los que una plataforma UCaaS o CCaaS tiene el control de las llamadas.

¿Por qué una prueba de carga directa por SIP o API no demuestra que el despliegue funcione?

Porque omite todos los tramos por los que pasan tus llamantes. Una prueba directa envía las llamadas directamente al endpoint SIP o a la API del proveedor de IA. Una llamada en producción sigue una ruta más larga: llega desde el operador, entra en tu plataforma de centro de contacto o UCaaS, pasa por tu IVR o lógica de enrutamiento, se transfiere en ciego al punto de entrada de la IA de voz y, después, termina ahí o se transfiere de vuelta a una cola humana.

Cada tramo tiene su propio límite de capacidad, su comportamiento SIP y su responsable de configuración. Una prueba directa no ejercita ninguno de ellos. Tres ejemplos de la documentación de Retell:

• La capacidad se define en más de un sitio. El límite de concurrencia de Retell se aplica por espacio de trabajo (los espacios de trabajo de pago por uso empiezan con 20 llamadas simultáneas). La guía de Five9 de Retell indica que Five9 aplica sus propios límites de capacidad de troncal, y su guía de Avaya recomienda confirmar que el número de troncales SIP administradas cubre las llamadas simultáneas previstas. Una prueba que se salta la plataforma nunca alcanza su límite.
• El método de conexión cambia lo que puede hacer la IA. Retell admite elastic SIP trunking (el método recomendado) y la marcación a una URI SIP. Con el método de URI SIP, la función de transferencia integrada de Retell no está disponible, así que las transferencias y los cuelgues deben gestionarse con tu propia lógica. Una prueba directa nunca revelaría esa carencia.
• Las transferencias dependen del otro extremo. La transferencia en frío de Retell usa SIP INVITE por defecto, o SIP REFER si tu proveedor de telefonía lo admite. Que REFER funcione, y que las cabeceras personalizadas se conserven, depende de tu proveedor, no de la IA.

¿Cómo es la ruta real de la llamada cuando una plataforma de centro de contacto tiene el control de las llamadas?

Es una cadena de cinco tramos, y cada llamada de prueba debería pasar por los cinco.

Aquí importan dos detalles de la documentación de Retell. Con el método de URI SIP, cada llamada necesita primero una solicitud Register Phone Call, y la llamada debe llegar a esa URI en un plazo de 5 minutos o termina con registered_call_timeout, así que tu servicio de registro también tiene que aguantar bajo carga. En el lado de salida, la guía de Genesys Cloud de Retell indica que las llamadas que Genesys transfiere a otro destino eligen una troncal según los planes de numeración y las rutas salientes del Site: configuración de la plataforma a la que una prueba directa nunca llega.

¿Dónde aparecen en los picos de volumen los fallos que solo surgen en la ruta real?

Donde se encuentran dos sistemas, normalmente en cuanto uno de ellos empieza a encolar llamadas. Vigila estos puntos durante el aumento progresivo:

1. Manda el límite de capacidad más ajustado. Si la troncal de tu plataforma admite menos llamadas simultáneas que tu espacio de trabajo de IA, los llamantes se quedan atascados en la plataforma y el panel de la IA parece estar en perfecto estado. Dimensiona juntos el operador, la troncal de la plataforma y el límite de concurrencia de la IA.
2. Colas de entrada en la IA. Cuando las llamadas entrantes alcanzan el límite de concurrencia de Retell, Retell retiene las nuevas llamadas unos 40 segundos. Si no se libera ningún hueco, transfiere al llamante a un fallback_number configurado, o termina la llamada con concurrency_limit_reached si no hay ninguno. Decide de antemano adónde debe ir ese fallback (a menudo, de vuelta a la cola humana de tu plataforma) y comprueba que funciona bajo carga.
3. El tráfico saliente desplaza al entrante. Todas las llamadas de voz de un espacio de trabajo comparten un mismo pool de concurrencia. Si el mismo espacio de trabajo también ejecuta campañas salientes, la concurrencia reservada para llamadas entrantes puede guardar huecos para las llamadas transferidas.
4. Tasa de establecimiento de llamadas. Retell fija las llamadas por segundo por ruta de telefonía, y su documentación indica que el CPS de Custom Telephony escala con tu concurrencia. Una ráfaga de transferencias al comienzo de cada hora puede alcanzar un límite de tasa antes que un límite de concurrencia.
5. Configuración de red y medios. Retell publica varios bloques de IP que hay que añadir a la lista de permitidas (algunos solo se aplican a cierto tráfico de EE. UU.), sus transportes (TCP recomendado, UDP, TLS, mTLS) y sus códecs (PCMU, PCMA, G.722). Una lista de permitidas que solo cubra algunos de esos bloques puede superar una prueba pequeña y fallar con volumen.
6. Cambios SIP a mitad de llamada. Las plataformas pueden enviar re-INVITE para refrescar una sesión, mover los medios o poner una llamada en espera. Retell responde a los re-INVITE dentro del diálogo para refrescos de sesión, reanclaje de medios, cambios de códec, renovación de claves SRTP y puesta en espera o reanudación; confirma que los re-INVITE de tu plataforma se comportan igual con volumen.

¿Cómo se genera tráfico de prueba a través de la ruta real?

Origina las llamadas de prueba fuera de tu red y marca los mismos números públicos que usan tus llamantes. Es la única forma de que todos los tramos soporten carga.

• Elige un generador de llamadas que marque tu número público. Las llamadas por lotes de Retell realizan llamadas salientes desde Retell, y las pruebas de simulación de Retell ejecutan conversaciones basadas en texto, así que ninguna de las dos reproduce una llamada entrante transferida por tu plataforma. Algunos partners de pruebas realizan llamadas reales; Hamming, por ejemplo, describe que sus agentes de voz llaman a los tuyos. Pregunta a cualquier proveedor de pruebas si sus llamadas entran por la red telefónica pública o se conectan directamente al agente.
• Etiqueta cada llamada de prueba. Haz que tu plataforma añada una cabecera SIP personalizada X- (por ejemplo, un ID de ejecución de prueba) en la transferencia. Retell extrae las cabeceras X- entrantes al campo custom_sip_headers de la llamada y a variables dinámicas, para que puedas vincular cada llamada de IA con el registro de la plataforma.
• Aumenta por escalones. Empieza por debajo del pico previsto, sube hasta superarlo y después deja que el tráfico baje y confirma que el sistema vuelve al reposo.
• Convoca a todos los responsables. Deben participar el operador, el administrador de la plataforma y el proveedor de IA de voz. La guía de Five9 de Retell plantea la prueba de integración final como una sesión conjunta.
• Sube los límites antes de la prueba, no durante. Revisa tus límites de concurrencia y CPS de IA en la página Limits (la calculadora integrada sugiere valores a partir del tráfico de tu hora punta) y confirma que la capacidad de la troncal de la plataforma coincide.

¿Qué señales SIP debes vigilar durante la prueba?

Vigila la señalización de cada llamada desde el primer INVITE hasta el BYE final, a ambos lados de la transferencia. Los detalles de llamada de Retell pueden incluir una pestaña Packet Capture con la señalización SIP de la llamada, y su guía de depuración con PCAP explica cómo leerla en Wireshark. Si usas tu propia troncal, la documentación de Retell recomienda capturar en el servidor o gateway que termina el SIP, que normalmente es tu SBC.

Busca:

• Un establecimiento limpio en el tramo de transferencia: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Respuestas de error: 403 (lista de permitidas o permisos), 404 (URI SIP o enrutamiento incorrectos), 408 o 477 (endpoint inaccesible o error de transporte), 486 (ocupado), 503 (servicio no disponible).
• La transferencia de salida: un REFER o un nuevo INVITE, según el método de transferencia, y si tus cabeceras X- se han conservado. La documentación de Retell advierte de que las cabeceras personalizadas pueden eliminarse cuando una transferencia va a un número PSTN en lugar de a un endpoint SIP.
• Quién envió el BYE, y cuándo: cada llamada debería terminar con un BYE de la parte que esperas.

Los eventos de webhook de Retell (call_started, call_ended y los eventos transfer_*) te dan una cronología por llamada para cotejarla con las capturas.

¿Qué debería contar como prueba superada?

Superar la prueba significa que las cifras cuadran en todos los sistemas, no solo que la IA se mantuvo activa. Usa esta lista de comprobación:

• El número de llamadas coincide entre los registros del operador, los informes de la plataforma y el registro de llamadas de la IA durante la ventana de prueba.
• Todas las llamadas de IA terminaron con un motivo de desconexión esperado (user_hangup, agent_hangup, call_transfer), y no hubo motivos concurrency_limit_reached ni error_*.
• Cada transferencia de vuelta a una persona llegó a la cola correcta, con el identificador de llamada y las cabeceras esperados.
• Ninguna respuesta SIP 4xx o 5xx en los tramos de transferencia, salvo las que provocaste a propósito.
• El audio fluyó en ambas direcciones en las llamadas muestreadas.
• La concurrencia máxima se mantuvo por debajo de todos los límites de la cadena, con margen.
• Cuando el tráfico se detuvo, la concurrencia volvió a cero en el lado de la IA y la plataforma no mostró sesiones residuales.

Esta última comprobación merece su propio plan de pruebas, ya que las llamadas que nunca se cierran del todo tras una transferencia pueden consumir concurrencia en los picos. Tratamos el cierre de llamadas en una guía aparte.

¿Qué debes preguntar a tu proveedor de IA de voz antes de la prueba?

Haz preguntas que obliguen al proveedor a mostrar la ruta, no solo la IA:

1. ¿Qué método de conexión recomendáis para nuestra plataforma y qué cambia en las transferencias y los cuelgues?
2. ¿Qué métodos de transferencia SIP admitís (INVITE, REFER) y qué requiere cada uno de nuestra plataforma?
3. ¿Cómo pasamos y leemos cabeceras SIP personalizadas en ambas direcciones?
4. ¿Dónde se configuran vuestros límites de concurrencia y de llamadas por segundo, qué le ocurre a la llamada al alcanzar el límite y podemos aumentarlos para la prueba?
5. ¿Podemos ver la señalización SIP y los motivos de desconexión de cada llamada, y revisará vuestro equipo de telefonía las capturas con nosotros?

La documentación de Retell incluye guías de configuración para Genesys Cloud, Five9, Avaya y Amazon Connect, una guía general de telefonía personalizada y una guía de concurrencia que cubre cada límite. Para las transferencias desde el agente, consulta transferencia de llamadas y cómo funcionan los traspasos de la IA a personas.

Si tu plataforma tiene el control de las llamadas y necesitas un agente de voz con IA que encaje detrás de ella, descubre la plataforma de IA conversacional para empresas de Retell y habla con el equipo para planificar una prueba de carga en tu ruta real de llamada.

Lecturas relacionadas: La prueba de carga del cierre de llamadas, el flujo de trabajo del CRM a la IA de voz y más guías en el centro Retell Learn.