Skip to main content

Llamadas entrantes

Enruta cualquier número —comprado en el marketplace o traído mediante tu propia troncal SIP— a un asistente:
  1. Phone numbers → select number → assign assistant.
  2. Las llamadas entrantes las responde ese asistente, según su modo de saludo (habla primero o espera a quien llama).
  3. La grabación (con gestión de consentimiento si está activada), la transcripción y los eventos de la llamada ocurren automáticamente.
La asignación de número → asistente se resuelve en cada llamada, así que puedes reasignar números en cualquier momento sin tocar el número en sí.

Llamadas salientes

Tres formas de hacer llamadas:
  • Llamada individual desde la interfaz — en la página de un asistente, introduce un número y llama: ideal para hacer pruebas.
  • API / MCP — make_call con assistant_id y to_number, más datos opcionales del lead que el asistente puede usar en la conversación (nombre, campos personalizados). Consulta la referencia de la API.
  • Campaigns — salida masiva sobre una lista de leads con lógica de marcador; consulta Campañas.
Detalles del comportamiento saliente:
  • El asistente saluda solo después de que la persona llamada responde (nunca habla mientras suena el tono).
  • Los resultados sin respuesta se traducen en estados claros: busy, no_answer, failed — la lógica de reintento de las campañas se basa en ellos.
  • Con el greeting mode: user speaks first, el asistente espera al “¿Hola?” de quien llama — notablemente más natural en llamadas en frío.
  • La answering machine detection (AMD), opcional, clasifica quién respondió (humano / buzón de voz / IVR) y puede reproducir un mensaje de buzón de voz configurado; consulta Marcador y cumplimiento.

Indicaciones ante fallos

POST /api/v1/calls devuelve de inmediato la llamada puesta en cola. Consulta GET /api/v1/calls/{id}, usa get_call, o consume call.completed para obtener el resultado final. Las llamadas salientes fallidas incluyen un objeto failure neutro respecto al proveedor:
Los códigos habituales incluyen busy, declined, no_answer, temporarily_unavailable, invalid_destination, authentication_failed, destination_forbidden, trunk_unavailable y no_outbound_trunk. El historial muestra un motivo breve con el código SIP registrado, por ejemplo Conexión de llamada bloqueada · SIP 403. Una conexión bloqueada (caller_blocked) requiere una respuesta explícita; un 403 genérico muestra Llamada no permitida. Se distinguen los conflictos de enrutamiento (routing_conflict) de los bucles confirmados (routing_loop), así como los métodos no admitidos (method_not_allowed), los tiempos de conexión agotados (connection_timeout), las llamadas sin respuesta (no_answer) y las cancelaciones (cancelled_before_answer). Otras respuestas abarcan autenticación, destino, formato de llamada, enrutamiento, seguridad y red telefónica. Los detalles técnicos se pueden desplegar. Un tiempo de espera local sin respuesta SIP no muestra ningún código SIP. Las llamadas existentes utilizan la respuesta registrada cuando está disponible. REST, MCP y los webhooks de llamadas devuelven los mismos motivos breves. retryable es una orientación para tu integración. No modifica los ajustes de reintento de las campañas. Si una transferencia fría o asistida falla mientras la llamada original sigue activa, el registro de eventos de la llamada contiene call_transfer_failed o warm_transfer_failed. Esos eventos usan la misma estructura failure, con operation: cold_transfer o warm_transfer.

Llamadas web

Cualquier asistente también puede recibir llamadas desde el navegador, algo que usan tanto la llamada de prueba integrada como el widget web integrable. Las llamadas web aparecen en el historial de llamadas con la dirección web.
Menú Test del asistente con las opciones Web Call y Call

En el menú Test del asistente, Web Call inicia una prueba de voz en el navegador. Elige Call para introducir el destino de una prueba telefónica saliente.

Resultados de la llamada

Toda llamada —sin importar su dirección— genera: una transcripción, duración y estado, indicaciones de fallo neutrales respecto al proveedor cuando corresponda, métricas de latencia por turno, un registro de eventos (llamadas a herramientas, transferencias, consentimiento, transiciones de nodos), grabación opcional y un webhook call.completed.