Manual de Troubleshooting do IPCC

Introdução

Este documento fornece informações para resolver problemas do Internet Protocol Contact Center (IPCC), que se concentra no Gateway Periférico (PG) e no Cisco Intelligent Contact Management (ICM). Embora este documento contenha algumas informações sobre os problemas comuns do Cisco CallManager e Cisco Global Directory, ele não faz qualquer tentativa de descrever completamente estes componentes. Em vez disso, este documento se concentra nos sintomas e métodos para identificar o origem dos problemas que o PG vê.  Os problemas podem estar relacionados ao software ou à configuração.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Como solucionar problemas e oferecer suporte ao Cisco ICM PG

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Cisco ICM version 4.6.2

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Sintomas e ações de solução de problemas

Examine os logs do PG para IPCC. Quando você vir erros não especificados nos logs do Peripheral Interface Manager (PIM), Open Peripheral Controller (OPC) ou Computer Telephony Interface (CTI) Server, vá diretamente para o log do JTapi Gateway (GW) para obter uma descrição de texto melhor do problema. A interface JTAPI geralmente fornece exceções quando as coisas dão errado em solicitações de terceiros. Essas exceções fornecem apenas descrições de string sem código de erro. Como resultado, o servidor PIM/OPC/CTI registra muitos erros como erros não especificados.

O Cisco IPCC PIM não fica ativo

PIM Não Habilitado

Verifique a existência de um log PIM. Se não houver registro PIM, verifique se o periférico está ativado na configuração do Cisco ICM. Às vezes, o periférico é adicionado, mas você precisa ativá-lo.

Selecione Edit > Peripheral e marque a caixa de seleção Enabled.

PIM reinicia

Se o processo PIM reiniciar, visualize o registro PIM no Cisco CallManager PG com o utilitário dumplog. Se o arquivo de log indicar um erro com o OPCHeartbeatTimeout, você deverá modificar essa configuração do Registro. Use regedt32 para fazer a alteração.

Modifique OPCHeartbeatTimeout no registro em eagtpim dados dinâmicos para 10. Este é o caminho:

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

Observação: esta tecla aparece em duas linhas aqui devido a limitações de espaço.

PIM no Estado Ocioso na Janela Log do PIM

Se o processo PIM estiver em um estado ocioso, execute estas verificações:

• Verifique o log PIM. Você deve ver, "Attempt to Ativate", pelo menos uma vez por minuto.

• Se o PIM não estiver ativo, use o utilitário dumplog para verificar o log do OPC. Execute opctest para ver se o processo OPC recebe a configuração do roteador.

• Se o processo OPC não receber a configuração do roteador, use o utilitário dumplog para exibir o log do pgagent. O processo pgagent deve ter um caminho ativo para o Controlador Central. Se pgagent não tiver um caminho ativo, verifique a conectividade de rede e a configuração do DMP na configuração do PG. No roteador, use o utilitário dumplog para exibir o log do ccagent. Verifique se o dispositivo PG (ID do sistema DMP) está ativado como um dispositivo no roteador.

• Ative o PG na configuração do roteador por meio da instalação ou no registro no registro DMP.

• Em uma janela de comando, use o comando tracert para verificar a conectividade de rede entre o roteador e o PG.

  Observação: pode haver uma discrepância entre DNS e DHCP.

• Verifique se o endereço IP do roteador está no arquivo de host no diretório c:\winnt\system32\drivers\etc.

• Verifique se a ID do Controlador Lógico configurada em PG > Setup corresponde à ID do Controlador de Interface Lógico PG em Configure > ICM. Verifique se a ID do Periférico configurada para o periférico em PG > Setup corresponde à ID do periférico em Configure > ICM.

• Modifique a instalação do ICM para corresponder à configuração.

O processo JGW não fica ativo

A versão incorreta da Microsoft Java Virtual Machine (JVM) está instalada

• Vá para um prompt de comando, digite jview e pressione ENTER. As informações sobre a versão Java instalada são exibidas:

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

• Se você não vir essa saída, ou se a versão for anterior à 3190, você deverá instalar a versão correta do Microsoft JVM. Execute msjavx86.exe. Este arquivo é instalado no diretório icr\bin durante a instalação.

O classpath Java está incorreto

• Em um prompt de comando, vá para o diretório icr\bin, digite jtapigw e pressione ENTER.  Uma resposta semelhante a esta aparece:

  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)

• Alternativamente, esta mensagem é exibida:

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

• Se você vir a segunda mensagem quando executar jtapigw, verifique o classpath Java.  Use o editor de registro para examinar o valor Classpath sob a chave SOFTWARE\Microsoft\Java VM.  Defina a chave desta forma:

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

Observação: a letra da unidade e o diretório de sistema do Windows podem diferir e os caracteres após as classes e antes de c:\icr... são: ponto e vírgula, ponto e ponto e vírgula.

Cliente Cisco JTAPI não instalado no PG

• Em um prompt de comando, vá para o diretório icr\bin, digite jtapigw e pressione ENTER.  Uma resposta semelhante a esta aparece:

  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)

• Em vez das mensagens acima, você pode ver esta mensagem:

  Java.lang.NoClassDefFoundError

• Se você vir algo como a segunda mensagem quando executar jtapigw, verifique se o cliente Cisco JTAPI está instalado no PG. Procure o arquivo CiscoJtapiVersion.class em c:\winnt\java\lib.

• Se esse arquivo não existir, você pode instalar o arquivo no PG a partir do Cisco CallManager; http://<callmanager name>/main.asp. Você pode localizar o arquivo na guia do aplicativo.

O registro JTAPI GW reclama sobre a versão incompatível do JTAPI

• Se você instalou somente o JTAPI 4.1 service pack (SP) 4 com qualquer hot fix inferior a 50 no Cisco CallManager PG, será necessário atualizar.

• Se você acabou de executar ICM > Setup para atualizar o PG, verifique se a data/hora no arquivo \icr\bin\icrjavalib.zip mostra uma data atualizada. A data deve ser aproximadamente a mesma que a data/hora no arquivo bldXXXXX.version, dentro de aproximadamente um dia.

Observação: a Instalação não poderá atualizar este arquivo se ele estiver em uso quando você executar a Instalação. Essa situação pode ocorrer se você tiver um navegador de Internet aberto, pois o navegador trata o arquivo zip como um diretório para o caminho de classe se o navegador abrir o zip. Para evitar esse problema, feche todas as sessões do navegador antes de executar a Instalação.  Se a Instalação não puder atualizar o arquivo, uma mensagem será exibida e o instruirá a reinicializar o computador para atualizar os arquivos. Você deve reinicializar.

JTAPIGW não pode se conectar ao Cisco CallManager

• O PIM se comunica com o Gateway JTAPI (JTAPIGW) e o JTAPIGW se comunica com o Cisco CallManager. À medida que o PIM tenta se tornar ativo, o PIM informa ao JTAPIGW para inicializar comunicações com o Cisco CallManager através do JTAPI.

• Você deve ver mensagens que indicam que o JTAPIGW aceitou uma conexão do PIM e os contatos getProvider(), por exemplo:

  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()

  Observação: este exemplo aparece em várias linhas devido a limitações de espaço.

Se você não vir o rastreamento retornado com êxito, poderá ver outros erros após a chamada a getProvider().  O trace para getProvider() mostra os parâmetros usados para inicializar JTAPI.  O primeiro parâmetro é o nome do serviço, que é o nome do host IP ou o endereço IP da máquina Cisco CallManager.  Neste exemplo, o endereço IP é usado.  Se um nome for usado, o PG deverá ser capaz de resolver o nome através de um arquivo de host ou DNS.  Certifique-se de que você possa fazer ping no nome ou no endereço.  Se precisar alterar o nome do serviço, execute novamente ICM > Configuração e altere o nome na caixa de diálogo Editar Periférico.

O rastreamento da chamada para getProvider() também mostra o nome de logon usado. Observe que o rastreamento não mostra a senha. O nome de logon e a senha são obtidos do que o administrador digita em ICM > Setup. Eles devem corresponder a um usuário e uma senha válidos configurados no diretório e administrados na página da Web Preferências do Usuário da Cisco para ter a capacidade de controlar cada um dos dispositivos do agente e pontos de rota. Verifique se o nome e a senha estão corretos em ICM > Setup. Configure o usuário no diretório para ter permissão para controlar apenas dispositivos do agente e pontos de rota válidos.

O registro JGW indica um host desconhecido

O processo JTAPI GW não pode resolver o endereço do Cisco CallManager. Configure o parâmetro de serviço na caixa de diálogo PIM em Setup com o nome de host ou endereço IP do Cisco CallManager. Se a configuração do nome do host para o Cisco CallManager estiver correta, certifique-se de que você pode fazer ping no Cisco CallManager. Caso contrário, use o endereço IP do Cisco CallManager, em vez do nome do host.

Log JGW Indica Senha ou Usuário Inválido

O JTAPI GW se conecta ao Global Diretory com um nome de usuário e uma senha. O nome de usuário e a senha na caixa de diálogo PIM na configuração devem corresponder ao nome de usuário e à senha do usuário configurado no diretório global na página da Web de administração do Cisco CallManager em ccmadmin > Usuário > Diretório global.

Se o usuário não existir, adicione um novo usuário. Certifique-se de marcar a caixa de seleção CTI Enabled na parte inferior da página.

Caixa de seleção CTI não ativada na página do usuário do diretório global

Uma caixa de seleção na página de usuário do diretório global do Cisco CallManager pode ativar ou desativar os privilégios CTI para um usuário PIM ou IP IVR. Você deve marcar e atualizar esta caixa de seleção para que o GW PIM/JTAPI seja ativado. Esta caixa de seleção garante que dois dispositivos CTI não possam se conectar ao Cisco CallManager, o que pode causar problemas (o limite padrão é 400).

O serviço Cisco CallManager não é executado

• No Cisco CallManager versão 3, este serviço mostra no controle de serviço como "Cisco CallManager". Inicie o serviço.

• O serviço Cisco CallManager normalmente é configurado para ser reiniciado se sair de forma anormal, mas você pode configurá-lo como "desligado" para possíveis problemas com a migração de dispositivos em cenários de failover.

• Verifique o registro de eventos para ver se o serviço Cisco CallManager é reiniciado. O sistema às vezes reinicia se identificar um problema com o uso adequado da CPU. O sistema relata erros ou avisos no registro de eventos que indicam um "thread de temporizador SDL lento". Com esse tipo de erro, o Cisco CallManager é reiniciado. Esta versão do Cisco CallManager é executada em prioridade normal para que outros aplicativos executados no sistema possam interferir no sinal de chamada.

• Quando a memória física é menor ou o sistema encontra outros problemas de temporização, o Cisco CallManager pode apresentar um erro que indica que ele não pôde ser inicializado após um tempo limite de 10 minutos e reiniciado. Há um serviço de componente DCOM para a camada de banco de dados (DBL) do Cisco CallManager que apresenta um problema de inicialização. Pare e inicie este serviço DBL DCOM por meio de serviços de componentes - componentes DCOM para resolver este problema.

  Observação: isso não é o mesmo que um serviço de sistema como o Cisco CallManager.

  Abra um caso no Cisco Technical Assistance Center (TAC). Isso provavelmente pode ser um problema na próxima vez que você reiniciar o sistema, a menos que resolva o problema de temporização subjacente.

Problemas de diretório (configuração, não execução, senha de diretório)

O serviço de diretório não é executado

• Confirme se o serviço de diretório está ativo e funcionando corretamente.  Por padrão, este é o DC Diretory Server no controle de serviço na máquina do Cisco CallManager. Tente iniciar a máquina. Você pode encontrar erros.

• O Serviço de Diretório poderá entrar em um estado de pausa se o sistema ficar sem memória ou espaço em disco. Os erros são exibidos no registro de eventos do Microsoft Windows 2000. Resolva problemas de recurso e reinicie o serviço de diretório, se necessário.

A página do usuário da Web do Cisco CallManager não funciona

Verifique se a página da Web do usuário do Cisco Global Diretory pode realmente exibir e configurar usuários e atribuir permissões a dispositivos de controle. O JTAPIGW e a página da Web usam o Cisco CallManager para acessar o servidor de diretório para acessar usuários e permissões. Se o problema com o JTAPIGW for devido a um problema no servidor de diretórios, a página da Web do usuário também poderá ter problemas. As possíveis razões são que o servidor de diretório não é executado ou o diretório não está configurado corretamente, se for o caso.

Servidor de Diretório Não Instalado

Para usar o Cisco CallManager 3.0.5 e posterior, você deve instalar um servidor de diretório. O Diretório DC AVVID é o padrão disponível nos CDs de instalação Spirian. Depois de instalar o servidor de diretório, a instalação do Cisco CallManager configura o diretório.

Você deve executar esta instalação corretamente, e o servidor de diretório deve estar ativo e deve ser executado corretamente para que o JTAPIGW faça login no Cisco CallManager e use o JTAPI.

Certifique-se de que o DC Diretory Service e o Cisco CallManager sejam executados corretamente.

Ao instalar o Cisco CallManager, você deve digitar "ciscocisco" quando vir o prompt de senha do gerenciador de diretórios. Se você inserir qualquer outra informação, talvez tenha que remover o DC Diretory Software (Adicionar/Remover) e reinstalar. Se o processo de remoção informar que alguns arquivos não podem ser removidos, você deverá remover ou renomear manualmente o diretório c:\dcdsrvr atual.

Servidor De Diretório Instalado, Mas Não Executado

Verifique o painel de controle para confirmar se o serviço não pode ser iniciado. Em seguida, verifique se o administrador está configurado e se o logon e a senha estão corretos para o serviço no campo Propriedades.

O servidor de diretório foi instalado e executado, mas não pode efetuar login com a ferramenta DCD Admin

Inicie o DC Diretory Admin no menu Iniciar do sistema. Efetue login com o seu usuário Diretory Manager com a senha "ciscocisco" (padrão) ou qualquer outra senha que o administrador tenha configurado. Se você receber um erro indicando que o usuário não está configurado, execute um dos arquivos de configuração do Cisco AVVID no diretório DCDSrvr\bin. Se este for o Cisco CallManager, Editor primário, execute avvid_cfg.cmd a partir do prompt do DOS. Se este for um Cisco CallManager secundário, execute avvid_scfg.cmd no prompt de comando.

Se você vir erros que indiquem que isso já está configurado, o usuário existe. Se não houver erros, as coisas devem começar a funcionar corretamente agora. Volte e verifique o acesso nas páginas de Usuário do Diretório Global em ccmadmin.

Observação: o DC Diretory entrará no modo de pausa se o diretório estiver com poucos recursos do sistema.

O agente não pode fazer logon

Este exemplo usa um exemplo de configuração do ICM para um destino de dispositivo:

Amostra de destino do dispositivo
Nome da empresa	Agente9782755100
Endereço global	Agente9782755100
ConfigParm	/devtype TelefoneCisco /dn 9782755100

O próximo exemplo usa um exemplo de configuração do ICM para um agente:

Amostra de agente
Periférico	CCMPG_PIM1
Número do Periférico	1234
Senha	XXX

Ao executar ICM > Setup para o PG, especifique um comprimento de ramal de agente igual a "4". Portanto, na configuração de exemplo, a extensão do dispositivo de exemplo são os 4 últimos dígitos do parâmetro /dn (por exemplo, "5100").

Tente fazer login com CTITest.

Se você não conseguir fazer logon de um agente com o softphone, tente a mesma operação através do ctitest . Esta é uma lista de exemplo de comandos ctitest que você pode usar para fazer login no agente de amostra para o alvo do dispositivo de amostra. Esta lista de comandos pressupõe que o servidor CTI escuta na porta 42027 na máquina CTIServerA. Esta lista também pressupõe que o dispositivo é uma extensão para o periférico representado como periférico 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

Servidor PIM e CTI Inativo no OPC

Use o comando opctest "status" e confirme o PIM do IPCC e a exibição do servidor CTI nos estados PIM_ATIVE e CTI_ATIVE. As barras de título das janelas de log do PIM e do servidor CTI também indicam o estado do processo.

O cliente CTI não pode se conectar

Verifique as configurações para se conectar ao servidor CTI. Para o softphone do desktop, as configurações estão no arquivo .ini (geralmente c:\arquivos de programas\geotel\cti desktop\cticonfig.ini). As configurações a serem verificadas incluem:

• PeripheralID — Este valor deve corresponder ao ID do periférico do IPCC em Configure > ICM.

• SideAHost — Esse valor deve ser o nome do host IP ou o endereço do lado A do servidor CTI.

• SideBHost — Este valor deve ser o nome do host IP ou o endereço do lado B do servidor CTI.  Se o servidor CTI for simplificado, você poderá deixar esse campo em branco.

• SideAPort — Este valor deve corresponder à porta na qual o servidor CTI no lado A escuta conexões. Este valor é especificado na Instalação do ICM para o Servidor CTI. O servidor CTI mostra essa porta na barra de título e registra esse valor quando o servidor CTI é iniciado. Verifique se o cliente pode fazer ping no servidor CTI.

O Cliente CTI Obtém Erro Indica que o Agente Precisa estar Conectado ao ACD

Execute o setup.exe que reside no diretório \icr\bin no servidor PG/CTI. Selecione o componente Gateway CTI. Verifique se a caixa de seleção Logon do agente necessário está desmarcada. Esta seleção de caixa de seleção não se aplica a aplicativos do IPCC ou de controle de terceiros. A finalidade dessa caixa de seleção é monitorar aplicativos e outros agentes do ACD.

O registro PIM mostra um destes erros de logon

Use procmon para o pim e "trace tp*" para ativar o rastreamento de terceiros (diferencia maiúsculas de minúsculas). Isso deve mostrar a solicitação de logon. Verifique se os parâmetros estão corretos. O instrumento é rastreado como "Device=". Esse valor deve corresponder à string /dn no configparam de destino do dispositivo. A ID do agente é rastreada como "AgentID=". Esse valor deve corresponder ao número do periférico do agente em Configurar/ICM.

• INVALID_PASSWORD

  Verifique se a senha está correta (a senha pode não ser rastreada como texto não criptografado). Se a senha estiver incorreta, o registro deverá mostrar um erro INVALID_PASSWORD_SPECIFIED.

• OBJETO_INVÁLIDO

  Indica que os parâmetros de configuração no Destino do Dispositivo contêm um tipo de dispositivo inválido. Este erro aparece assim com espaços entre as palavras-chave:

  /devtype CiscoPhone /dn 9782755100

• INVALID_DEVICE_TARGET

  Indica que algo no Destino do dispositivo é inválido, provavelmente algo no campo de parâmetros de configuração. Com o utilitário dumplog, exiba o log PIM pela última vez em que o PIM foi reiniciado. O log valida os destinos de dispositivo e registra erros quando as cadeias de caracteres de configuração de destino de dispositivo são inválidas.

O log JGW mostra erros de login

Verifique o log jgw para quaisquer erros que ocorram em tentativas de login. Use procmon para o PIM e "trace *TP*" para ativar o rastreamento de terceiros (diferencia maiúsculas de minúsculas). Procure a linha, "MsgAddCallObserver: Addr: XXXX", onde XXXX é o ramal no qual você tenta fazer login. Esse ramal deve ser um ramal válido do Cisco CallManager em um dispositivo que o usuário PG tenha permissão para controlar. O ramal deve ter o número correto de dígitos para o telefone, como o Cisco CallManager sabe. Em outras palavras, o ramal deve ser o número que você disca de outro telefone no mesmo Cisco CallManager para acessar o telefone em questão.

Dispositivo Fora do Domínio do Provedor

Se o log JGW mostrar uma exceção, indicando que o dispositivo não está no domínio do provedor, o telefone não está associado ao usuário com o qual o JTAPI GW faz login. Verifique se o ramal na extremidade da lista de associação de dispositivos de usuário do Global Diretory está correto. Verifique também se o número de linha do dispositivo não está registrado duas vezes. A aparência de linha compartilhada é um recurso do Cisco CallManager que não é suportado pelo IPCC. Você pode tentar configurar inadvertidamente uma aparência de linha compartilhada com dois telefones que tenham a mesma linha. Se você alterar um número de linha, o outro muda e o PG não consegue se conectar ao dispositivo correto. Para resolver esse problema, exclua ambas as linhas e adicione-as ao Cisco CallManager.

INVALID_SKILL_GROUP_SPECIFIED

Para fazer logon, um agente deve ser configurado em Configurar/ICM como um membro de pelo menos um grupo de habilidades (Membro do Grupo de Habilidades).

O agente já fez logon em outro telefone

Verifique se o agente (como o Número de periférico do agente representa) já não está conectado a outro destino de dispositivo. Uma forma de verificar isso é executar o Monitor ICR e executar o relatório Free from Agent para o agente em questão. Se o agente estiver conectado, será exibida a ID de destino de rede do destino de dispositivo no qual o agente está conectado. Os dados do agente serão exibidos no awdb somente se você tiver configurado o ICM para enviar dados do agente para o periférico a este AW.

• Você também pode consultar isso em isqlw na tabela Agent_Real_Time do awdb. Primeiro, localize o destino de habilidade do agente (por exemplo, selecione * em Agente onde PeripheralID = XXX e PeripheralNumber = YYY). Em seguida, verifique se o agente está conectado (por exemplo, selecione * em Agent_Real_Time onde SkillTargetID = XXX).

• Você também pode verificar isso ao se conectar a procmon para PIM e executar dagent <número periférico do agente>.

Destino do Dispositivo Já Conectado

Verifique se o destino do dispositivo (conforme especificado pelo instrumento) já não tem outro agente conectado.

• Uma forma de verificar isso é executar o isqlw na tabela Agent_Real_Time do awdb. Primeiro, localize a ID do destino de rede para o destino de dispositivo em questão. Por exemplo, selecione * em Device_Target onde ConfigParam como ‘%1003%’. Agora, verifique se o destino do dispositivo está conectado. Por exemplo, selecione * em Agent_Real_Time, onde NetworkTargetID = XXX.

• Você também pode verificar isso ao se conectar a procmon ao PIM e despejar o destino do dispositivo. Há duas maneiras de fazer o dump do destino do dispositivo. O comando ddt usa um ID de destino de rede como entrada e despeja o destino do dispositivo. O comando deadt obtém a string /dn da configuração de destino do dispositivo como entrada e despeja o destino do dispositivo. Por exemplo, se a string device target /dn for /dn 9782755100, você despeja o destino do dispositivo como deadt 9782755100.

Dispositivo não associado ao usuário PG

Vá para a página da Web do Cisco CallManager, selecione User/Global Diretory e localize a ID de usuário que o PG usa. Verifique os "Dispositivos Associados" e certifique-se de que o usuário tenha permissão para controlar o dispositivo.

• Se você não conseguir localizar o dispositivo na página do usuário (marcada ou desmarcada), pode haver um problema com a sincronização entre o banco de dados (onde o Cisco CallManager armazena os dispositivos) e o servidor de diretório (que armazena os dispositivos e os perfis de usuário). Verifique se o servidor de diretórios (DC Diretory Server) está em execução.

• Verifique o log do aplicativo Visualizador de Eventos do Windows NT e procure erros no diretório DC ou no metalink. Se ocorrerem erros de importação, execute avvid_recfg em c:\dcdsrvr\bin.

• Certifique-se de que o Microsoft Java Virtual Machine (JVM) esteja instalado na máquina do Cisco CallManager. Para testar isso, digite jview em um prompt de comando. Para o Cisco CallManager 2.4, você deve instalar a JVM manualmente. Para o Cisco CallManager 3, a plataforma é Windows 2000 e a instalação da JVM é automática.

Dispositivo de telefone inativo

Verifique se o telefone está ligado, registrado com o Cisco CallManager e capaz de fazer e receber chamadas do telefone sem controle do agente.

O agente não pode fazer a chamada

Agente em estado Não Pronto

Verifique se o agente está conectado e não no estado Disponível.  Se o agente não estiver Disponível, ele não poderá fazer uma chamada. Para fazer uma chamada, primeiro clique em Não pronto.

Configurações de mesa do agente incorretas

Se houver um erro somente quando você discar determinados números, verifique esses números de um telefone físico para certificar-se de que você pode discar com êxito. Se você configurou um plano de número discado do ICM, verifique se o número discado corresponde a um dos curingas em seu plano de número discado. Em seguida, verifique se as configurações de mesa do agente permitem que o agente disque o tipo de número que a entrada do plano de número discado identifica (por exemplo, Internacional).

Plano de número discado em PIM bloqueia o acesso

O plano do número discado configurado para cada PIM pode ser configurado incorretamente ou corretamente para impedir que um agente faça chamadas para um determinado número. O erro no log PIM deve indicar um erro de permissão. Os números de agentes e dispositivos não podem se sobrepor quando o plano de número discado é usado para fazer chamadas de agente para agente.

O Agente Faz Uma Chamada Curta, Tem Que Esperar Para Fazer Uma Nova Chamada

O Roteador torna o agente indisponível quando o agente faz uma chamada ou quando uma chamada é roteada para o agente. Esse mecanismo permite que o Roteador roteie outra chamada para o agente antes que o PIM relate que a chamada chegou. Algumas redes levam vários segundos para realmente rotear a chamada. O Roteador não cancela o timer com base no estado do agente.

Se o tempo real levado para rotear chamadas para o PIM do cliente de roteamento for relativamente curto, você poderá alterar o tempo configurável no roteador. Em um dos roteadores em uma janela de comando do DOS, use rtsetting.exe. Procure em Extrapolation > Agent. A configuração padrão é 10 segundos. Se o valor for muito curto, o Roteador roteará as chamadas para os agentes que estão prestes a receber uma chamada. Isso faz com que o PIM descarte chamadas.

O tempo limite padrão no PIM é de 7 segundos. Você pode modificar esse valor com o comando regedt32. Adicione a chave "AgentReserveTimout" neste caminho:

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

Observação: essa chave será adicionada na configuração da versão 4.1.5.

Observação: esta tecla aparece em duas linhas aqui devido a limitações de espaço.

O número PIM deve ser sempre alguns segundos menor que o temporizador de extrapolação do Roteador para impedir que o Roteador envie novos eventos de pré-chamada para o PIM antes que o evento original seja processado. Isso causa problemas no PIM.

Se a chamada for recebida após o tempo limite do PIM, ela será considerada uma chamada não ACD e nenhuma das informações de variáveis de contexto, serviço ou grupo de habilidades será atribuída à chamada.

O agente não pode ir — Não pronto, ocupado ou outro

Agente no estado "Ativo"

Se o agente estiver em uma chamada e clicar em Não pronto, Ocupado ou Outro, o estado do agente não será alterado imediatamente. Isso é intencional. O agente permanece no estado Conversa ou Em espera até a conclusão da chamada. O agente faz a transição para Não pronto, Pronto para trabalho ou Não pronto para trabalho, dependendo do botão que está sendo pressionado. Se, após o término da chamada, o agente passar imediatamente para Disponível, você deverá verificar as configurações de mesa do agente para o agente e ver se Disponível após Entrada ou Disponível após Saída estão definidas. Essas configurações substituem as tarefas que o agente executa com os botões durante uma chamada.

Configurações de mesa do agente impedem a transição

Verifique as configurações de mesa do agente para o agente em Configurar o ICM e veja se Razão de Ociosidade Necessária está marcado. Se a caixa de seleção estiver marcada, o agente não poderá entrar no estado Não pronto sem um código de razão. Modifique o Desktop_Settings.cfg para corresponder à configuração de mesa do agente em Configurar ICM ou altere a configuração de mesa do agente em Configurar ICM.

Se não houver nenhuma configuração de área de trabalho do agente atribuída ao agente, o agente poderá fazer logon e ficar pronto, mas não poderá ir para não_pronto ou fazer logoff. A solução é fechar o aplicativo do agente, atribuir uma configuração de área de trabalho do agente e fazer logon novamente.

O agente precisa aguardar para não ficar pronto

O Roteador torna o agente indisponível quando o agente faz uma chamada ou quando uma chamada é roteada para o agente. Esse mecanismo permite que o Roteador roteie outra chamada para o agente antes que o PIM relate a chamada como recebida. Algumas redes levam vários segundos para realmente rotear a chamada. O Roteador não cancela o timer com base no estado do agente.

Se o tempo real levado para rotear chamadas para o PIM do cliente de rota for relativamente curto, você poderá alterar o tempo configurável no roteador. Em um dos roteadores em uma janela de comando do DOS, use rtsetting.exe. Procure em Extrapolation > Agent. O padrão é 10 segundos. Se o valor for muito curto, o Roteador roteará as chamadas para os agentes que estão prestes a receber uma chamada. Isso faz com que o PIM descarte chamadas.

O agente não consegue ficar pronto

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

Há uma inconsistência nos dados da solicitação de logon e da solicitação pronta. Possivelmente, o instrumento, a ID do agente ou os números de periféricos não correspondem. Ative o rastreamento do servidor CTI com procmon e defina regset como 0xf8 para ver os rastreamentos apropriados. Você também pode exibir isso nos logs OPC ou PIM, se o rastreamento de terceiros (TP) estiver ativado.

O agente não consegue desconectar

O estado atual do agente impede que a chamada seja feita

Se o agente estiver em um estado Pronto para trabalho, Não pronto para trabalho ou Disponível, ele deverá primeiro ir para Não pronto antes de fazer logoff. Modifique Desktop_Settings.cfg para corresponder à configuração de mesa do agente em Configurar ICM ou altere a configuração de mesa do agente em Configurar ICM.

Configurações de mesa do agente impedem alterações de estado

Se o agente estiver no estado Não pronto e ainda não conseguir fazer logoff, verifique as configurações de mesa do agente para o agente em Configurar ICM e veja se a opção Motivo do logoff necessário está marcada.

O agente mostra chamada ativa ou conversação, mas não há chamada no telefone

Fazer logoff e logon do agente

Se o softphone mostrar uma chamada que não está mais fisicamente presente, o estado do agente poderá ficar preso em Conversando ou Em Espera e o agente não poderá fazer logoff. Isso pode ser devido a um bug de software no JTAPI ou no PIM. Para limpar a condição, primeiro tente limpar a chamada do softphone se o botão de liberação estiver habilitado. Se isso não funcionar, tente fazer logoff do agente. Se o botão de logout não funcionar, saia e reinicie o softphone. Se a condição persistir, saia do softphone, execute o Gerenciador de Tarefas, execute kill geodcs.exe e common~1.exe e reinicie o softphone. Esses processos podem continuar a ser executados e lembrar o estado de agente inválido.

Agente em estado incorreto no PIM

Em procmon , verifique o estado do agente no PIM. Se você reiniciar a área de trabalho do agente e a condição não for limpa, há mais medidas que podem ser tomadas. O servidor CTI e o OPC fornecem mecanismos para limpar chamadas com a interface de depuração de procmon ou opctest . Esta é uma opção um pouco preferida à outra opção, que é a de alternar o serviço PG ou, pelo menos, fechar a janela PIM.

Chamadas Limpas Logo Após o Alerta ou Estabelecido

Configurações do Registro Incorretas

Com regedt32, verifique estas configurações do Registro:

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

Observação: essas chaves de registro aparecem em duas linhas aqui devido a limitações de espaço.

Defina esses valores como 300 e 28800, respectivamente.

O pós-roteamento não funciona

Verifique a rota e o script da rota

Use a ferramenta AW Call Tracer para verificar se a chamada chega ao script e o script é executado corretamente. Execute o Editor de Scripts e monitore o script. Verifique se há problemas nos registros do Roteador, do OPC e do PIM. A maioria dos erros de rota é rastreada incondicionalmente.

'Usar Mapa de Rótulo de DN' Verificado para Cliente de Roteamento de Periférico

Há uma configuração para cada cliente de roteamento em Configurar o ICM rotulada "Usar DN/Mapa de Rótulos". Se essa configuração for definida como "Sim", você precisará configurar uma entrada "Rótulo do número discado" para cada combinação de número discado e possível rótulo de destino. Essa configuração não é útil em clientes de roteamento PG e deve ser definida como "Não".

Nenhum Rótulo Configurado para o Destino de Dispositivo Roteado

Verifique o rótulo configurado no cliente de roteamento. Você deve configurar o Rótulo em cada cliente mesmo que o rótulo seja idêntico em cada cliente.

O ponto de rota CTI não está configurado no Cisco CallManager

Para usar o Post Routing, você deve configurar um "CTI Route Point" no Cisco CallManager e atribuir uma linha ao ponto de rota com o número de diretório desejado (por exemplo, "5000"). Para chamadas do agente para pós-roteamento, use o plano do número discado. Um agente que disca para o Cisco CallManager CTI Route Point confunde o softphone do IPCC no CTI Desktop versão 4.1.9.

O dispositivo para o ponto de rota CTI não está na lista de dispositivos controlados pelo usuário PG

Você deve adicionar o dispositivo CTI Route Point à lista de "Dispositivos Associados" do usuário PG na página da Web do usuário do Cisco CallManager no diretório global. Se você criar um novo dispositivo, adicione a(s) linha(s) primeiro e depois adicione o dispositivo à lista "Dispositivos associados" do usuário. Se você adicionar mais linhas a um dispositivo que já existe na lista de dispositivos do usuário, será necessário reiniciar o JGW para que o JGW reconheça as novas linhas. No entanto, se você adicionar um novo dispositivo, adicionar uma linha ao dispositivo e, em seguida, adicionar o dispositivo à lista de dispositivos do usuário, o JGW deverá ser capaz de reconhecer o novo dispositivo (dentro de cerca de 30 segundos).

Nenhum número discado configurado no Cisco ICM

Verifique o número discado para certificar-se de que o número esteja configurado para o cliente de roteamento de periféricos. Execute procmon para JGW e ative o rastreamento como "trace *ROUTE*" (diferencia maiúsculas de minúsculas). Verifique o log JGW quanto a erros que pertencem ao número discado. Na inicialização, o JGW tenta registrar um retorno de chamada de rota para o número discado. Quando uma chamada é feita para o número discado, o gateway recebe um "RouteEvent".

Junto com o número discado, verifique se o tipo de chamada foi criado e mapeado corretamente para o script.

Verificar se não é necessário reiniciar o JGW

Se você configurou um número discado do ICM, configurou o ponto de rota CTI e o adicionou à lista de dispositivos do usuário, mas ainda não recebeu solicitações de rota quando o número foi discado, talvez seja necessário reiniciar o JGW (ou executar o ciclo do PG). Você só precisa reiniciar se ativou o rastreamento no JGW (trace *ROUTE*) e se vir erros que mostram que o endereço não está no provedor. Geralmente, o JGW deve ser capaz de reconhecer novos pontos de rota CTI que são adicionados à lista de dispositivos do usuário sem a necessidade de reiniciar. Além disso, se as linhas forem adicionadas a um ponto de rota CTI que já existe, o JGW não as reconhecerá sem a necessidade de reiniciar. Você deve ser capaz de evitar uma reinicialização se adicionar um novo ponto de rota CTI para cada número discado em vez de novas linhas para dispositivos que já existem.

Observação: isso pressupõe que DeviceListPolling esteja ativado no arquivo JTAPI.ini no diretório winnt\java\lib no PIM. Se DeviceListPolling estiver desativado, você deverá ativar DeviceListPolling. Se DeviceListPolling estiver desativado e você adicionar qualquer dispositivo à lista de usuários, será necessário desligar o PG ou pelo menos o JTAPI GW para que o PG veja o novo dispositivo.

Verificar Logs OPC para Caixas de Diálogo de Rota

Use opctest para ativar o rastreamento de rota "debug /routing" e verificar os logs OPC para erros quando as chamadas são feitas para o ponto de rota. Verifique se as solicitações de rota estão sendo recebidas e se as etiquetas foram retornadas. As solicitações de rota aparecem como mensagens "CSTA_ROUTE_REQUEST" e "ICR_NEW_CALL_REQ". Os rótulos retornados aparecem como mensagens "ICR_CONNECT". Se ocorrerem erros, você poderá ver mensagens "ICR_DIALOG_FAIL" em vez de mensagens "ICR_CONNECT". Nesse caso, verifique se há erros no registro do roteador.

Verificar caixas de diálogo de roteamento nos logs do roteador

Use rtsetting.exe para ativar o rastreamento de rota e verificar os logs do roteador em busca de erros quando as chamadas são feitas para o ponto de rota.

Verifique se todos os rótulos necessários estão configurados. Se o script de rota tiver como destino agentes IPCC/EA, você deverá ter rótulos configurados para o cliente de pós-roteamento para cada destino de dispositivo de destino.

O script de roteamento não remove a chamada da fila quando o agente se torna disponível

Verifique se há erros no registro do roteador. Se não houver:

Nenhum erro no log do roteador — o nó da fila está na fila para a prioridade base do grupo de habilidades

Se o nó da fila enfileirar até a prioridade base, nada acontecerá quando o agente se tornar disponível. Há duas opções para corrigir esse problema:

• Há uma configuração do Registro do roteador chamada AutoLoginBase (use rtsetting.exe). Altere essa configuração para permitir que a chamada seja enfileirada para o grupo de habilidades base para funcionar mais ou menos como esperado. Não há preferência por habilidades primárias em vez de secundárias quando esse tipo de enfileiramento ocorre.

• Enfileirar explicitamente para os conjuntos de habilidades principal e/ou secundário no nó da fila.

Log do Roteador Indica Rótulo Não Configurado para Destino

Configure o rótulo para o destino do dispositivo em questão e todos os outros destinos para os quais este cliente de roteamento pode rotear. Use a ferramenta de configuração em massa AW para obter uma maneira mais eficiente de fazer isso em relação à configuração do ICR.

Tocar sem resposta ouvido quando todos os agentes e portas de fila estão ocupados

Verificar logs do roteador

• Os erros de rota devem ser rastreados incondicionalmente.

• Você pode usar a ferramenta rastreador de chamadas para testar o caminho da rota.

• Use rtrtrace para ativar o rastreamento de solicitação de rota e verificar se há erros nos logs do roteador quando as chamadas são feitas para o ponto de rota.

• Verifique se todos os rótulos necessários estão configurados. Se o script de rota tiver como destino agentes IPCC/EA, você deverá ter rótulos configurados para cada destino de dispositivo de destino. Cada destino de dispositivo deve ter rótulos configurados para cada cliente de rota que tente enviar chamadas. Portanto, se uma chamada for pré-roteada da rede diretamente para um agente disponível, o cliente de roteamento de rede deverá ter um rótulo para o destino do dispositivo associado. Se a chamada for primeiro enfileirada em uma URV e depois entregue ao agente, o cliente de roteamento da URV deverá ter um rótulo para o destino de dispositivo associado.

Certifique-se de que o Mapeamento de Rótulo de DN esteja Desativado no Cliente de Roteamento em Configurar ICM

Certifique-se de que Usar DN/Mapa de rótulo não esteja marcado na guia Cliente de roteamento no Gerenciador de configurações/PG Explorer.

Verificar Logs PIM

• Use procmon para ativar o rastreamento no PIM (trace precall, trace *call_event*) e verifique os logs. A mensagem de pré-chamada é exibida no Roteador. Você também verá "DeliveredEvent" com "DevTgDevStr" definido como o ramal do agente. Se a chamada não aparecer, verifique se o rótulo está correto para o cliente de rota.

As transferências arbitrárias produzem resultados inconsistentes

O IPCC não suporta a opção de colocar uma chamada em espera e fazer uma nova chamada porque o Cisco CallManager fornece resultados inconsistentes. Isso é considerado um aprimoramento do produto e pode ser considerado para uma versão futura.

Alternar não funciona

Quando uma chamada de consulta é comutada/alternada/em espera/recuperada, o Cisco CallManager interrompe a associação de consulta. Isso resulta em um cenário de transferência arbitrária que não é suportado. Os agentes podem se reconectar ao cliente e iniciar uma nova consulta. O softphone do IPCC desabilita o botão alternativo até que ele seja resolvido, mas fornecedores terceirizados podem reclamar.

A parte que participou da conferência não pode fazer conferência em outra parte

O Cisco CallManager tem uma limitação de que somente o iniciador da conferência pode adicionar mais participantes à conferência. Outros interlocutores não podem adicionar mais interlocutores no Cisco CallManager.

Estação de agente fez logout inesperadamente

Temporizador de inatividade das configurações de mesa do agente

Nas configurações de Mesa do agente, há uma configuração de tempo para fazer logoff de agentes no estado Não pronto. O tempo máximo de inatividade é de 2 horas, mas você pode configurá-lo para ser menor. Os agentes no estado Disponível não serão desconectados enquanto estiverem no estado de inatividade. O agente faz a transição de Pronto para Não pronto se o temporizador de toque sem resposta expirar (também uma configuração de mesa do agente configurável).

Tempo Limite de Pulsação do Servidor CTI

O servidor CTI possui um tempo limite de pulsação configurado. Computadores mais antigos, servidores CTI sobrecarregados ou redes com problemas de largura de banda podem ser a causa principal. Os logs do servidor CTI devem relatar um erro no log.

O agente não se comporta como configurado nas configurações de mesa do agente

As configurações de mesa do agente em Configurar ICR(M) e o arquivo de configuração do agente têm que concordar sobre como o agente é tratado.

Há um temporizador de trabalho na configuração do periférico no ICM em Parâmetros de Configuração. Defina os parâmetros como \WORKTIMER 30 para definir um atraso de 30 segundos para disponibilidade automática.

O arquivo de configuração da área de trabalho reside em:

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

O modo de trabalho em Entrada deve ser definido como Obrigatório, não Obrigatório com Dados em Desk_Settings.cfg e nas configurações de mesa do agente do ICR(M). Obrigatório com Dados substitui a opção de disponibilidade automática.

Falha nas Transferências de Consulta

Examine o log JTAPI GW e veja se há erros que indiquem por que a transferência de consulta falha. Verifique se o software do agente permite colocar em espera/recuperar ou operações alternativas na chamada de consulta. Quando qualquer uma das chamadas é mantida/recuperada, a chamada não é mais considerada de consulta, mas uma transferência "arbitrária" pelo Cisco CallManager. O Cisco CallManager tem problemas com transferências arbitrárias. Limitar o usuário a reconectar-se ou concluir a transferência em uma chamada de consulta.

O participante consultor desliga, mas a aparência da chamada não desaparece

O Cisco CallManager atualmente tem problemas com um evento de desconexão para uma conferência iniciada por consulta quando a conferência não é concluída. Desconecte a chamada uma segunda vez para limpar a aparência da chamada no telefone do agente.

A rota de tradução para VRU não funciona

Primeiro, monitore o script ativo. Em seguida, verifique os logs do Roteador, do OPC e do PIM do cliente de roteamento e da URV. A maioria dos erros é rastreada incondicionalmente, mas você pode ativar o rastreamento para obter uma melhor imagem do que acontece.

Esta é a sequência da rota de conversão:

• O cliente de roteamento faz uma nova solicitação de chamada ao roteador.

• O Roteador retorna uma conexão com o Cliente de Roteamento com um rótulo que deve entregar a chamada à IVR.

• A IVR deve enviar uma RequestInstruction que o PG da VRU usa para procurar o destino do periférico.

• O Roteador faz a correspondência entre os destinos periféricos da instrução de solicitação e os destinos periféricos das rotas de conversão que ele aguarda.

• O Script de Roteamento continua com o script de execução ou nós de fila conforme designado pelo cliente.

Monitore o script ativo para localizar o caminho da falha. Verifique se há erros no rastreamento do roteador. Verifique se o cliente de rota recebe os rótulos iniciais. Verifique se a URV recebe a chamada. Verifique se a URV envia uma instrução de solicitação no nível PIM ou OPC da URV.

A solicitação de rota não chega ao "Rota de tradução para o nó URV" no script de rota

Monitore o script e verifique se a solicitação chega à rota de conversão para o nó da URV.

Primeiro, no script de rota, um nó select ou route select com uma rota de tradução selecionada não é suficiente para converter a rota para a URV de serviço controlado. É necessária uma Rota de Tradução para o nó da URV.

Segundo, o monitor deve mostrar que a chamada chega ao nó da rota de conversão. Uma falha aqui significa que uma rota de tradução não pode ser determinada ou que a mensagem de solicitação de rota RequestInstruction não foi recebida da IVR.

A roda de tradução fica com tempo esgotado no registro do roteador

O erro de tempo limite da rota de tradução indica que o Roteador não recebe a instrução de solicitação. Verifique se há erros no OPC e no PIM da URV e veja se RequestInstruction chega.

Ative o "roteamento de tradução" e o "rastreamento URV de rede" com a ferramenta rtrtrace no Roteador para obter uma melhor indicação do que ocorre no Roteador. No OPC do PG da URV, ative o relatório de controle de serviço com opctest .

Registro de VRU PIM indica DNIS não localizado em grupo de tronco X

A Instrução de Solicitação deve indicar um grupo de troncos válido que mapeie para um número de periférico de grupo de troncos em um dos grupos de troncos configurados para o PG da VRU. Desligue e desligue o Gateway Periférico da URV para receber a atualização do número do periférico do grupo de troncos, se modificado.

Verifique a configuração de ICM

Verifique se o Mapeamento de Rótulo de DN está desativado no cliente de roteamento IVR PG. O Gateway Periférico de RVI precisa de uma atribuição de URV de rede. A URV de rede deve ser do tipo 2. O Gateway Periférico de RVI deve ter um grupo de troncos de rede e um grupo de troncos atribuídos. Faça referência ao grupo de troncos da rede no grupo de troncos.

O PG de roteamento da placa de rede/postagem deve ter um rótulo para cada um dos DNIS nos destinos periféricos. (Faça com que os rótulos sejam iguais aos do DNIS para a solicitação do cliente de roteamento no assistente de tradução de rotas. Você pode configurar isso no prefixo, selecionar a opção prefixo = DNIS.)

O cliente de roteamento VRU precisa de um rótulo configurado para o destino do dispositivo para o qual ele roteia quando um agente se torna disponível.

Solucionar problemas da interface do Cisco IP IVR - ICM

Esta seção do Cisco IP IVR aborda como solucionar erros de configuração entre o IP IVR e o ICM e inclui problemas comuns com a configuração do roteamento de conversão e pós-roteamento do IVR PG. Consulte o Cisco IP IVR Troubleshooting Guide para obter mais informações sobre erros gerais de IVR.

Em geral, verifique os logs de MIVR na página da Web appadmin > Engine > Trace.

• Portas CTI IVR e pontos de rota CTI configurados no Cisco CallManager, IVR e ICM.

• As portas IVR CTI e os pontos de rota CTI são associados ao usuário IVR no diretório global do Cisco CallManager.

• A caixa de seleção Controle de serviços é marcada na configuração do ICM de IVR.

• Os nomes de script nas definições de script IVR correspondem aos nomes de script VRU da rede no ICM.

• O número do grupo de troncos no Gateway Periférico da URV corresponde ao número do grupo de portas da ITC no RVI IP.

Falha na tradução do roteador

Junto com todas as outras ações que você usa para solucionar problemas, você também pode tentar essas coisas para ajudar a solucionar problemas da IVR IP.

• Verifique o log de MIVR. Esse registro pode geralmente apontar para áreas com problemas.

• Use as configurações de depuração para ativar o Cisco IP IVR em SS_TEL e LIB_ICM.

• Ative o log do Cisco Jtapi para IP IVR com jtprefs no IP IVR. Consulte Ferramentas de depuração. Interrompa e inicie o mecanismo de RVI IP depois de ativar o rastreamento.

• Verifique se o número do grupo de portas CTI no grupo de portas da rota de tradução JTAPI de IVR IP corresponde ao número do periférico na configuração do grupo de troncos no ICM.

O script não é reproduzido ou reproduz mensagens de erro

Verifique os logs de IVR IP em arquivos de rastreamento do mecanismo para verificar se:

• Executar script é recebido.

• O IP IVR pode localizar o script. Carregue scripts com a ferramenta de administração do repositório.

• O IP IVR pode localizar o prompt. Os prompts definidos pelo usuário residem em \wfavvid\prompts\ user\en_us\ no IP IVR.

O status JTAPI mostra serviço parcial

Isso geralmente significa que algumas das portas CTI ou pontos de rota CTI configurados no IP IVR não foram configurados e/ou associados ao usuário do IP IVR no Cisco CallManager.

Isso também pode significar que os scripts não foram nomeados corretamente ou não foram carregados no Gerenciador de Repositório.

Status do ICM em IVR IP mostra o status parcial

Geralmente, essa condição indica uma configuração parcial ou incompatível de um lado ou do outro.

Aviso de falha ouvido quando uma chamada é removida da fila do roteador

Este é um script de roteamento configurado incorretamente que permite muito pouco tempo limite na configuração do script URV de rede em Configurar ICR.

Alguns dos scripts disponíveis com a IVR IP para a interface ICM são executados por um período muito longo, mas o tempo limite padrão na configuração do script de rede do ICM é de três minutos. Se o script expirar e o caminho de falha de script de execução reproduzir outro script de execução, esses scripts de execução basicamente serão enfileirados na IVR. Quando os scripts são desenfileirados, você ouve muitos scripts serem executados um sobre o outro.

Solucionar problemas de estatísticas do serviço IVR

As estatísticas de RVI são importantes para os relatórios de nível de serviço do IPCC. Portanto, algumas informações sobre como solucionar problemas estão incluídas aqui. Como visão geral, as alterações no Roteador e no Gateway Periférico da URV, em que as chamadas implementadas na URV são contadas como enfileiradas, em vez de conectadas. Quando as chamadas são roteadas, elas são relatadas como respondidas. Quando o cliente na fila desconecta as chamadas, elas são relatadas como abandonadas. Consulte o arquivo readme.txt dos hot fixes 53 e 54 para obter detalhes adicionais. O Roteador envia eventos especiais de fila que indicam em qual estado a chamada está no Roteador.

Há uma configuração de registro especial no PIM da URV, portanto, você deve ativar esse recurso voluntariamente para garantir uma interrupção mínima.

O Relatório em Tempo Real de Serviços da Empresa 10 faz uso especial desses dados quando você adiciona o(s) serviço(s) de URV e o(s) Serviço(s) PG do Cisco CallManager a um ou mais relatórios de periféricos da empresa. O Relatório em Tempo Real de Serviços da Empresa requer que os serviços PG da URV e PG do Cisco CallManager sejam agrupados em um serviço da empresa para fins de geração de relatórios.

Outros relatórios úteis de filas são os novos relatórios de tipos de chamada para registros históricos e em tempo real, e a grade em tempo real de grupos de habilidades agora mostra as chamadas em fila no grupo de habilidades.

Não são geradas estatísticas de serviço ou registros de detalhes de chamadas de encerramento

O PIM da URV não gera eventos CSTA. Ative a Emissão de relatórios de controle de serviços na configuração do PG da URV. Está na chave do Registro em ServiceControlQueueReporting em:

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

Observação: esta chave de registro aparece em duas linhas aqui devido a limitações de espaço.

A URV relata todas as chamadas como conectadas, não enfileiradas conforme necessário

Chave do Registro ServiceControlQueueReporting Fora do Ritmo ou Não Definida como 1

O log de inicialização do PIM da URV deve reclamar se não existir.

Adicione a chave ServiceControlQueueReporting e defina o valor como 1 em:

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

Observação: esta tecla aparece em duas linhas aqui devido a limitações de espaço.

As chamadas são contadas em relação ao serviço incorreto ou não aparecem nos relatórios de serviço

O log do OPC indica que o mapeamento de serviços não foi encontrado

O log do OPC indica que o mapeamento de serviço não foi encontrado quando as chamadas são contadas em relação ao serviço errado ou não aparecem nos relatórios de serviço.

Problemas de relatórios do Cisco ICM

O Cisco ICM não foi projetado para facilitar a correlação de dados das tabelas de Tipo de chamada, Serviço e Grupo de habilidades. Os números geralmente têm significados ligeiramente diferentes em cada grupo. Há apenas um serviço para uma chamada, mas pode haver dois grupos de habilidades se mais de um agente estiver envolvido. O recurso RONA (redirect on no answer, redirecionamento sem resposta) provavelmente gera outra rota de postagem sem gerar outro registro de terminação.

Grupo de Habilidades do Agente, Grupo de Habilidades, Serviço, Números de Tipo de Chamada Não Equilibram

• Sintoma: As chamadas tratadas ou outros campos estatísticos não correspondem aos relatórios de serviço, tipo de chamada e/ou grupo de habilidades.

• Condição: O tipo de chamada, o serviço e os grupos de habilidades são configurados com um mapa lógico entre si, mas os relatórios ainda não correspondem exatamente.

• Solução de problemas: Se o volume de chamadas for menor que 1 chamada por segundo, ative as configurações de rastreamento no OPC, PIM e JTAPI GW, conforme apropriado para CSTA, PIM, AGENT e eventos de terceiros. Consulte a seção Ferramentas deste documento para obter instruções.

• Documente o fluxo de chamadas:

  • A rota de postagem inicial está no Cisco CallManager PG ou no VRU PG?

  • O FONA (forward on no answer) está configurado e para o que o FONA está configurado para redirecionar?

  • Um grupo de habilidades padrão está configurado com o número de periférico 0 para separar as chamadas roteadas das chamadas não roteadas e de saída?

Obtenha os dados históricos destas tabelas para um dia com as instruções "select *":

• Peripheral_Half_Hour

• Tipo_Chamada_Meia_Hora

• Service_Half_Hour

• Skill_Group_Half_Hour

• Detalhes_Chamada_Encerramento

• Detalhes_Chamada_Rota

Solução de problemas do Cisco CallManager

Ao coletar os rastreamentos no Cisco CallManager, você pode ativar os sinalizadores na página Cisco CallManager Admin em Serviços > Sinalizadores de Rastreamento. 0xCB05 é um bom sinalizador de rastreamento configurado para rastreamento SDL de erros CTI. Defina 0xCB05 em parâmetros de serviço para fins de depuração. Consulte Casos de TAC AVVID: Coletando Informações de Solução de Problemas para obter mais informações. Consulte a documentação on-line do Cisco CallManager, incluindo guias de solução de problemas.

Ative o rastreamento para o Cisco CallManager

Consulte Configurar rastreamentos do Cisco CallManager para suporte técnico da Cisco para obter informações sobre como ativar o rastreamento para o Cisco CallManager.

Alterar endereços IP do Cisco CallManager

Consulte Alteração dos endereços IP do Cisco CallManager e altere o nome do servidor.

1. Execute a instalação no Cisco CallManager PG e altere os serviços JTAPI para o PIM do Cisco CallManager. Se você tiver mobilidade de ramal e/ou serviços telefônicos.

2. Pare o Mecanismo CRA.

3. Em CRA - Altere o endereço IP em Configuração do Mecanismo.

4. Altere o IP em JTAPI.

5. Interrompa o DC Diretory Service no servidor.

6. Altere o endereço IP na configuração do diretório.

7. No Cisco CallManager - altere o endereço IP em System > Server.

8. Altere o endereço IP em URLs em System > Enterprise Parameters.

9. Altere o endereço IP em todos os URLs em Features > Phone Services.

10. Alterar Endereço IP do Servidor - Propriedades da Rede.

11. Altere a Opção de DHCP 150 para o novo Endereço IP.

12. Altere o IP no perfil do hotel no DC Diretory, Cisco CallManager > Perfil do sistema > Hoteling.

13. Abra o gerenciador de empreendimento SQL.

14. Alterar endereços IP em URLs na tabela PlugIn.

Para fazer backup das alterações de configuração:

1. Abra a configuração stiBackup.

2. Altere os endereços IP do servidor em todas as guias apropriadas.

Ferramentas de debug

Procmon

Procmon é uma ferramenta de linha de comando que você pode usar para depurar processos PIM e JTAPI GW.

• Uso: procmon <nome do cliente> <nó> process.

  • Procmon ipcc pg1a pim1

  • Procmon ipcc pg1a jgw1

  • Procmon ipcc cg1a ctisvr

Aqui estão algumas configurações de rastreamento úteis para cada um dos processos:

• JTAPI GW (use procmon)

  • trace JT_TPREQUESTS (ativa rastreamentos de solicitações de terceiros)

  • trace JT_JTAPI_EVENT_USED (ativa os rastreamentos dos Eventos JTAPI que o PG usa)

  • trace JT_PIM_EVENT (ativa os rastreamentos de mensagens de evento enviadas ao PIM)

  • trace JT_ROUTE_MESSAGE (ativa os rastreamentos de cliente de roteamento)

  • trace JT_LOW* (rastreia com base nas camadas subjacentes de JTAPI e CTI)

• PIM (use procmon)

  • trace tp* (ativa rastreamentos de solicitação de terceiros)

  • trace pré-call (ativa os rastreamentos de eventos de pré-chamada)

  • trace *event (ativa os rastreamentos de eventos de agentes e chamadas)

  • trace csta* (ativa os rastreamentos de eventos de chamadas CSTA)

• SERVIDOR CTI (use procmon)

  • regset EMSTraceMask 0xf8 (ativa rastreamentos úteis do servidor CTI, provavelmente para contornar)

OPCtest

Opctest é uma ferramenta de linha de comando para depurar o processo OPC no PG.

• Uso: opctest /cust <nome do cliente> /node <nó>

  • opctest /cust ipcc /node pg1a

• Configurações úteis

  • debug /agent (ativa os rastreamentos de eventos do agente)

  • debug /routing (ativa rastreamentos de eventos de roteamento)

  • debug /cstacer (ativa rastreamentos de eventos csta)

  • debug /tpmsg (ativa rastreamentos de solicitação de chamada de terceiros)

rttest

Rttest é uma ferramenta de interface de linha de comando para depurar o processo do roteador no ICM. Consulte rtrtrace para obter a versão da GUI.

• Uso: rttest /cust ipcc

rtsetting.exe

Ferramenta GUI para alterar as configurações de registro do roteador.

• Há uma opção para restaurar as configurações para o padrão.

rtrtrace.exe

Ferramenta GUI para ativar vários rastreamentos de roteador no ICM.

• As configurações particularmente úteis para o IPCC são:

  • Enfileiramento - para problemas de desenfileiramento.

  • Service Control - para problemas com a interface da URV.

  • Roteamento de tradução - para problemas com rotas de tradução.

dumplog

Despeja arquivos binários do Cisco ICM em arquivos de texto. Altere os diretórios para o diretório process logfiles.

• Os arquivos de log de processos OPC, PIM e JtapiGW residem em icr\<customer_name>\<node>\logfiles\.

• No PG, há um arquivo de lote chamado cdlog onde você digita >cdlog <cust> <node>.

• Uso: nome do processo dumplog

  • Dumplog /" (para obter ajuda sobre diferentes opções de dumplog)

  • Dumplog jgw1

  • Dumplog pim1

  • Dumplog opc

vrutrace

Uma ferramenta para exibir o arquivo de captura do PG da URV. Funciona de forma semelhante ao dumplog.

Rastreamento de chamada

Ferramenta Cisco ICM que você pode usar para depurar scripts de roteamento.  Você pode encontrar essa ferramenta no item de menu AW no AW.

jtprefs

Esta é uma ferramenta para ativar rastreamentos JTAPI para o cliente JTAPI no IVR IP. Os rastreamentos JTAPI no IPCC PG são controlados com a interface procmon. Esta ferramenta reside em arquivos de programa\CiscoJtapiTools\.

Monitor de desempenho

Uma ferramenta administrativa do Microsoft Windows 2000 que mostra dados em tempo real do Cisco CallManager, Cisco IP IVR e ICM. Você pode ver as chamadas em andamento, os dispositivos registrados e a utilização da CPU do processo. Essa ferramenta pode ser encontrada em Iniciar > Programas > Ferramentas Administrativas.

Arquivos de registro

Arquivos de log do Cisco ICM

Os arquivos de log do Cisco ICM residem em \icr\<cust>\<node>\logfiles. Aqui, customer faz referência ao nome da instância do cliente e node faz referência a pg1a, ra para roteador, cg1a e muito mais. Use dumplog para exibir os arquivos de log.

Observação: você pode exibir arquivos de captura de eventos com ferramentas de rastreamento como vrutrace. Esses arquivos estão em um diretório diferente.

Arquivos de registro do Cisco CallManager

Os arquivos de log do Cisco CallManager normalmente residem em \program files\cisco\ccm\trace com diretórios de rastreamento de:

• Ccm - Registros SDI do CallManager.

• Dbl - Logs Da Camada De Banco De Dados.

• Sdl - Registros De Sinalização De Chamada.

• Tftp - Logs do servidor tftp.

Você pode modificar as configurações de rastreamento para esses arquivos na página de administração do Cisco CallManager em trace settings. Você pode modificar as configurações de rastreamento SDL em parâmetros de serviço no Cisco CallManager.

Arquivos de log IVR IP

Os arquivos de log IVR IP residem em \arquivos de programa\wfavvid. Você também pode exibir os arquivos de log IPIVR na página appadmin, em arquivos de rastreamento do mecanismo.

Você pode exibir os logs do Cisco JTAPI Client ao ativar eventos JTAPI com jtprefs.exe e reiniciar o mecanismo IP IVR.

Dados de perfis úteis

Ao coletar dados para abrir casos, colete os dados listados nesta seção, além dos arquivos de log.

Número de agentes

Qual é o número de agentes configurados?

Gateways usados

Quantos gateways estão configurados?

Versões de software dos componentes

Cisco CallManager, cliente JTAPI, ICM, versão do Gateway IOS e IP IVR.

• Você pode encontrar a versão do Cisco CallManager na página da Web de administração do Cisco CallManager em Ajuda > Sobre > Detalhes.

• Para encontrar a versão do JTAPI Client, basta digitar jview CiscoJtapiVersion em um prompt de comando no diretório \winnt\java\lib no Cisco CallManager PG.

• Você também pode encontrar a versão IP IVR.

Tipo IVR

Que tipo de IVR está em uso?

Plataformas

Que tipos de plataformas estão em uso/ CPU / e quantidade de memória física.

Informações Relacionadas

• Usando o Procmon (console de monitor de processo remoto)
• Como usar o utilitário Dumplog
• Usando o Utilitário de Linha de Comando OPCTest
• Utilitário ICM rttest Cisco
• Aumento do rastreamento
• Lendo um arquivo de registro Drwtsn32
• Casos de TAC AVVID: Coletando informações de solução de problemas
• Alterar os endereços IP do Cisco CallManager
• Suporte Técnico e Documentação - Cisco Systems