Un callback, un menú telefónico y un asistente de voz usan partes diferentes de una plataforma de telefonía.
¿Qué puede controlar una API de voz?
Una API de voz puede exponer configuración, control de llamadas y reportes, con las operaciones soportadas definidas por el proveedor.
La configuración abarca troncales, identidades de llamante, destinos y enrutamiento de números. El control de llamadas abarca el comportamiento dentro de una conversación, como indicaciones o entrada por teclado. Los reportes devuelven el estado de la llamada, su duración y otros resultados registrados.
Los proveedores expresan el control de llamadas de formas distintas. TwiML de Twilio, por ejemplo, describe acciones mediante instrucciones devueltas a Twilio. Migrar una aplicación implica mapear su comportamiento y las expectativas de sus callbacks, no solo reemplazar un hostname.
Un método que lee una llamada no es una operación que la inicia.
¿Cómo funcionan juntos una API y SIP?
Una API de aplicación puede configurar o controlar un servicio mientras SIP establece la sesión telefónica por debajo.
SIP, el protocolo de señalización de llamadas, crea, modifica y termina sesiones. Negocia cómo se conectan los participantes. RTP transporta medios en tiempo real como audio.
Las rutas pueden fallar de forma independiente. Una llamada puede sonar mientras un ajuste de medios o una ruta de red impide que un participante escuche al otro. Prueba el audio en ambas direcciones, además del timbrado y el colgado.
Un PBX, el sistema telefónico empresarial que enruta llamadas, puede conservar su gestión de llamadas mientras usa troncales SIP de un proveedor. Un runtime conversacional puede usar una conexión similar y proporcionar él mismo herramientas de voz y negocio.
¿Qué puedo consultar sobre una llamada?
Un registro de llamada identifica el intento e informa su estado observado. Los campos disponibles dependen de la operación y de la etapa de la llamada.
- Conexión: si la llamada fue admitida, sonó y recibió una respuesta.
- Medios: si los participantes pudieron escucharse e interactuar entre sí.
- Resultado de negocio: si la cita, el callback o la tarea de soporte prevista se completó.
Una llamada telefónica contestada puede llegar a una persona, al buzón de voz o a otro sistema automatizado. El registro de llamada por sí solo no puede demostrar que un cliente completó una tarea.
Los eventos ayudan a tu aplicación a reaccionar ante cambios. Gestiona duplicados y entregas tardías, y luego concilia actualizaciones faltantes o inciertas contra el estado registrado del proveedor.
¿Cómo construyo esto con Bird?
Configuras llamadas salientes con una troncal SIP, un caller ID verificado y un país de destino habilitado.
Los cambios de configuración requieren voice_management con nivel de escritura.
En la troncal, outbound_enabled debe ser true. Su domain es la dirección a la que se conecta tu cliente SIP. La autenticación por clave API registra tu clave en allowed_api_key_ids; la clave necesita voice con nivel de escritura. Actualizar esa lista reemplaza todas las entradas, así que conserva las claves que otros clientes aún usen.
Tu caller ID necesita status: verified, lo que confirma que tu espacio de trabajo completó su llamada de verificación. Su phone_number contiene el número internacional, incluido el + inicial.
El país de destino necesita tanto enabled: true como status: available. Habilitar un país no hace que un destino no soportado sea alcanzable.
El teléfono del navegador también necesita session_credentials_enabled: true en la troncal y MD5 en su lista digest_algorithms.
Después de una llamada, consultas status, rejection_reason y sip_response_code. Las operaciones de lista de tramos y lectura de un tramo devuelven esos campos. Estas operaciones informan sobre los intentos. Tu aplicación SIP los inicia.
Para un menú telefónico, configuras indicaciones y ramas de teclado en la aplicación conectada. Un runtime de voz con IA proporciona voz, razonamiento y herramientas de negocio para una conversación.
En resumen
Las API de voz exponen operaciones diferentes.
Configuración, control de llamadas y registros de llamadas son interfaces distintas. Una operación de lectura no implica la capacidad de realizar una llamada.
Señalización y audio tienen rutas separadas.
SIP establece y modifica la sesión. Los medios transportan lo que los participantes escuchan, así que una señalización exitosa por sí sola no demuestra que el audio funcione.
Una llamada contestada no demuestra que la tarea se haya completado.
Una llamada contestada puede llegar al buzón de voz o a otro sistema. La aplicación que posee la tarea confirma si se completó.