Guida alla risoluzione dei problemi IPCC

Introduzione

In questo documento vengono fornite informazioni per la risoluzione dei problemi relativi a Internet Protocol Contact Center (IPCC), che si occupa di Peripheral Gateway (PG) e Cisco Intelligent Contact Management (ICM). Sebbene questo documento contenga alcune informazioni sui problemi più comuni di Cisco CallManager e Cisco Global Directory, non cerca di descrivere completamente questi componenti. Piuttosto, questo documento si concentra sui sintomi e sui metodi per identificare la fonte dei problemi che il PG vede.  I problemi possono essere correlati al software o alla configurazione.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Come risolvere i problemi e supportare Cisco ICM PG

Componenti usati

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

• Cisco ICM versione 4.6.2

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.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Sintomi e azioni di risoluzione dei problemi

Esaminare i registri PG per IPCC. Se nei registri del server PIM (Peripheral Interface Manager), OPC (Open Peripheral Controller) o CTI (Computer Telephony Interface) vengono visualizzati errori non specificati, passare direttamente al registro GW (JTapi Gateway) per una descrizione più dettagliata del problema. L'interfaccia JTAPI in genere fornisce eccezioni in caso di problemi su richieste di terze parti. Queste eccezioni forniscono solo descrizioni di stringhe senza codice di errore. Di conseguenza, il server PIM/OPC/CTI registra molti errori come non specificati.

Cisco IPCC PIM non diventa attivo

PIM non abilitato

Verificare l'esistenza di un registro PIM. Se non è presente alcun registro PIM, verificare che la periferica sia abilitata in Cisco ICM Setup. A volte, la periferica viene aggiunta, ma è necessario attivarla.

Selezionare Modifica > Periferica e selezionare la casella di controllo Abilitato.

Riavvii PIM

Se il processo PIM viene riavviato, visualizzare il log PIM su Cisco CallManager PG con l'utilità dumplog. Se il file di registro indica un errore con OPCHeartbeatTimeout, è necessario modificare questa impostazione del Registro di sistema. Utilizzare regedt32 per apportare la modifica.

Modificare OPCHeartbeatTimeout nel Registro di sistema in eagtpim dynamic data in 10. Il percorso è il seguente:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
PIMS\<pim_inst>\EAGENTData\Dynamic

Nota: questo tasto viene visualizzato su due righe a causa dei limiti di spazio.

PIM in stato di inattività nella finestra del registro PIM

Se il processo PIM è inattivo, eseguire i controlli seguenti:

• Controllare il registro PIM. È necessario visualizzare "Tentativo di attivazione" almeno una volta al minuto.

• Se il PIM non è attivo, utilizzare l'utilità dumplog per controllare il registro OPC. Eseguire il comando opctest per verificare se il processo OPC riceve la configurazione dal router.

• Se il processo OPC non riceve la configurazione dal router, utilizzare l'utilità dumplog per visualizzare il registro pgagent. Il processo pgagent deve avere un percorso attivo al controller centrale. Se pgagent non ha un percorso attivo, controllare la connettività di rete e la configurazione DMP nell'installazione di PG. Sul router, usare l'utility dumplog per visualizzare il registro dell'agente. Verificare se il dispositivo PG (ID sistema DMP) è abilitato come dispositivo sul router.

• Abilitare il PG nella configurazione del router tramite il programma di installazione o nel Registro di sistema in DMP.

• In una finestra di comando, usare il comando tracert per verificare la connettività di rete tra il router e il PG.

  Nota: potrebbe esserci una discrepanza tra DNS e DHCP.

• Verificare se l'indirizzo IP del router si trova nel file host nella directory c:\winnt\system32\drivers\etc.

• Verificare che l'ID del controller logico configurato in PG > Configurazione corrisponda all'ID del controller dell'interfaccia logica PG in Configurazione > ICM. Verificare che l'ID della periferica configurato per la periferica in PG > Configurazione corrisponda all'ID della periferica in Configurazione > ICM.

• Modificare l'impostazione di ICM in modo che corrisponda alla configurazione.

Il processo JGW non diventa attivo

È installata una versione non corretta di Microsoft Java Virtual Machine (JVM)

• Andare al prompt dei comandi, digitare jview e premere INVIO. Vengono visualizzate le informazioni relative alla versione Java installata:

  Microsoft (R) Command-line Loader for Java version 5.00.3190

• Se questo output non viene visualizzato o se la versione è precedente alla 3190, è necessario installare la versione corretta di Microsoft JVM. Eseguire msjavx86.exe. Il file viene installato nella directory icr\bin durante l'installazione.

Classpath Java non corretto

• Dal prompt dei comandi, andare alla directory icr\bin, digitare jtapigw e premere INVIO.  Viene visualizzata una risposta simile a questa:

  18:43:17 Fail: Node Manager Required Arguments missing.
  18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164)
  18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs
   (NodeManager.java:27)
  18:43:17 Trace: at MainWorkerThread.mainImplementation
   (MainWorkerThread.java:41)
  18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)

• In alternativa, viene visualizzato questo messaggio:

  Java.lang.NoClassDefFoundError: com/cisco/icr/GWThreadGroup

• Se viene visualizzato il secondo messaggio quando si esegue jtapigw, verificare il percorso di classe Java.  Utilizzare l'editor del Registro di sistema per esaminare il valore Classpath nella chiave SOFTWARE\Microsoft\Java VM.  Impostare la chiave nel modo seguente:

  C:\WINNT\java\classes;.;c:\icr\bin\icrjavalib.zip

Nota: la lettera di unità e la directory di sistema di Windows possono essere diverse e i caratteri dopo le classi e prima di c:\icr... sono: punto e virgola, punto e virgola.

Client JTAPI Cisco non installato su PG

• Dal prompt dei comandi, andare alla directory icr\bin, digitare jtapigw e premere INVIO.  Viene visualizzata una risposta simile a questa:

  18:43:17 Fail: Node Manager Required Arguments missing.
  18:43:17 Trace: at com/cisco/icr/ems.EMSFailMessage (ems.java:164)
  18:43:17 Trace: at com/cisco/icr/NodeManager.setStartupArgs (NodeManager.java:27)
  18:43:17 Trace: at MainWorkerThread.mainImplementation (MainWorkerThread.java:41)
  18:43:17 Trace: at MainWorkerThread.run (MainWorkerThread.java:19)

• Invece di quanto sopra, è possibile visualizzare questo messaggio:

  Java.lang.NoClassDefFoundError

• Se durante l'esecuzione di jtapigw viene visualizzato un messaggio simile al secondo, verificare che il client JTAPI Cisco sia installato sul server PG. Cercare il file CiscoJapVersion.class in c:\winnt\java\lib.

• Se il file non esiste, è possibile installarlo sul PG da Cisco CallManager; http://<nome gestore chiamate>/main.asp. È possibile individuare il file nella scheda dell'applicazione.

Il registro GW JTAPI si lamenta della versione JTAPI incompatibile

• Se è stato installato solo JTAPI 4.1 Service Pack (SP) 4 con una correzione inferiore a 50 in Cisco CallManager PG, è necessario eseguire l'aggiornamento.

• Se è stato appena eseguito ICM > Setup per aggiornare il file PG, verificare che la data e l'ora sul file \icr\bin\icrjavalib.zip mostrino una data aggiornata. La data deve corrispondere approssimativamente alla data/ora del file bldXXXXX.version, entro un giorno circa.

Nota: se il file è in uso durante l'esecuzione del programma di installazione, non sarà possibile aggiornarlo. Questa situazione può verificarsi se è aperto un browser Internet perché, il browser tratta il file zip come una directory per il percorso della classe se il browser apre lo zip. Per evitare questo problema, chiudere tutte le sessioni del browser prima di eseguire il programma di installazione.  Se il programma di installazione non è in grado di aggiornare il file, verrà visualizzato un messaggio che richiede di riavviare il computer per aggiornare i file. È necessario riavviare.

JTAPIGW non può connettersi a Cisco CallManager

• Il PIM comunica con il gateway JTAPI (JTAPIGW), mentre il JTAPIGW comunica con Cisco CallManager. Quando il PIM tenta di diventare attivo, il PIM indica a JTAPIGW di inizializzare le comunicazioni con Cisco CallManager tramite JTAPI.

• È necessario visualizzare messaggi che indicano che JTAPIGW ha accettato una connessione dal PIM e contatta getProvider(), ad esempio:

  13:16:47 pg2A-jgw1 Trace:Calling getProvider () 172.24.79.128; 
    login=PGUser;passwd=<***edited***>
  13:16:52 pg2A-jgw1 Trace: Returned successfully from getProvider()

  Nota: questo esempio viene visualizzato su più righe a causa di limitazioni di spazio.

Se la traccia non viene restituita correttamente, è possibile visualizzare altri errori dopo la chiamata a getProvider().  La traccia di getProvider() mostra i parametri utilizzati per inizializzare JTAPI.  Il primo parametro è il nome del servizio, ossia il nome host IP o l'indirizzo IP del computer Cisco CallManager.  Nell'esempio viene usato l'indirizzo IP.  Se si utilizza un nome, il PG deve essere in grado di risolverlo tramite un file host o DNS.  Accertarsi di poter eseguire il ping del nome o dell'indirizzo.  Se è necessario modificare il nome del servizio, eseguire nuovamente ICM > Setup, quindi modificare il nome nella finestra di dialogo Modifica periferica.

La traccia della chiamata a getProvider() mostra anche il nome di accesso utilizzato. Si noti che la traccia non mostra la password. Il nome e la password di accesso vengono presi da quanto l'amministratore immette in ICM > Setup. Questi devono corrispondere a un utente valido configurato nella directory e amministrato nella pagina Web delle preferenze utente di Cisco per avere la possibilità di controllare ognuno dei dispositivi dell'agente e dei punti di instradamento. Verificare che il nome e la password siano corretti in ICM > Setup. Configurare l'utente nella directory in modo che abbia l'autorizzazione a controllare solo i dispositivi dell'agente e i punti di instradamento validi.

Il log JGW indica un host sconosciuto

Il processo JTAPI GW non è in grado di risolvere l'indirizzo di Cisco CallManager. Configurare il parametro service nella finestra di dialogo PIM in Setup con il nome host o l'indirizzo IP di Cisco CallManager. Se la configurazione del nome host per Cisco CallManager è corretta, verificare di poter eseguire il ping su Cisco CallManager. In caso contrario, utilizzare l'indirizzo IP di Cisco CallManager anziché il nome host.

Il registro JGW indica che la password o l'utente non è valido

JTAPI GW accede alla directory globale con un nome utente e una password. Il nome utente e la password nella finestra di dialogo PIM del programma di installazione devono corrispondere al nome utente e alla password per l'utente configurato nella directory globale della pagina Web Cisco CallManager admin in ccmadmin > User > Global Directory.

Se l'utente non esiste, aggiungerne uno nuovo. Assicurarsi di selezionare la casella di controllo CTI abilitato nella parte inferiore della pagina.

Casella di controllo CTI non abilitata nella pagina Utente di Global Directory

Una casella di controllo nella pagina utente della directory globale Cisco CallManager può abilitare o disabilitare i privilegi CTI per un utente PIM o IP IVR. Per attivare PIM/JTAPI GW, è necessario selezionare e aggiornare questa casella di controllo. Questa casella di controllo impedisce a due dispositivi CTI di connettersi a Cisco CallManager e può causare problemi (il limite predefinito è 400).

Il servizio Cisco CallManager non viene eseguito

• In Cisco CallManager versione 3, questo servizio viene visualizzato in controllo servizi come "Cisco CallManager". Avviare il servizio.

• In genere, il servizio Cisco CallManager è impostato per il riavvio in caso di uscita anomala, ma è possibile configurarlo in modo che venga disattivato per possibili problemi relativi alla migrazione di dispositivi in scenari di failover.

• Controllare il registro eventi per verificare se il servizio Cisco CallManager viene riavviato. Talvolta il sistema viene riavviato se identifica un problema relativo all'utilizzo adeguato della CPU. Il sistema riporta errori o avvisi nel registro eventi che indicano un "thread timer SDL lento". Con questo tipo di errore, Cisco CallManager viene riavviato. Questa versione di Cisco CallManager viene eseguita a priorità normale in modo che altre applicazioni in esecuzione sul sistema possano interferire con il segnale di chiamata.

• Quando la memoria fisica è inferiore o il sistema rileva altri problemi di temporizzazione, Cisco CallManager può generare un errore che indica che non è stato possibile inizializzare dopo un timeout di 10 minuti e riavviare. Si è verificato un problema di inizializzazione di un servizio componente DCOM per il livello database (DBL) di Cisco CallManager. Per risolvere il problema, arrestare e avviare il servizio DCOM DBL tramite Servizi componenti - Componenti DCOM.

  Nota: questo non è lo stesso di un servizio di sistema come Cisco CallManager.

  Apri una richiesta con il Cisco Technical Assistance Center (TAC). È possibile che questo problema si verifichi al successivo riavvio del sistema, a meno che non si risolva il problema di intervallo sottostante.

Problemi relativi alla directory (configurazione, non in esecuzione, password della directory)

Il servizio directory non viene eseguito

• Verificare che il servizio directory sia attivo e funzioni correttamente.  Per impostazione predefinita, questo è il server di directory controller di dominio in controllo servizio sul computer Cisco CallManager. Provate ad avviare la macchina. Possono verificarsi degli errori.

• Il servizio directory può passare allo stato di pausa se la memoria o lo spazio su disco del sistema si esaurisce. Gli errori vengono visualizzati nel registro eventi di Microsoft Windows 2000. Risolvere i problemi relativi alle risorse e riavviare il servizio directory, se necessario.

La pagina utente Web Cisco CallManager non funziona

Verificare che la pagina Web utente di Cisco Global Directory possa effettivamente visualizzare e configurare gli utenti e assegnare le autorizzazioni ai dispositivi di controllo. Sia JTAPIGW che la pagina Web utilizzano Cisco CallManager per accedere al server delle directory e accedere agli utenti e alle autorizzazioni. Se il problema con JTAPIGW è dovuto a un problema del server delle directory, anche la pagina Web dell'utente può presentare problemi. È possibile che il server delle directory non venga eseguito o che la directory non sia configurata correttamente.

Server di directory non installato

Per utilizzare Cisco CallManager 3.0.5 e versioni successive, è necessario installare un server delle directory. La directory AVVID DC è l'impostazione predefinita disponibile nei CD di installazione di Spirian. Dopo aver installato il server delle directory, l'installazione di Cisco CallManager configura la directory.

È necessario eseguire questa installazione correttamente e il server delle directory deve essere attivo e deve essere eseguito correttamente affinché JTAPIGW possa accedere a Cisco CallManager e utilizzare JTAPI.

Verificare che il servizio directory controller di dominio e Cisco CallManager funzionino correttamente.

Quando si installa Cisco CallManager, è necessario immettere "cisco" quando viene visualizzato il prompt con la richiesta della password. Se si immette qualcos'altro, potrebbe essere necessario rimuovere il software di directory DC (Aggiungi/Rimuovi) e reinstallarlo. Se durante il processo di rimozione alcuni file non possono essere rimossi, è necessario rimuovere o rinominare manualmente la directory c:\dcdsrvr corrente.

Il server di directory è installato ma non viene eseguito

Controllare il pannello di controllo per verificare che il servizio non possa essere avviato. Verificare quindi che l'amministratore sia configurato e che l'accesso e la password siano corretti per il servizio nel campo Proprietà.

Il server delle directory è installato ed è in esecuzione ma non è in grado di accedere con lo strumento di amministrazione DCD

Avviare DC Directory Admin dal menu Start del sistema. Accedere con l'utente Directory Manager con la password "cisco" (predefinita) o con qualsiasi password configurata dall'amministratore. Se viene visualizzato un errore che indica che l'utente non è configurato, eseguire uno dei file di configurazione di Cisco AVVID nella directory DCDSrvr\bin. Se si tratta del Cisco CallManager principale di Publisher, eseguire avvid_cfg.cmd dal prompt di DOS. Se si tratta di un Cisco CallManager secondario, eseguire avvid_scfg.cmd dal prompt dei comandi.

Se vengono visualizzati errori che indicano che la configurazione è già stata eseguita, l'utente non esiste. Se non ci sono errori, le cose devono iniziare a funzionare correttamente ora. Tornare indietro e controllare l'accesso dalle pagine utente di Global Directory su ccmadmin.

Nota: il controller di dominio entra in modalità di pausa se le risorse di sistema della directory sono insufficienti.

L'agente non riesce ad accedere

In questo esempio viene utilizzata una configurazione ICM di esempio per una destinazione dispositivo:

Esempio di destinazione del dispositivo
Nome organizzazione	Agent9782755100
Indirizzo globale	Agent9782755100
ParamConfigurazione	/devtype CiscoPhone /dn 9782755100

Nell'esempio seguente viene utilizzata una configurazione ICM di esempio per un agente:

Esempio agente
Periferica	CCMPG_PIM1
Numero periferica	1234
Password	XXX

Quando si esegue ICM > Setup per il PG, si specifica una lunghezza di estensione dell'agente di "4". Pertanto, nella configurazione di esempio, l'estensione del dispositivo di esempio è rappresentata dalle ultime 4 cifre del parametro /dn (ad esempio, "5100").

Provare ad accedere con CTITest.

Se non è possibile accedere a un agente tramite il soft phone, provare a eseguire la stessa operazione tramite ctitest. Di seguito è riportato un elenco di esempio di comandi ctitest che è possibile utilizzare per accedere all'agente di esempio per la destinazione del dispositivo di esempio. In questo elenco di comandi si presume che il server CTI sia in ascolto sulla porta 42027 nel computer CTIServerA. L'elenco presuppone inoltre che il dispositivo sia un'estensione della periferica rappresentata come periferica ICM 5000.

config /hostA CTIServerA
config /portA 42067
config /service CLIENT_EVENTS+CLIENT_CONTROL
agent /periph 5001 /inst 9782755100
open
login 1234 XXX /inst 9782755100

PIM e CTI Server non sono attivi in OPC

Usare il comando option "status" (stato) e verificare che gli stati PIM IPCC e CTI Server siano attivi e attivi. Anche le barre del titolo delle finestre di registro PIM e CTI Server indicano lo stato del processo.

Impossibile connettere il client CTI

Verificare le impostazioni per la connessione al server CTI. Per il soft phone desktop, le impostazioni si trovano nel file .ini (generalmente c:\programmi\hotel\cti desktop\cticonfig.ini). Le impostazioni da controllare includono:

• PeripheralID: questo valore deve corrispondere all'ID della periferica IPCC in Configure > ICM.

• SideHost: questo valore deve corrispondere al nome host IP o all'indirizzo del server CTI lato A.

• SideBHost: questo valore deve essere il nome host IP o l'indirizzo del server CTI lato B.  Se CTI Server è semplificato, è possibile lasciare vuoto questo campo.

• SideAPort: questo valore deve corrispondere alla porta usata dal server CTI sul lato A per le connessioni. Questo valore è specificato in Impostazione ICM per il server CTI. CTI Server visualizza questa porta nella barra del titolo e registra questo valore all'avvio di CTI Server. Verificare se il client può eseguire il ping del server CTI.

L'errore CTI Client Get indica che l'agente deve essere connesso ad ACD

Eseguire il file setup.exe che si trova nella directory \icr\bin del server PG/CTI. Selezionare il componente gateway CTI. Verificare se la casella di controllo Accesso agente richiesto è deselezionata. Questa casella di controllo non può essere selezionata per IPCC o applicazioni di controllo di terze parti. Lo scopo di questa casella di controllo è monitorare applicazioni e altri agenti ACD.

Nel log PIM viene visualizzato uno dei seguenti errori di login

Utilizzare procmon per il pim e "trace tp*" per attivare la traccia di terze parti (con distinzione tra maiuscole e minuscole). Deve essere visualizzata la richiesta di accesso. Verificare che i parametri siano corretti. Lo strumento viene tracciato come "Device=". Questo valore deve corrispondere alla stringa /dn nel parametro di configurazione di destinazione del dispositivo. L'ID agente viene tracciato come "AgentID=". Questo valore deve corrispondere al numero di periferica dell'agente in Configure/ICM.

• PASSWORD_NON VALIDA

  Assicurarsi che la password sia corretta (la password potrebbe non essere tracciata come testo non crittografato). Se la password non è corretta, nel registro deve essere visualizzato un errore INVALID_PASSWORD_SPECIFIED.

• OGGETTO_NON VALIDO

  Indica che i parametri di configurazione nella destinazione del dispositivo contengono un tipo di dispositivo non valido. Questo errore è simile al seguente con gli spazi tra le parole chiave:

  /devtype CiscoPhone /dn 9782755100

• DESTINAZIONE_DISPOSITIVO_NON_VALIDO

  Indica che la destinazione del dispositivo non è valida, probabilmente nel campo dei parametri di configurazione. Con l'utilità dumplog, visualizzare il registro PIM per l'ultima volta che il PIM è stato riavviato. Il registro convalida le destinazioni dispositivo e registra gli errori quando le stringhe di configurazione destinazione dispositivo non sono valide.

Il log JGW mostra gli errori di login

Controllare nel log jgw eventuali errori che si verificano durante i tentativi di login. Utilizzare procmon per il PIM e "trace *TP*" per attivare il trace di terze parti (con distinzione tra maiuscole e minuscole). Cercare la riga "MsgAddCallObserver: Indirizzo: XXXX" dove XXXX è l'estensione in cui si tenta di eseguire l'accesso. Questa estensione deve essere un'estensione Cisco CallManager valida su un dispositivo che l'utente PG è autorizzato a controllare. L'interno deve contenere il numero di cifre esatto per il telefono, come Cisco CallManager sa. In altre parole, l'interno deve essere il numero composto da un altro telefono dello stesso Cisco CallManager per raggiungere il telefono in questione.

Dispositivo non presente nel dominio del provider

Se il log jgw mostra un'eccezione, che indica che il dispositivo non è nel dominio del provider, il telefono non è associato all'utente con cui JTAPI GW accede. Verificare che l'estensione all'estremità remota dell'elenco delle associazioni dei dispositivi utente di Global Directory sia corretta. Verificare inoltre che il numero di linea della periferica non sia registrato due volte. L'aspetto della linea condivisa è una funzione di Cisco CallManager non supportata da IPCC. È possibile tentare inavvertitamente di impostare un aspetto di linea condivisa con due telefoni che hanno la stessa linea. Se si modifica un numero di riga, l'altro viene modificato e PG non può accedere al dispositivo corretto. Per risolvere il problema, eliminare entrambe le righe e aggiungerle a Cisco CallManager.

SPECIFICATO_GRUPPO_COMPETENZE_NON VALIDO

Per eseguire l'accesso, un agente deve essere configurato in Configurazione/ICM come membro di almeno un gruppo di abilità (membro del gruppo di abilità).

Agente già connesso a un altro telefono

Verificare che l'agente (come rappresentato dal numero di periferica dell'agente) non sia già collegato a un'altra destinazione del dispositivo. Un modo per verificare questa condizione consiste nell'eseguire Monitoraggio ICR ed eseguire il report Free from Agent per l'agente in questione. Se l'agente è connesso, viene visualizzato l'ID della destinazione di rete della destinazione del dispositivo a cui è connesso l'agente. I dati dell'agente vengono visualizzati nell'awdb solo se ICM è stato configurato per l'invio dei dati dell'agente per la periferica a questo AW.

• È inoltre possibile eseguire una query per questa operazione in isqlw sulla tabella Agent_Real_Time in awdb. Individuare innanzitutto il target di abilità per l'agente (ad esempio, selezionare * dall'agente dove ID periferica = XXX e Numero periferica = YYYY). Quindi, controllare se l'agente è connesso (ad esempio, selezionare * da Agent_Real_Time dove SkillTargetID = XXX).

• È inoltre possibile verificare questa condizione quando si esegue la connessione a procmon a PIM e si esegue dagent <agent peripheral number>.

Destinazione dispositivo già connessa

Verificare che la destinazione del dispositivo (come specificato dallo strumento) non abbia già un altro agente connesso.

• Per verificare questa condizione, eseguire isqlw nella tabella Agent_Real_Time in awdb. Individuare innanzitutto l'ID della destinazione di rete per la destinazione del dispositivo in questione. Ad esempio, selezionare * da Device_Target dove ConfigParam è simile a ‘%1003%’. Verificare ora se la destinazione del dispositivo è connessa. Ad esempio, selezionare * da Agent_Real_Time dove NetworkTargetID = XXX.

• È inoltre possibile verificare questa condizione quando si esegue la connessione a procmon al PIM e si scarica la destinazione del dispositivo. Esistono due modi per eseguire il dump della destinazione del dispositivo. Il comando ddt accetta come input un ID di destinazione di rete ed esegue il dump della destinazione del dispositivo. Il comando deadt accetta la stringa /dn dalla configurazione di destinazione del dispositivo come input ed esegue il dump della destinazione del dispositivo. Ad esempio, se la stringa /dn della destinazione del dispositivo è /dn 9782755100, la destinazione del dispositivo verrà scaricata come deadt 9782755100.

Dispositivo non associato all'utente PG

Andare alla pagina Web di Cisco CallManager, selezionare User/Global Directory e individuare l'ID utente utilizzato da PG. Controllare la voce "Associated Devices" (Dispositivi associati) e assicurarsi che l'utente disponga delle autorizzazioni necessarie per controllare il dispositivo.

• Se non è possibile trovare il dispositivo nella pagina utente (selezionata o deselezionata), potrebbe essersi verificato un problema con la sincronizzazione tra il database (in cui Cisco CallManager memorizza i dispositivi) e il server delle directory (in cui sono memorizzati i dispositivi e i profili utente). Verificare che il server delle directory (DC Directory Server) sia in esecuzione.

• Controllare il registro applicazioni del Visualizzatore eventi di Windows NT e cercare gli errori nella directory DC o in metalink. Se si verificano errori di importazione, eseguire avvid_recfg da c:\dcdsrvr\bin.

• Verificare che Microsoft Java Virtual Machine (JVM) sia installato sul computer Cisco CallManager. Per verificarlo, digitare jview al prompt dei comandi. Per Cisco CallManager 2.4, è necessario installare JVM manualmente. Per Cisco CallManager 3, la piattaforma è Windows 2000 e l'installazione JVM è automatica.

Dispositivo telefonico non attivo

Controlla se il telefono è acceso, registrato con Cisco CallManager e in grado di effettuare e ricevere chiamate dal telefono senza controllo da parte dell'agente.

Impossibile effettuare la chiamata

Agente in stato non pronto

Verificare che l'agente sia connesso e non in stato Disponibile.  Se l'agente non è disponibile, non può effettuare una chiamata. Per effettuare una chiamata, fare clic su Non pronto.

Impostazioni Agent Desk non corrette

Se si verifica un errore solo durante la composizione di determinati numeri, controllare tali numeri da un telefono fisico per verificare che sia possibile effettuare correttamente la composizione. Se è stato configurato un piano numerico composto da ICM, verificare se il numero composto corrisponde a uno dei caratteri jolly inclusi nel piano numerico composto. Verificare quindi se le impostazioni del desk dell'agente consentono all'agente di comporre il tipo di numero identificato dalla voce del piano numerico (ad esempio, Internazionale).

Piano numerico composto in PIM Blocks Access

Il piano numerico composto configurato per ogni PIM può essere configurato in modo errato o correttamente per impedire a un agente di effettuare chiamate verso un determinato numero. L'errore nel registro PIM deve indicare un errore di autorizzazione. I numeri per gli agenti e i dispositivi non possono sovrapporsi quando il piano numerico composto viene utilizzato per effettuare chiamate da agente a agente.

L'Agente Effettua Una Chiamata Breve, Deve Attendere Per Effettuarne Una Nuova

Il router rende l'agente non disponibile quando l'agente effettua una chiamata o quando una chiamata viene indirizzata all'agente. Questo meccanismo consente al router di instradare un'altra chiamata all'agente prima che il PIM segnali l'arrivo della chiamata. Alcune reti impiegano diversi secondi per instradare effettivamente la chiamata. Il router non annulla il timer in base allo stato dell'agente.

Se il tempo effettivamente necessario per instradare le chiamate al PIM dal client di routing è relativamente breve, è possibile modificare il tempo configurabile nel router. Su uno dei router di una finestra dei comandi DOS, utilizzare rtsetting.exe. Cercare in Estrapolazione > Agente. L'impostazione predefinita è 10 secondi. Se il valore è troppo breve, il router instrada le chiamate agli agenti che stanno per ricevere una chiamata. In questo modo il PIM rifiuta le chiamate.

Il timeout predefinito per PIM è di 7 secondi. È possibile modificare questo valore con il comando regedt32. Aggiungere la chiave "AgentReserveTimout" nel percorso seguente:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\EAGENTData\Dynamic\

Nota: questo tasto verrà aggiunto nella versione 4.1.5 del programma di installazione.

Nota: questo tasto viene visualizzato su due righe a causa dei limiti di spazio.

Il numero PIM deve essere sempre inferiore di alcuni secondi al timer di estrapolazione del router per impedire al router di inviare nuovi eventi pre-chiamata al PIM prima che venga elaborato l'evento originale. Questo causa problemi nel PIM.

Se la chiamata arriva dopo il timeout PIM, viene considerata una chiamata non ACD e alla chiamata non viene assegnata alcuna variabile di contesto, informazioni sul servizio o sul gruppo di competenze.

L'agente non può andare: non pronto, occupato o altro

Agente in stato "Attivo"

Se l'agente è impegnato in una chiamata e fa clic su Non pronto, Occupato o Altro, lo stato dell'agente non cambia immediatamente. Questo è intenzionale. L'agente rimane nello stato Talk o Held fino al completamento della chiamata. L'agente passa a Non pronto, Pronto per il lavoro o Non pronto a seconda del pulsante premuto. Se, al termine della chiamata, l'agente passa immediatamente a Disponibile, è necessario controllare le impostazioni del desk dell'agente per l'agente e verificare se sono impostati Disponibile dopo l'entrata o Disponibile dopo l'uscita. Queste impostazioni sostituiscono le attività eseguite dall'agente con i pulsanti durante una chiamata.

Impedisci transizione impostazioni Agent Desk

Verificare le impostazioni della scrivania dell'agente in Configura ICM e verificare se il campo Motivo di inattività richiesto è selezionato. Se la casella di controllo è selezionata, l'agente non può passare allo stato Non pronto senza un codice motivo. Modificare Desktop_Settings.cfg in modo che corrisponda all'impostazione della postazione dell'agente in Configura ICM oppure modificare l'impostazione della postazione dell'agente in Configura ICM.

Se all'agente non è assegnata alcuna impostazione del desk dell'agente, l'agente è in grado di eseguire l'accesso e di prepararsi, ma l'agente non è in grado di eseguire not_ready o la disconnessione. Per risolvere il problema, chiudere l'applicazione dell'agente, assegnare un'impostazione della scrivania dell'agente ed eseguire nuovamente l'accesso.

L'agente deve attendere di non essere pronto

Il router rende l'agente non disponibile quando l'agente effettua una chiamata o quando una chiamata viene indirizzata all'agente. Questo meccanismo consente al router di instradare un'altra chiamata all'agente prima che il PIM segnali la chiamata come ricevuta. Alcune reti impiegano diversi secondi per instradare effettivamente la chiamata. Il router non annulla il timer in base allo stato dell'agente.

Se il tempo effettivo impiegato per instradare le chiamate al PIM dal client di routing è relativamente breve, è possibile modificare il tempo configurabile nel router. Su uno dei router di una finestra dei comandi DOS, utilizzare rtsetting.exe. Cercare in Estrapolazione > Agente. L'impostazione predefinita è 10 secondi. Se il valore è troppo breve, il router instrada le chiamate agli agenti che stanno per ricevere una chiamata. In questo modo il PIM rifiuta le chiamate.

L'agente non può essere pronto

PRIVILEGIO_VIOLATION_ON_SPECIFIED_DEVICE

Incoerenza nei dati per la richiesta di accesso e la richiesta ready. È possibile che lo strumento, l'ID agente o i numeri di periferica non corrispondano. Attivare CTI Server trace con procmon e impostare regset su 0xf8 per visualizzare le tracce appropriate. È inoltre possibile visualizzare questo valore nei log OPC o PIM, se è attiva la traccia di terze parti (TP).

L'agente non può disconnettersi

Lo Stato Corrente Dell'Agente Impedisce La Chiamata

Se l'agente si trova nello stato Pronto per il lavoro, Non pronto per il lavoro o Disponibile, deve passare a Non pronto prima che l'agente si disconnetta. Modificare Desktop_Settings.cfg in modo che corrisponda all'impostazione della postazione dell'agente in Configura ICM oppure modificare l'impostazione della postazione dell'agente in Configura ICM.

Impostazioni Agent Desk Impedisce La Modifica Dello Stato

Se l'agente si trova nello stato Non pronto e non può ancora disconnettersi, controllare le impostazioni della scrivania dell'agente in Configura ICM e verificare se il campo Motivo disconnessione richiesta è selezionato.

L'Agente Mostra Una Chiamata Attiva O Una Chiamata Attiva, Ma Nessuna Chiamata Al Telefono

Esci e torna indietro agente

Se il soft phone visualizza una chiamata che non è più fisicamente presente, lo stato dell'agente può essere bloccato in Parla o In attesa e l'agente non può disconnettersi. Ciò può essere dovuto a un bug software in JTAPI o PIM. Per cancellare la condizione, prima tentare di cancellare la chiamata dal soft phone se il pulsante di rilascio è abilitato. Se l'operazione non riesce, provare a disconnettere l'agente. Se il pulsante di disconnessione non funziona, uscire e riavviare il soft phone. Se la condizione persiste, uscire dal soft phone, eseguire Task Manager, terminare geodcs.exe e common~1.exe, quindi riavviare il soft phone. Questi processi possono continuare a essere eseguiti e ricordare lo stato dell'agente non valido.

Agente in stato non corretto nel PIM

In procmon , verificare lo stato dell'agente nel PIM. Se si riavvia il desktop dell'agente e la condizione non viene cancellata, è possibile adottare altre misure. Il server CTI e OPC forniscono meccanismi per cancellare le chiamate con l'interfaccia di debug procmon o opctest. Si tratta di un'opzione leggermente preferita rispetto all'altra, che consiste nel riaccendere il servizio PG o almeno chiudere la finestra PIM.

Chiamate cancellate subito dopo l'avviso o stabilite

Impostazioni del Registro di sistema non corrette

Con regedt32, controllare le seguenti impostazioni del Registro di sistema:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\
  CurrentVersion\<pim_inst>\CallControl\MaxAlertingTimeAllowedForCall

e

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\
  CurrentVersion\<pim_inst>\CallControl\MaxConnectedTimeAllowedForCall

Nota: queste chiavi del Registro di sistema vengono visualizzate su due righe a causa di limitazioni di spazio.

Impostate questi valori rispettivamente su 300 e 2800.

Il post-instradamento non funziona

Controllare lo script Route e Route

Utilizzare lo strumento AW Call Tracer per verificare se la chiamata raggiunge lo script e se lo script viene eseguito correttamente. Eseguire Script Editor e monitorare lo script. Esaminare i registri Router, OPC e PIM per individuare eventuali problemi. La maggior parte degli errori di route viene tracciata in modo incondizionato.

Controllo di 'Usa mappa etichetta DN' per il client di routing della periferica

In Configura ICM è disponibile un'impostazione per ciascun client di routing etichettata "Usa DN/mappa etichetta". Se questa impostazione è impostata su "Sì", è necessario configurare una voce "Etichetta numero composto" per ciascuna combinazione di numero composto ed etichetta di destinazione possibile. Questa impostazione non è utile sui client di routing PG e deve essere impostata su "No".

Nessuna etichetta configurata per la destinazione della periferica di routing

Verificare l'etichetta configurata nel client di routing. È necessario configurare Label su ogni client anche se l'etichetta è identica su ogni client.

Il punto di routing CTI non è configurato in Cisco CallManager

Per utilizzare il post-routing, è necessario configurare un "CTI Route Point" su Cisco CallManager e assegnare una linea al punto di routing con il numero di directory desiderato (ad esempio, "5000"). Per le chiamate agente al post-routing, utilizzare il piano numerico composto. Un agente che accede al punto di routing CTI di Cisco CallManager confonde il soft phone IPCC nella versione 4.1.9 di CTI Desktop.

Il dispositivo per il punto di instradamento CTI non è incluso nell'elenco dei dispositivi controllati dall'utente PG

È necessario aggiungere il dispositivo CTI Route Point all'elenco di "Dispositivi associati" per l'utente PG nella pagina Web dell'utente Cisco CallManager in Global Directory. Se si crea una nuova periferica, aggiungere prima la riga o le righe, quindi aggiungere la periferica all'elenco "Periferiche associate" dell'utente. Se si aggiungono più righe a un dispositivo che esiste già nell'elenco dei dispositivi utente, è necessario riavviare JGW affinché riconosca le nuove righe. Tuttavia, se si aggiunge una nuova periferica, si aggiunge una linea alla periferica e quindi si aggiunge la periferica all'elenco delle periferiche utente, JGW deve essere in grado di riconoscere la nuova periferica (entro circa 30 secondi).

Nessun numero composto configurato su Cisco ICM

Verificare che il numero composto sia configurato per il client di routing delle periferiche. Eseguire procmon su JGW e attivare la traccia come "trace *ROUTE*" (con distinzione tra maiuscole e minuscole). Controllare il registro JGW per eventuali errori relativi al numero composto. All'avvio, JGW tenta di registrare una chiamata di route per il numero composto. Quando viene effettuata una chiamata al numero composto, il gateway riceve un "RouteEvent".

Insieme al numero composto, verificare se il tipo di chiamata è stato creato e mappato correttamente allo script.

Verificare che non sia necessario riavviare JGW

Se è stato configurato un numero composto da ICM, è stato impostato il punto di routing CTI e lo si è aggiunto all'elenco dei dispositivi utente, ma non si ricevono ancora richieste di routing quando viene composto il numero, potrebbe essere necessario riavviare JGW (o il PG). È necessario riavviare il sistema solo se è stata attivata la traccia in JGW (trace *ROUTE*) e si verificano errori che indicano che l'indirizzo non è presente nel provider. In genere, JGW deve essere in grado di riconoscere i nuovi punti di routing CTI aggiunti all'elenco dei dispositivi utente senza la necessità di riavviare. Inoltre, se le linee vengono aggiunte a un punto di stesura CTI già esistente, JGW non le riconosce senza la necessità di riavviarle. Per evitare il riavvio del sistema, aggiungere un nuovo punto di routing CTI per ciascun numero composto anziché nuove linee ai dispositivi già esistenti.

Nota: questo presuppone che DeviceListPolling sia attivato nel file JTAPI.ini nella directory winnt\java\lib in PIM. Se DeviceListPolling è disattivato, è necessario attivarlo. Se DeviceListPolling è disattivato e si aggiunge un dispositivo all'elenco degli utenti, è necessario eseguire un ciclo del PG o almeno JTAPI GW per il PG per visualizzare il nuovo dispositivo.

Controlla registri OPC per finestre di dialogo di instradamento

Utilizzare opctest per attivare la traccia di route "debug /routing" e verificare la presenza di errori nei registri OPC quando vengono eseguite chiamate al punto di routing. Verificare che le richieste di route vengano ricevute e che le etichette vengano restituite. Le richieste di instradamento vengono visualizzate come messaggi "CSTA_ROUTE_REQUEST" e "ICR_NEW_CALL_REQ". Le etichette restituite vengono visualizzate come messaggi "ICR_CONNECT". Se si verificano errori, è possibile visualizzare messaggi "ICR_DIALOG_FAIL" anziché messaggi "ICR_CONNECT". In questo caso, controllare se nel registro del router sono presenti errori.

Controlla registri router per finestre di dialogo route

Utilizzare rtsetting.exe per attivare la traccia della route e verificare la presenza di errori nei registri del router quando vengono eseguite chiamate al punto di route.

Assicurarsi che tutte le etichette necessarie siano configurate. Se lo script di instradamento è destinato agli agenti IPCC/EA, è necessario disporre di etichette configurate per il client di post-instradamento per ciascun dispositivo di destinazione.

Lo script di routing non rimuove la chiamata dalla coda quando l'agente diventa disponibile

Controllare il registro del router per eventuali errori. Se non esistono:

Nessun errore nel log del router — il nodo della coda è in coda per la priorità base del gruppo di abilità

Se il nodo della coda si accoda alla priorità di base, non accade nulla quando l'agente diventa disponibile. Per risolvere il problema, è possibile procedere in due modi:

• È presente un'impostazione del Registro di sistema del router denominata AutoLoginBase (utilizzare rtsetting.exe). Modificare questa impostazione per consentire l'accodamento della chiamata al gruppo di competenze di base per lavorare più o meno come previsto. Quando si utilizza questo tipo di accodamento, non vi è preferenza per le abilità primarie rispetto a quelle secondarie.

• Accoda esplicitamente al set di abilità primario e/o secondario nel nodo della coda.

Il log del router indica che l'etichetta non è configurata per la destinazione

Configurare l'etichetta per la destinazione del dispositivo in questione e tutte le altre destinazioni a cui il client di routing può indirizzare. Utilizzare lo strumento di configurazione globale AW per eseguire questa operazione in modo più efficiente rispetto alla configurazione di ICR.

Non è possibile ricevere risposte quando tutti gli agenti e le porte della coda sono occupati

Verifica registri router

• Gli errori di route devono essere tracciati senza condizioni.

• È possibile utilizzare lo strumento di controllo delle chiamate per verificare il percorso della route.

• Utilizzare trtrace per attivare la traccia delle richieste di route e controllare i registri del router per rilevare eventuali errori quando vengono eseguite chiamate al punto di route.

• Assicurarsi che tutte le etichette necessarie siano configurate. Se lo script di instradamento è destinato agli agenti IPCC/EA, è necessario disporre di etichette configurate per ciascun dispositivo di destinazione. Ogni destinazione del dispositivo deve disporre di etichette configurate per ogni client di routing che tenta di inviare chiamate. Pertanto, se una chiamata viene instradata dalla rete direttamente a un agente disponibile, il client di routing di rete deve disporre di un'etichetta per la destinazione del dispositivo associato. Se la chiamata viene prima inserita nella coda di una VRU e quindi consegnata all'agente, il client di routing della VRU deve avere un'etichetta per la destinazione del dispositivo associato.

Assicurarsi che il mapping delle etichette DN sia disattivato nel client di routing in Configura ICM

Verificare che l'opzione Usa mapping DN/etichetta non sia selezionata nella scheda Client di routing in Configuration Manager/PG Explorer.

Verifica registri PIM

• Utilizzare procmon per attivare la traccia nel PIM (trace precall, trace *call_event*) e controllare i registri. Il messaggio di pre-chiamata viene visualizzato dal router. Viene inoltre visualizzato "DeliveredEvent" con "DevTgDevStr" impostato sull'estensione dell'agente. Se la chiamata non viene visualizzata, verificare che l'etichetta sia corretta per il client di routing.

Risultati incoerenti nei trasferimenti arbitrari

IPCC non supporta l'opzione di mettere in attesa una chiamata ed effettuare una nuova chiamata perché Cisco CallManager fornisce risultati incoerenti. Questo è considerato un miglioramento del prodotto e può essere preso in considerazione per una versione futura.

Alternativo non funziona

Quando una chiamata di consultazione viene commutata/alternata/mantenuta/recuperata, Cisco CallManager interrompe l'associazione di consultazione. Ciò determina uno scenario di trasferimento arbitrario non supportato. Gli agenti possono riconnettersi al cliente e avviare una nuova consultazione. Il soft phone IPCC disattiva il pulsante alternativo finché non viene risolto, ma i produttori terzi possono inviare un reclamo.

La parte confermata non può tenere conferenze in un'altra parte

Cisco CallManager prevede un limite in base al quale solo l'iniziatore della conferenza può aggiungere altre parti alla conferenza. Le altre parti non possono aggiungere altre parti in Cisco CallManager.

Disconnessione imprevista della stazione agente

Timer inattività impostazioni scrivania agente

Nelle impostazioni di Agent Desk, è presente un'impostazione di tempo per disconnettere gli agenti nello stato Non pronto. Il tempo massimo di inattività è di 2 ore, ma è possibile configurare un tempo inferiore. Gli agenti in stato Disponibile non vengono disconnessi quando si trovano in stato di inattività. L'agente passa da Pronto a Non pronto se il timer di risposta squillo non scade (anche un'impostazione configurabile del desk dell'agente).

Timeout heartbeat server CTI

Timeout heartbeat configurato per il server CTI. La causa può essere costituita da computer obsoleti, server CTI sovraccarichi o reti con problemi di larghezza di banda. I registri del server CTI devono segnalare un errore nel registro.

L'agente non si comporta come configurato nelle impostazioni di Agent Desk

Le impostazioni del desk dell'agente in Configura ICR(M) e nel file di configurazione dell'agente devono concordare entrambe le modalità di gestione dell'agente.

È presente un timer di lavoro nella configurazione periferica su ICM in Parametri di configurazione. Impostare i parametri come \WORKTIMER 30 per impostare un ritardo di 30 secondi per la disponibilità automatica.

Il file di configurazione del desktop risiede in:

\program files\geotel\cti desktop\Desk_Settings.cfg

La modalità di lavoro in ingresso deve essere impostata su Obbligatorio, non su Obbligatorio con Dati in Desk_Settings.cfg e nelle impostazioni della scrivania dell'agente Configura ICR(M). Obbligatorio con dati sostituisce l'opzione di disponibilità automatica.

Trasferimenti consulta non riusciti

Esaminare il registro GW JTAPI e verificare se sono presenti errori che indicano la causa del mancato trasferimento della consultazione. Verificare se il software dell'agente consente operazioni di blocco/recupero o alternative alla chiamata di consultazione. Quando una chiamata viene trattenuta/recuperata, la chiamata non è più considerata consultiva, ma un trasferimento "arbitrario" da parte di Cisco CallManager. Cisco CallManager ha problemi con i trasferimenti arbitrari. Limitare l'utente alla riconnessione o al completamento del trasferimento durante una chiamata di consulenza.

Consulta la parte che si blocca ma l'aspetto della chiamata non scompare

Cisco CallManager attualmente ha problemi con un evento di disconnessione per una conferenza iniziata consulta quando la conferenza non è completata. Scollegare la chiamata una seconda volta per cancellare l'aspetto della chiamata al telefono dell'agente.

Il percorso di conversione verso la VRU non funziona

Controllare innanzitutto lo script attivo. Quindi, controllare i registri Router, OPC e PIM del client di routing e della VRU. La maggior parte degli errori viene tracciata incondizionatamente, ma è possibile ruotare la traccia per ottenere un'immagine migliore di ciò che accade.

Di seguito è riportata la sequenza del percorso di traduzione:

• Il client di routing invia una nuova richiesta di chiamata al router.

• Il router restituisce una connessione al client di routing con un'etichetta che deve recapitare la chiamata all'IVR.

• L'IVR deve quindi inviare una RequestInstruction utilizzata dal gruppo di ruoli della VRU per cercare la destinazione periferica.

• Il router corrisponde alle destinazioni periferiche dell'istruzione di richiesta con le destinazioni periferiche di instradamento della traduzione su cui attende.

• Lo script di instradamento continua con i nodi dello script di esecuzione o della coda progettati dal cliente.

Monitorare lo script attivo per trovare il percorso dell'errore. Esaminare la traccia del router per individuare eventuali errori. Verificare se il client di routing riceve le etichette iniziali. Verificare se la VRU riceve la chiamata. Verificare se la VRU invia un'istruzione di richiesta a livello PIM o OPC della VRU.

La richiesta di route non raggiunge "Translation Route to VRU Node" nello script di route

Monitorare lo script e verificare se la richiesta raggiunge il percorso di conversione al nodo VRU.

In primo luogo, nello script route, un nodo select o route select con una route di conversione selezionata non è sufficiente per tradurre la route alla VRU controllata dal servizio. È necessario un nodo di instradamento della conversione verso VRU.

In secondo luogo, il monitoraggio deve mostrare che la chiamata raggiunge il nodo del percorso di conversione. Un errore indica che non è possibile determinare una route di conversione oppure che il messaggio di richiesta della route RequestInstruction non è stato ricevuto dall'IVR.

Timeout route di conversione nel registro router

L'errore di timeout del routing di conversione indica che il router non riceve l'istruzione di richiesta. Verificare l'OPC e il PIM della VRU per individuare eventuali errori e verificare se RequestInstruction arriva.

Attivare le opzioni "translation routing" (routing di conversione) e "network VRU tracing" (tracciamento VRU di rete) con lo strumento trtrace sul router per avere un'indicazione migliore di ciò che accade nel router. Nell'OPC VRU PG, attivare il report di controllo del servizio con il comando opctest.

Il registro PIM della VRU indica che DNIS non è stato trovato nel gruppo trunk X

L'istruzione Request deve indicare un gruppo trunk valido mappato a un numero di periferica del gruppo trunk in uno dei gruppi trunk configurati per il gruppo PG VRU. Spegnere e riaccendere la VRU PG per ricevere l'aggiornamento del numero di periferica del gruppo trunk, se modificato.

Verifica configurazione ICM

Verificare che il mapping dell'etichetta DN sia disattivato nel client di routing IVR PG. L'IVR PG ha bisogno di un'assegnazione VRU di rete. La VRU di rete deve essere di tipo 2. Al PG IVR devono essere assegnati un gruppo trunk di rete e un gruppo trunk. Fare riferimento al gruppo trunk di rete nel gruppo trunk.

Il gruppo PG di routing NIC/post-routing deve avere un'etichetta per ciascun DNIS presente nelle destinazioni periferiche. Rendere le etichette uguali a DNIS per la richiesta del client di routing nella procedura guidata route di traduzione. È possibile impostarlo nel prefisso, selezionare l'opzione prefisso = DNIS.)

Quando un agente diventa disponibile, il client di routing VRU deve avere un'etichetta configurata per la destinazione del dispositivo verso cui viene indirizzato.

Risoluzione dei problemi dell'interfaccia Cisco IP IVR - ICM

In questa sezione viene descritto come risolvere gli errori di configurazione tra IP IVR e ICM e vengono descritti i problemi comuni relativi alla configurazione del routing post-routing e del routing di conversione IVR PG. Per ulteriori informazioni sugli errori IVR generali, consultare la Cisco IP IVR Troubleshooting Guide (Guida alla risoluzione dei problemi di Cisco IP IVR).

In generale, controllare i log MIVR nella pagina Web appadmin > Engine > Trace files.

• Porte CTI IVR e punti di routing CTI configurati in Cisco CallManager, IVR e ICM.

• Le porte CTI e i punti di routing CTI IVR sono associati all'utente IVR nella directory globale di Cisco CallManager.

• La casella di controllo Controllo servizio è selezionata nella configurazione ICM IVR.

• I nomi degli script nelle definizioni degli script IVR corrispondono ai nomi degli script VRU di rete in ICM.

• Il numero del gruppo trunk in VRU PG corrisponde al numero del gruppo di porte CTI in IP IVR.

Route di conversione non riuscita

Insieme a tutte le altre azioni utilizzate per risolvere i problemi, è possibile provare a eseguire queste operazioni per risolvere i problemi relativi all'IVR IP.

• Controllare il registro MIVR. Questo registro può in genere indicare aree problematiche.

• Le impostazioni di debug per l'attivazione di Cisco IP IVR sono SS_TEL e LIB_ICM.

• Attivare Cisco Japper Log for IP IVR con jtprefs su IP IVR. Vedere Strumenti di debug. Arrestare e avviare il motore IP IVR dopo aver attivato la traccia.

• Verificare se il numero del gruppo di porte CTI nel gruppo di porte della route di conversione JTAPI IP IVR corrisponde al numero di periferica nella configurazione del gruppo trunk in ICM.

Lo script non viene riprodotto o riproduce il messaggio di errore

Controllare i registri IP IVR nei file di traccia del motore per verificare se:

• Ricevuto script di esecuzione.

• IP IVR può trovare script. Caricare gli script con lo strumento di amministrazione del repository.

• IP IVR può trovare prompt. I prompt definiti dall'utente si trovano in \wfavvid\prompts\ user\en_us\ sull'IVR IP.

Stato JTAPI: visualizza servizio parziale

In genere, ciò significa che alcune porte CTI o punti di routing CTI configurati in IP IVR non sono stati configurati e/o associati all'utente IP IVR su Cisco CallManager.

Ciò può anche indicare che gli script non sono stati denominati correttamente o non sono stati caricati in Gestione repository.

Stato ICM su IP IVR: visualizza stato parziale

In genere, questa condizione indica una configurazione parziale o una configurazione non corrispondente su un lato o sull'altro.

Richiesta di arresto ascoltata quando una chiamata viene rimossa dalla coda del router

Questo è uno script di routing non configurato correttamente che consente un timeout troppo basso nella configurazione dello script VRU di rete in Configure ICR.

Alcuni degli script disponibili con IP IVR per l'interfaccia ICM vengono eseguiti per un periodo di tempo molto lungo, ma per impostazione predefinita il timeout della configurazione dello script di rete ICM è di tre minuti. Se si verifica il timeout dello script e il percorso di errore dello script di esecuzione esegue un altro script di esecuzione, questi ultimi vengono in pratica accodati in corrispondenza dell'IVR. Quando gli script vengono rimossi dalla coda, molti script vengono riprodotti uno sull'altro.

Risoluzione dei problemi relativi alle statistiche del servizio IVR

Le statistiche IVR sono importanti per i report dei livelli di servizio IPCC. Di conseguenza, in questa sezione vengono fornite alcune informazioni su come risolvere i problemi. In breve, le modifiche nei parametri Router e VRU PG dove le chiamate implementate nella VRU sono conteggiate come in coda, anziché connesse. Quando le chiamate vengono instradate, vengono segnalate come risposte. Quando il cliente in coda disconnette le chiamate, queste vengono segnalate come abbandonate. Per ulteriori informazioni, consultare il file readme.txt degli hot fix 53 e 54. Il router invia eventi speciali della coda che indicano lo stato della chiamata nel router.

Poiché nel PIM della VRU è presente un registro speciale, è necessario attivare questa funzione per ridurre al minimo le interruzioni.

Enterprise Service Real Time Report 10 utilizza in modo speciale questi dati quando si aggiungono i servizi VRU e i servizi Cisco CallManager PG a uno o più report sulle periferiche aziendali. Enterprise Service Real Time Report richiede che i servizi VRU PG e Cisco CallManager PG siano raggruppati in un servizio enterprise ai fini della creazione di report.

Altri rapporti utili sulle code sono i nuovi rapporti sul tipo di chiamata per i record in tempo reale e cronologici e la griglia in tempo reale del gruppo di abilità ora mostra le chiamate in coda rispetto al gruppo di abilità.

Nessun Record Di Statistiche Del Servizio O Di Dettagli Chiamate Di Terminazione Generato

VRU PIM non genera eventi CSTA. Attivare Service Control Reporting nella configurazione VRU PG. Si trova nella chiave del Registro di sistema in ServiceControlQueueReporting in:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\VRUData\Config

Nota: questa chiave del Registro di sistema viene visualizzata su due righe a causa di limitazioni di spazio.

La VRU segnala tutte le chiamate come connesse, non in coda come richiesto

Chiave del Registro di sistema ServiceControlQueueReporting non presente o non impostata su 1

Se il registro di avvio della VRU PIM non esiste, è necessario inviare un reclamo.

Aggiungere la chiave ServiceControlQueueReporting e impostare il valore su 1 in:

HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\
  PIMS\<pim_inst>\VRUData\Config

Nota: questo tasto viene visualizzato su due righe a causa dei limiti di spazio.

Le chiamate vengono conteggiate a fronte di un servizio errato o non vengono visualizzate nei report del servizio

Log OPC indica che il mapping del servizio non è stato trovato

Il log OPC indica che il mapping del servizio non è stato trovato quando le chiamate vengono conteggiate rispetto al servizio errato o non vengono visualizzate nei report del servizio.

Problemi di report ICM Cisco

Cisco ICM non è progettato per una facile correlazione delle tabelle Tipo di chiamata dei dati, Servizio e Gruppo di competenze. I numeri in genere hanno significati leggermente diversi in ciascun gruppo. Esiste un solo servizio per chiamata, ma possono esistere due gruppi di competenze se è coinvolto più di un agente. La funzionalità di reindirizzamento su risposta nulla (RONA) genera probabilmente un'altra route post senza generare un altro record di terminazione.

Gruppo di competenze agente, Gruppo di competenze, Servizio, Tipo di chiamata Numeri non quadrati

• Sintomo: Le chiamate gestite o altri campi statistici non corrispondono tra i report servizio, tipo di chiamata e/o gruppo di competenze.

• Condizione: Il tipo di chiamata, il servizio e i gruppi di competenze sono impostati con una mappa logica reciproca, ma i report non corrispondono esattamente.

• Risoluzione dei problemi: Se il volume di chiamata è inferiore a 1 chiamata al secondo, attivare le impostazioni di traccia in OPC, PIM e JTAPI GW, in base agli eventi CSTA, PIM, AGENT e di terze parti. Per istruzioni, consultare la sezione Strumenti di questo documento.

• Documentare il flusso di chiamata:

  • Il percorso iniziale del post è su Cisco CallManager PG o VRU PG?

  • È configurato forward on no answer (FONA) e a cosa è configurato FONA per reindirizzare?

  • Un gruppo di competenze predefinito è configurato con il numero di periferica 0 per separare le chiamate instradate dalle chiamate non instradate e in uscita?

Prendere i dati cronologici da queste tabelle per un giorno con le istruzioni "select *":

• Peripheral_Half_Hour

• Tipo_Chiamata_Mezz_Ora

• Mezz_ora

• Skill_Group_Half_Hour

• Dettagli_Chiamata_Terminazione

• Dettaglio_chiamata_route

Risoluzione dei problemi di Cisco CallManager

Quando si raccolgono le tracce in Cisco CallManager, è possibile ruotare i flag dalla pagina Cisco CallManager Admin in Servizi > Flag di traccia. 0xCB05 è un flag di traccia valido impostato per la traccia SDL degli errori CTI. Impostare 0xCB05 nei parametri del servizio per il debug. Per ulteriori informazioni, fare riferimento al documento Casi TAC AVVID: Raccolta di informazioni sulla risoluzione dei problemi per ulteriori informazioni. Fare riferimento alla documentazione online di Cisco CallManager, incluse le guide alla risoluzione dei problemi.

Attiva la traccia per Cisco CallManager

Per informazioni su come attivare la traccia per Cisco CallManager, fare riferimento a Configurazione delle tracce di Cisco CallManager per il supporto tecnico Cisco.

Modifica degli indirizzi IP di Cisco CallManager

Fare riferimento a Modifica degli indirizzi IP di Cisco CallManager e modifica del nome del server.

1. Eseguire il programma di installazione su Cisco CallManager PG e modificare i servizi JTAPI per Cisco CallManager PIM. Se si dispone di mobilità per le estensioni e/o servizi telefonici.

2. Arrestare il motore CRA.

3. In CRA - Modificare l'indirizzo IP in Configurazione motore.

4. Modificare IP in JTAPI.

5. Arrestare il servizio directory controller di dominio nel server.

6. Modificare l'indirizzo IP nella configurazione della directory.

7. In Cisco CallManager - modificare l'indirizzo IP in Sistema > Server.

8. Modificare l'indirizzo IP negli URL in Sistema > Parametri Enterprise.

9. Modificare l'indirizzo IP in tutti gli URL in Caratteristiche > Servizi telefonici.

10. Cambia indirizzo IP server - Proprietà rete.

11. Modificare l'opzione DHCP 150 in un nuovo indirizzo IP.

12. Modificare IP nel profilo dell'hotel in DC Directory, Cisco CallManager > Profilo di sistema > Hoteling.

13. Aprire SQL Enterprise Manager.

14. Modificare gli indirizzi IP negli URL nella tabella PlugIn.

Per eseguire il backup delle modifiche alla configurazione:

1. Aprire la configurazione stiBackup.

2. Modificare gli indirizzi IP dei server in tutte le schede appropriate.

Strumenti di debug

Procmon

Procmon è uno strumento da riga di comando che consente di eseguire il debug dei processi PIM e JTAPI GW.

• Utilizzo: procmon <nome cliente> <nodo>.

  • Procmon ipcc pg1a pim1

  • Procmon ipcc pg1a jgw1

  • Procmon ipcg1a ctisvr

Di seguito sono riportate alcune impostazioni di traccia utili per ogni processo:

• JTAPI GW (utilizzare procmon)

  • trace JT_TPREQUESTS (attiva le tracce delle richieste di terze parti)

  • trace JT_JTAPI_EVENT_USED (attiva le tracce per gli eventi JTAPI utilizzati da PG)

  • trace JT_PIM_EVENT (attiva le tracce per i messaggi di evento inviati al PIM)

  • trace JT_ROUTE_MESSAGE (attiva le tracce del client di routing)

  • trace JT_LOW* (tracce basate sui livelli JTAPI e CTI sottostanti)

• PIM (utilizzare procmon)

  • trace tp* (attiva le tracce delle richieste di terze parti)

  • traccia pre-chiamata (attiva le tracce degli eventi di pre-chiamata)

  • trace *event (attiva le tracce degli eventi agente e chiamata)

  • trace csta* (attiva le tracce degli eventi di chiamata CSTA)

• SERVER CTI (utilizzare procmon)

  • regset EMSTraceMask 0xf8 (attiva le tracce utili del server CTI, che potrebbero andare a capo)

OPCtest

Opctest è uno strumento da riga di comando per eseguire il debug del processo OPC in PG.

• Utilizzo: opctest /cust <nome cliente> /node <nodo>

  • opctest /cust ipcc /node pg1a

• Impostazioni utili

  • debug /agent (attiva le tracce degli eventi dell'agente)

  • debug /routing (attiva le tracce degli eventi di routing)

  • debug /cstacer (attiva le tracce degli eventi csta)

  • debug /tpmsg (attiva le tracce delle richieste di chiamata di terze parti)

prova

Rttest è uno strumento di interfaccia della riga di comando per eseguire il debug del processo del router sull'ICM. Vedere trtrace per la versione GUI.

• Utilizzo: rttest /cust ipcc

rtsetting.exe

GUI per modificare le impostazioni del registro del router.

• È possibile ripristinare le impostazioni predefinite.

rtrtrace.exe

GUI per attivare varie tracce del router sull'ICM.

• Impostazioni particolarmente utili per IPCC:

  • Accodamento - per problemi di rimozione dalla coda.

  • Service Control: per problemi con l'interfaccia VRU.

  • Instradamento traduzione - per problemi relativi ai percorsi di traduzione.

dumplog

Esegue il dump dei file binari Cisco ICM in file di testo. Spostarsi nella directory dei file di registro del processo.

• I file di registro dei processi OPC, PIM e JtapiGW si trovano in icr\<nome_cliente>\<nodo>\logfiles\.

• Sul PG, è presente un file batch chiamato cdlog in cui si digita >cdlog <cust> <node>.

• Utilizzo: nome processo dumplog

  • Dumplog /" (per informazioni sulle diverse opzioni duplog)

  • Duplog jgw1

  • Scarica pim1

  • Opzione duplog

vrutrace

Strumento per visualizzare il file di acquisizione VRU PG. Funziona in modo simile alla modalità dumplog.

Call Tracer

Strumento Cisco ICM che può essere utilizzato per eseguire il debug degli script di routing.  È possibile trovare questo strumento nella voce di menu AW sull'AW.

jtprefs

Questo è uno strumento per attivare le tracce JTAPI per il client JTAPI sull'IVR IP. Le tracce JTAPI sull'IPCC PG sono controllate tramite l'interfaccia procmon. Questo strumento risiede in Programmi\CiscoJapTools\.

Monitoraggio prestazioni

Strumento di amministrazione di Microsoft Windows 2000 che visualizza i dati in tempo reale per Cisco CallManager, Cisco IP IVR e ICM. È possibile visualizzare le chiamate in corso, i dispositivi registrati e l'utilizzo della CPU del processo. Questo strumento è disponibile in Start > Programmi > Strumenti di amministrazione.

File di log

File di log Cisco ICM

I file di registro Cisco ICM si trovano in \icr\<cust>\<node>\logfiles. In questo caso, il cliente fa riferimento al nome dell'istanza del cliente e ai riferimenti del nodo pg1a, ra per router, cg1a e altro ancora. Utilizzare dumplog per visualizzare i file di log.

Nota: è possibile visualizzare i file di acquisizione degli eventi con strumenti di traccia quali vrutrace. Questi file si trovano in una directory diversa.

File di log di Cisco CallManager

I file di registro di Cisco CallManager risiedono normalmente in \program files\cisco\ccm\trace con directory di traccia di:

• Ccm - Registri SDI CallManager.

• Dbl - Registri livello database.

• Sdl - Registri Segnalazione Chiamata.

• Tftp - Registri per il server tftp.

È possibile modificare le impostazioni di traccia per questi file dalla pagina di amministrazione di Cisco CallManager in impostazioni di traccia. È possibile modificare le impostazioni di traccia SDL nei parametri del servizio in Cisco CallManager.

File di log IP IVR

I file di registro IP IVR si trovano in \programmi\wfavvid. È inoltre possibile visualizzare i file di log IPIVR dalla pagina appadmin in file di trace del motore.

È possibile visualizzare i registri del client JTAPI Cisco quando si attivano gli eventi JTAPI con jtprefs.exe e si riavvia il motore IP IVR.

Dati di profilo utili

Quando si raccolgono i dati per le richieste aperte, oltre ai file di log vengono raccolti anche i dati elencati in questa sezione.

Numero di agenti

Qual è il numero di agenti configurati?

Gateway utilizzati

Quanti gateway sono configurati?

Versioni software dei componenti

Cisco CallManager, JTAPI Client, ICM, versione Gateway IOS e IP IVR.

• La versione di Cisco CallManager è disponibile nella pagina Web di amministrazione di Cisco CallManager in Guida > Informazioni su > Dettagli.

• Per trovare la versione del client JTAPI, è sufficiente digitare jview CiscoJapVersion al prompt dei comandi nella directory \winnt\java\lib in Cisco CallManager PG.

• È inoltre possibile trovare la versione IP IVR.

Tipo IVR

Che tipo di IVR è in uso?

Piattaforme

Quali tipi di piattaforme sono in uso/CPU/memoria fisica.

Informazioni correlate

• Utilizzo della Console Remote Process Monitor (Procmon)
• Come utilizzare l'utilità Dumplog
• Utilizzo dell'utilità della riga di comando OPCTest
• Utilità Cisco ICM Test
• Attivazione della traccia
• Lettura di un file di registro Drwtsn32
• Casi TAC AVVID: Raccolta di informazioni sulla risoluzione dei problemi
• Modifica degli indirizzi IP di Cisco CallManager
• Documentazione e supporto tecnico – Cisco Systems