Conoscenza dell'architettura JTAPI e del flusso di chiamate in UCCX

Introduzione

Questo documento descrive le funzionalità di base di JTAPI, la sua architettura e il flusso di chiamate per quanto riguarda UCCX.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti strumenti e funzionalità:

• JTAPI - API di telefonia Java
• API - Interfaccia di programmazione delle applicazioni
• UCCX - Unified Contact Center Express
• CUCM - Cisco Unified Communications Manager
• CTI - Integrazione con la telefonia informatica

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Configurazione di Cisco Unified Communications Manager (CUCM)
• Configurazione di Unified Contact Center Express (UCCX)

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software:

• UCCX versione 12.5.1.1002-481
• CUCM versione 12.5.1.1900-146

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Questo documento descrive l'architettura JTAPI, il flusso di chiamate, l'attivazione dei debug e la raccolta dei log.

Panoramica di JTAPI

Cisco Unified JTAPI è uno standard di interfaccia di programmazione sviluppato da Sun Microsystems per l'utilizzo con applicazioni di telefonia informatica basate su Java. Cisco JTAPI implementa la specifica Sun JTAPI 1.2 con estensioni Cisco aggiuntive. È necessario utilizzare Cisco JTAPI per sviluppare applicazioni che:

• Controlla e osserva i telefoni di Cisco Unified Communications Manager.

• Instradare le chiamate utilizzando le porte CTI (Computer-Telephony Integration) e i punti di instradamento (dispositivi virtuali).

JTAPI e UCCX

Cisco Unified JTAPI viene utilizzato in un contact center per monitorare lo stato dei dispositivi e per emettere istruzioni di routing per inviare le chiamate al posto giusto al momento giusto. Inoltre, JTAPI viene utilizzato per avviare e interrompere la registrazione delle istruzioni durante il recupero delle statistiche delle chiamate per l'analisi e per le chiamate a schermo nelle applicazioni CRM, lo scripting automatico e il controllo delle chiamate remote.

Architettura JTAPI

Cisco Unified JTAPI, utilizzata in un ambiente aziendale, combina disponibilità, posizione e preferenze dell'utente in un ambiente personalizzato per il routing basato sulla presenza.

Ecco le applicazioni di JTAPI:

• JTAPI può monitorare o ricevere notifiche relative a due o più combinazioni di telefono e linea.
• Le applicazioni per contact center utilizzano il modello di chiamata completa per JTAPI.
• JTAPI offre le funzionalità seguenti:
  • Controllo delle chiamate
  • Controllo supporti
  • Negoziazione media

Modello JTAPI Observer

Nel diagramma seguente viene illustrato il modello Provider-Observer su cui JTAPI opera.

Osservatori

Interfacce observer

Il JTAPI si basa sull'idea dell'osservatore. Da osservatore, si riferisce all'idea di colui che osserva gli eventi. Potete avere più osservatori posizionati su cose diverse all'interno del sistema. JTAPI utilizza degli osservatori per conoscere le modifiche dello stato degli oggetti.

Ad esempio, è possibile inserire osservatori nelle linee, nei telefoni, nel terminale, negli indirizzi e così via, nonché informarli sui cambiamenti dello stato.

Modello provider JTAPI

Il diagramma seguente spiega il modello del provider su cui JTAPI opera:

Modello provider JTAPIModello provider

Il provider JTAPI è una connessione dall'applicazione a Gestione chiamate o Gestione CTI. I provider vengono utilizzati per collegare osservatori agli oggetti. È inoltre possibile collegare un observer a un provider. I provider vengono utilizzati per ricevere notifiche relative alle azioni eseguite sugli oggetti. È inoltre possibile assumere il controllo dei dispositivi a cui è collegato l'osservatore (dal fornitore che ha collegato l'osservatore).

Utente JTAPI

Gli screenshot successivi sono tratti da CUCM (a sinistra) e UCCX (a destra) che spiegano l'utente dell'applicazione JTAPI.

• Quando si avvia un'applicazione e si desidera stabilire una connessione con il gestore CTI, viene aperto un provider.
• L'apertura di un provider consente di monitorare le azioni eseguite su dispositivi, terminali e così via.
• L'implementazione in CUCM avviene tramite un utente di applicazione.
• L'utente viene creato e le credenziali vengono fornite in modo che possa prima eseguire l'autenticazione tramite CTI a CUCM.
• Pertanto, l'utente dell'applicazione JTAPI creata in CUCM è il provider.
• Oltre al semplice monitoraggio, è necessario verificare che i dispositivi siano inclusi in Dispositivi associati per assicurarsi di poterli controllare.

Handle P1 e P2

P1 e P2 sono gli handle del provider. Queste funzionalità diventano importanti quando si aprono più provider dalla stessa applicazione. Da UCCX è possibile creare 2 provider, uno dei quali controlla le porte CTI e i punti di instradamento, l'altro che controlla i telefoni agente chiamati provider RM-JTAPI. In qualità di UCCX, viene creato il provider che controlla le porte CTI e i punti di instradamento, ovvero il provider JTAPI P1. L'altro provider creato dopo P1 è il provider P2 o il provider RmCm che gestisce i dispositivi agente.

Se viene visualizzato P1 nuovo evento chiamata, si sa che si tratta di un evento chiamata da una porta CTI o da un punto di instradamento CTI. Se viene visualizzato P2 nuovo evento chiamata, si sa che si tratta di un evento chiamata dal telefono effettivo. Si creano un utente RM-JTAPI e un utente JTAPI sul lato CCX, ma sul lato CUCM, si vedono 2 utenti JTAPI creati. Questo perché ogni nodo CCX ottiene il proprio utente JTAPI, ma condividono l'unico utente RM-JTAPI. Quando si crea un trigger su UCCX, questo viene aggiunto a entrambi gli utenti JTAPI. Entrambi i nodi aprono un provider separatamente. Pertanto, qualsiasi azione eseguita sul punto di instradamento viene notificata su entrambi i nodi CCX.

A parte questo, il nodo secondario si trova lì e continua ad informare che è ancora il nodo secondario. Ogni nodo dispone di un gruppo distinto di porte CTI. Le porte CTI del nodo 1 sono controllate da jtapi_1. Le porte CTI del nodo 2 sono controllate da jtapi_2.

Quando la chiamata arriva al punto di instradamento CTI, entrambi i nodi CCX ricevono una notifica relativa al nuovo evento di chiamata, ma il nodo CCX attivo risponde al gestore chiamate con una richiesta di reindirizzamento per una delle porte CTI da esso controllate.

Se in CUCM viene visualizzato un indirizzo IP rispetto a un punto di routing CTI, si tratta di uno degli indirizzi IP del CCX, ma ciò non significa che il nodo specifico stia instradando la chiamata.

Una cosa comune da fare è che il dispositivo viene dissociato dall'utente JTAPI e riaggiunto. Il motivo è che quando si annulla l'associazione, il provider riceve una notifica e rimuove tutte le connessioni a esso e quindi quando viene riaggiunto, l'observer viene aggiunto di nuovo e il provider inizia di nuovo a monitorarlo utilizzando una richiesta di provider aperta. Potete vedere che oltre al dispositivo che viene aggiunto nell'elenco dei dispositivi controllati, c'è un'altra cosa chiamata Consenti controllo del dispositivo dal CTI casella di controllo sul singolo dispositivo. In questo modo si ottiene un livello di granularità aggiuntivo. Pertanto, se nell'elenco controllato è stato aggiunto il punto di instradamento ma la casella di controllo CTI non è selezionata, è comunque possibile ricevere notifiche relative agli eventi sul punto di instradamento ma non è possibile eseguire alcuna azione sul controllo delle chiamate.

Flusso di chiamata

Di seguito sono riportate le sequenze di eventi coinvolti nel flusso di chiamate UCCX:

1. Quando la chiamata arriva al punto di routing CTI, viene reindirizzata a una porta CTI.
2. La porta CTI apre il canale multimediale con il driver ipvms nella casella uccx.
3. Una volta deciso che l'agente deve rispondere alla chiamata, viene effettuato un trasferimento della consulenza dalla porta all'agente.
4. Al punto di routing CTI viene inviato un nuovo evento chiamata.
5. La richiesta di reindirizzamento va alla porta CTI.
6. Lo stato dell'ID chiamata diventa inattivo.
7. Poi arriva un altro nuovo evento di chiamata per la chiamata alla porta CTI.
8. Se la risposta di reindirizzamento è 0, è buona, se è diversa da zero, significa che non è riuscita.
9. Quindi si invia una richiesta di accettazione della chiamata (la risposta non viene fornita, la richiesta viene accettata solo sulla porta).
10. Accettare quindi i passaggi sullo script, in questo caso la richiesta di risposta alla chiamata arriva in Jtapi.

11. Quindi si riceve una risposta dalla porta.

12. Lo stato della chiamata cambia in connesso.

13. Dopo aver ricevuto la risposta dalla porta, si verifica la negoziazione dei supporti.

14. La porta invia una richiesta open_logical_channel in cui condivide la porta e l'indirizzo ip a cui desidera che la parte remota invii l'RTP.

15. Prima di aprire il canale logico, crea una connessione con il driver IPVMS sulla scatola UCCX e apre un flusso RTP.

16. L'evento successivo è l'evento start_receiver che indica le informazioni sull'estremità remota (ad esempio l'indirizzo ip e la porta del dispositivo chiamante).

17. Si ottiene quindi l'evento start_transmission come qualsiasi altro segnale multimediale.

18. Ora state ascoltando l'IVR e i prompt.

19. Quando la chiamata raggiunge un passaggio nello script che consente il trasferimento della chiamata all'agente, viene visualizzato CallSetupTransferRequest.

20. A differenza del primo messaggio, questo è un trasferimento di consultazione e non un reindirizzamento.

21. Il motivo di questo trasferimento di consulenza è perché se un agente è PRONTO ma non al suo posto, e reindirizziamo la chiamata, rimane solo senza risposta, ma se facciamo un trasferimento di consulenza, allora se l'agente non è lì, allora la chiamata viene di nuovo messo in coda.

22. Come qualsiasi altro trasferimento di consultazione, questa è la porta CTI che preme il pulsante di trasferimento per la prima volta sul telefono.

23. In un normale trasferimento di consulenze, esiste un percorso di supporto tra A e C, ma in questo caso si istruisce CUCM di non farlo, in quanto non ha senso stabilire un supporto tra UCCX e l'agente.

24. Quindi si sta per fare un trasferimento di consulta senza fare un taglio di media tra l'agente e la porta CTI.

25. A questo punto, la porta CTI mette il chiamante in attesa e viene visualizzato un evento di modifica dello stato di chiamata = HOLD.

26. Ora viene visualizzato un evento di nuova chiamata dalla porta CTI al dispositivo agente.(Utilizzando l'ID chiamata originale, ma un sottoinsieme e un evento P2.)

27. Se si esegue una ricerca nell'ID chiamata evento P2, verrà visualizzato il messaggio successivo come richiesta CallAnswer, che indica che l'agente ha ricevuto la chiamata.

28. Una volta che l'agente ha risposto alla chiamata (utilizzando P2) e la chiamata è in stato connesso anche sul lato della porta CTI (utilizzando P1), il punto di instradamento vedrà unaCallDirectTransferRequest, il che significa che il pulsante di trasferimento è stato premuto per la seconda volta.

29. Ora che la porta CTI sa che l'agente ha risposto alla chiamata, non c'è punto d'attesa, invia immediatamente un messaggioCallDirectTransferRequest che indica che la porta CTI preme il pulsante di trasferimento una seconda volta, come spiegato sopra.

30. Ora, la gamba di richiamo originale (quella che era in attesa) è quella che è sopravvissuta.

31. L'altra gamba di richiamo viene distrutta (tra porto e agente).

32. A questo punto, CUCM e UCCX fuori dal quadro e RTP viene stabilito tra il chiamante e l'agente attraverso il gateway.

Il diagramma seguente illustra in modo riepilogativo il flusso di chiamate menzionato in precedenza.

Riepilogo flusso chiamate JTAPI

Risoluzione dei problemi

Abilita e raccogli registri JTAPI

Abilita debug JTAPI

Verificare i seguenti passaggi per abilitare i livelli di debug JTAPI.

1. Accedere a UCCX.
2. Passare a CCX Serviceability.
3. Vai alla traccia.
4. Andare alla configurazione.
5. Dall'elenco a discesa Select Service (Seleziona servizio), selezionare Cisco Unified CM Telephony Client.
6. Selezionare la casella di controllo Debug.
7. Selezionare tutte le caselle di controllo ad eccezione di MISC_DEBUGGING.

Raccogli debug JTAPI

Verificare i seguenti passaggi per abilitare i livelli di debug JTAPI da RTMT o CLI.

Da RTMT

1. Accedere allo strumento CCX Real Time Monitoring.
2. Fare clic su Trace & Log Central.
3. Fare clic su Raccogli file.
4. Selezionare JTAPI Client per tutti i server.
5. Fare clic su Next (Avanti).
6. Selezionare i timestamp e il percorso in cui si desidera salvare i file di registro.

Dalla CLI

Percorso registro JTAPI

activelog /uccx/log/JTAPI

Comando per raccogliere i log JTAPI:

file get activelog /uccx/log/JTAPI/* recurs compress

Sintassi:

file get {activelog|inactivelog|install} specifica-file [opzioni]

file-spec obbligatorio da trasferire

opzioni facoltative reltime mesi|settimane|giorni|ore|minuti valore temporale

                                 abstime hh:mm:MM/GG/AA hh:mm:MM/GG/AA

                                 corrispondenza regex

                                 ricorrenze

                                 comprimere

5 modi per scaricare i registri in base all'indicatore orario

reltime - Periodo di tempo relativo, espresso in minuti | ore | giorni | settimane | valore mesi

abstime - Periodo di tempo assoluto, specificato come hh:mm:MM/GG/AA hh:mm/GG/AA

match - Corrisponde a una stringa specifica nel nome del file, specificato come valore stringa

recurs: recupera tutti i file, include le sottodirectory

compress consente di scaricare i file in formato compresso.

Link di riferimento

• Guida per gli sviluppatori JTAPI
• Livelli di traccia UCCX