Un asistente de reservas necesita más que una voz que suene natural. Necesita una forma fiable de escuchar al cliente, actuar sobre la solicitud correcta y explicar el resultado confirmado.
¿Qué hace el runtime conversacional?
El runtime procesa la voz, decide cómo responder y produce audio para el llamante.
Una aplicación puede combinar reconocimiento de voz, un modelo de lenguaje y síntesis de voz, o usar un modelo que procese audio directamente. También gestiona los turnos: cuándo escuchar, cuándo hablar y qué pasa cuando el llamante interrumpe.
Las herramientas de negocio dan a la conversación un resultado útil. Una herramienta de citas puede comprobar disponibilidad y solicitar una reserva. La aplicación debe distinguir una reserva confirmada de un timeout o un resultado desconocido antes de que el agente hable.
Una plataforma gestionada puede proporcionar algunas de estas piezas. Telnyx AI Assistants expone configuración de modelo, voz y herramientas. Las herramientas integradas de Vapi incluyen acciones usadas durante una conversación. Esos ajustes del runtime son dependencias separadas al cambiar de proveedor de telefonía.
¿Cómo llega el agente a la red telefónica?
Un runtime de agente compatible con SIP se conecta a través del trunk de un proveedor de telefonía, con una ruta de medios que transporta el audio.
SIP establece y modifica la sesión. El runtime también debe enviar y recibir medios; un intercambio de señalización exitoso no demuestra que escuche al llamante.
Para llamadas entrantes, un número telefónico dirige al llamante al endpoint de la aplicación. Para llamadas salientes, la aplicación usa una identidad de llamante permitida y un destino al que la conexión pueda llegar. La disponibilidad de un número, la presentación del llamante y el comportamiento de la red receptora son asuntos separados.
Cambiar el trunk no copia los prompts, voces, herramientas ni fuentes de conocimiento del agente. Conserva esos componentes en el runtime que mantengas, o migra cada uno de forma explícita.
¿Qué hace que la conversación funcione con interrupciones?
El runtime debe manejar a un llamante que habla encima de un prompt, cambia de dirección o da una respuesta ambigua.
Prueba nombres, fechas y números a través de la ruta de audio telefónico real. Incluye ruido de fondo, herramientas de negocio lentas y una acción cuyo resultado sea incierto. La aplicación debe comprobar una operación posiblemente completada antes de reintentarla.
La transferencia a una persona también debe tener un resultado claro. El agente debe saber a dónde transferir la conversación y qué decir si ese destino no está disponible. La aplicación conectada o el sistema telefónico de la empresa (PBX), que dirige las llamadas a personas o equipos de trabajo, determina cómo funcionan las transferencias y las conferencias. Verifica ese funcionamiento en todo el recorrido de la llamada.
¿Qué debo medir?
Mide por separado la conectividad telefónica, el comportamiento conversacional y la finalización de la acción de negocio.
El registro de llamada muestra el resultado telefónico. El audio y las transcripciones ayudan a revisar lo que se escuchó y se dijo. El sistema de reservas, pagos o casos confirma si la acción solicitada ocurrió.
Una prueba basada solo en transcripciones no puede determinar la calidad de audio ni el comportamiento ante interrupciones. Una llamada contestada no puede determinar una interacción exitosa con el cliente. Mantén visibles en la revisión las grabaciones faltantes, las transcripciones fallidas y los resultados inciertos de herramientas.
¿Cómo conecto una aplicación de voz con IA a Bird?
Conecta tu aplicación de voz con IA a través de un trunk SIP. Configura inbound_enabled en true para las llamadas que llegan a tu agente. Habilita outbound_enabled para las llamadas que realiza. Ambas direcciones empiezan deshabilitadas, así que un trunk nuevo rechaza llamadas hasta que habilites la dirección que necesitas.
Las actualizaciones del trunk requieren voice_management con nivel de escritura.
Para la entrega entrante, el sip_uri del gateway contiene el host de tu runtime y un puerto opcional, sin nombre de usuario. El destination_format se convierte en la parte antes de @ en la dirección SIP entregada. El +{number} predeterminado pasa el número marcado tal cual. Un valor fijo dirige todos los números entrantes a una sola dirección del runtime.
El priority del gateway determina el orden de failover: un gateway en 0 se intenta antes que uno en 1. Luego apuntas un número retenido con capacidad de entrada al trunk en Enrutamiento entrante.
Para llamadas salientes, tu runtime se conecta al domain devuelto por el trunk. Con autenticación por clave API, allowed_api_key_ids lista las claves permitidas; cada una necesita voice con nivel de escritura. Tu runtime usa bird como nombre de usuario SIP y el secreto de la clave seleccionada como contraseña. Actualizar la lista de claves permitidas la reemplaza por completo, así que conserva las claves que otros clientes aún usen.
Las llamadas salientes también requieren un identificador de llamante verificado y un país de destino habilitado y disponible.
Tu runtime es dueño de las acciones de negocio y la transferencia a un humano. Las herramientas MCP alojadas de Bird gestionan recursos del espacio de trabajo; no ejecutan el ciclo de voz y razonamiento en tiempo real.
En resumen
El runtime es dueño de la conversación.
Voz, razonamiento, herramientas y gestión de turnos pertenecen a la aplicación o plataforma que ejecuta el agente.
La conexión telefónica transporta la llamada.
Números, señalización SIP, medios e identidad del llamante forman la conexión con el teléfono del cliente.
Prueba la interacción completa.
Audio, interrupciones, resultados inciertos de herramientas y transferencia a un humano necesitan pruebas en la ruta de llamada real.
Un sistema de negocio confirma su propio resultado.
Una confirmación hablada o un resumen generado no demuestra que una reserva u otra acción haya tenido éxito.