Voice

Cos'è un’API vocale?

Un’API vocale consente a un'applicazione di configurare, controllare o ispezionare le telefonate attraverso un'interfaccia software documentata.

Un callback, un menu telefonico e un assistente vocale usano parti diverse di una piattaforma di chiamata.

Cosa può controllare un’API vocale?

Un’API vocale può esporre configurazione, controllo delle chiamate e reportistica, con le operazioni supportate definite dal provider.

La configurazione copre trunk, identità del chiamante, destinazioni e instradamento dei numeri. Il controllo delle chiamate copre il comportamento all'interno di una conversazione, come prompt o input da tastiera. La reportistica restituisce lo stato della chiamata, la durata e gli altri esiti registrati.

I provider esprimono il controllo delle chiamate in modi diversi. TwiML di Twilio, ad esempio, descrive le azioni tramite istruzioni restituite a Twilio. Migrare un'applicazione significa quindi mapparne il comportamento e le aspettative sui callback, non solo sostituire un hostname.

Un metodo che legge una chiamata non è un'operazione che ne avvia una.

Come funzionano insieme un’API e SIP?

Un’API applicativa può configurare o controllare un servizio mentre SIP stabilisce la sessione telefonica sottostante.

SIP, il protocollo di segnalazione delle chiamate, crea, modifica e termina sessioni. Negozia come si connettono i partecipanti. RTP trasporta media in tempo reale come l'audio.

I percorsi possono fallire indipendentemente. Una chiamata può squillare mentre un'impostazione dei media o un percorso di rete impedisce a un partecipante di sentire l'altro. Testa l'audio in entrambe le direzioni oltre allo squillo e al riaggancio.

Un PBX, il centralino aziendale che instrada le chiamate, può mantenere la propria gestione delle chiamate usando i trunk SIP di un provider. Un runtime conversazionale può usare una connessione simile fornendo autonomamente strumenti vocali e di business.

Cosa posso leggere su una chiamata?

Un registro di chiamata identifica il tentativo e ne riporta lo stato osservato. I campi disponibili dipendono dall'operazione e dalla fase della chiamata.

  • Connessione: se la chiamata è stata ammessa, ha squillato e ha ricevuto una risposta.
  • Media: se i partecipanti potevano sentirsi e interagire tra loro.
  • Esito di business: se l'appuntamento, il callback o il compito di assistenza previsto è stato completato.

Una telefonata con risposta può raggiungere una persona, la segreteria telefonica o un altro sistema automatico. Il registro di chiamata da solo non può dimostrare che un cliente abbia completato un compito.

Gli eventi aiutano la tua applicazione a reagire ai cambiamenti. Gestisci i duplicati e le consegne in ritardo, poi riconcilia gli aggiornamenti mancanti o incerti con lo stato registrato dal provider.

Come costruisco tutto questo con Bird?

Configuri le chiamate in uscita con un trunk SIP, un caller ID verificato e un paese di destinazione abilitato.

Le modifiche alla configurazione richiedono voice_management a livello di scrittura.

Sul trunk, outbound_enabled deve essere true. Il suo domain è l'indirizzo a cui si connette il client SIP. L'autenticazione tramite API-key elenca la tua chiave in allowed_api_key_ids; la chiave richiede voice a livello di scrittura. L'aggiornamento di quell'elenco sostituisce tutte le voci, quindi conserva le chiavi ancora in uso da altri client.

Il tuo caller ID richiede status: verified, che conferma che il tuo spazio di lavoro ha completato la chiamata di verifica. Il suo phone_number contiene il numero internazionale, incluso il + iniziale.

Il paese di destinazione richiede sia enabled: true sia status: available. Abilitare un paese non rende chiamabile una destinazione non supportata.

Il telefono browser richiede anche session_credentials_enabled: true sul trunk e MD5 nella sua lista digest_algorithms.

Dopo una chiamata, controlli status, rejection_reason e sip_response_code. Le operazioni di elenco dei segmenti e di lettura di un segmento restituiscono questi campi. Queste operazioni riportano i tentativi. La tua applicazione SIP li avvia.

Per un menu telefonico, configuri prompt e ramificazioni da tastiera nell'applicazione connessa. Un runtime vocale AI fornisce voce, ragionamento e strumenti di business per una conversazione.

In breve

  1. Le API vocali espongono operazioni diverse.

    Configurazione, controllo delle chiamate e registri delle chiamate sono interfacce diverse. Un'operazione di lettura non implica la possibilità di effettuare una chiamata.

  2. Segnalazione e audio hanno percorsi separati.

    SIP stabilisce e modifica la sessione. I media trasportano ciò che i partecipanti sentono, quindi una segnalazione riuscita da sola non dimostra che l'audio funzioni.

  3. Una chiamata con risposta non dimostra che l’attività sia completata.

    Una chiamata con risposta può raggiungere la segreteria telefonica o un altro sistema. L'applicazione che gestisce il compito conferma se è stato completato.

Mettilo in pratica.

Prosegui con la documentazione, le guide e gli esempi per questo argomento. Le risorse sono in inglese.

Ottieni un brief di implementazione

Costruisci sulla stessa rete.

Una chiave API di test è subito tua. L'accesso alla produzione si sblocca quando aggiungi un metodo di pagamento e verifichi un mittente.

La tua prossima idea.
Pronta a partire.