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.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Como pesquisar defeitos e apoiar o ICM PG de Cisco
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.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Olhe os logs PG para o IPCC. Quando você vê erros não especificados no Peripheral Interface Manager (PIM), em Open Peripheral Controller (OPC), ou em log de servidor do Computer Telephony Interface (CTI), vá diretamente ao log do JTapi Gateway (GW) para uma descrição de texto melhor do problema. A interface JTAPI fornece geralmente exceções quando as coisas vão mal em requisições de terceira parte. Estas exceções fornecem somente descrições da corda sem o código de erro. Em consequência, os log de servidor PIM/OPC/CTI muitos erros como erros não especificados.
Verifique para ver se há a existência de um log PIM. Se não há nenhum log PIM, a verificação para certificar-se do peripheral está permitida no ICM instalação de Cisco. Às vezes, o peripheral é adicionado, mas você precisa de permitir o peripheral.
Seleto edite > Peripheral, e verifique a caixa de verificação permitida.
Se o processo PIM reinicia, veja o fazer logon PIM o CallManager da Cisco PG com Se o arquivo de registro indica um erro com o OPCHeartbeatTimeout, você deve alterar esta configuração de registro. Use o regedt32 para fazer a mudança.
Altere OPCHeartbeatTimeout no registro sob dados dinâmicos do eagtpim ao 10. Está aqui o trajeto:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\EAGENTData\Dynamic
Nota: Esta chave aparece sobre duas linhas aqui devido às limitações de espaço.
Se o processo PIM está em um estado ocioso, execute estas verificações:
Verifique o log PIM. Você deve ver, “tenta ativar uma vez”, pelo menos ao minuto.
Se o PIM não é ativo, use o utilitário dumplog para verificar o log OPC. Execute o opctest para ver se o processo OPC recebe a configuração do roteador.
Se o processo OPC não recebe a configuração do roteador, use o utilitário dumplog para ver o log PGAGENT. O processo pgagent deve ter um caminho ativo ao controlador central. Se o PGAGENT não tem um caminho ativo, verifique a conectividade de rede e a configuração do DMP no PG inicialização. No roteador, use o utilitário dumplog para ver o log ccagent. Verifique se o dispositivo PG (ID de sistema DMP) está permitido como um dispositivo no roteador.
Permita o PG na configuração de roteador com a instalação ou no registro sob o registro de DMP.
Em uma janela de comando, use o comando tracert verificar a conectividade de rede entre o roteador e o PG.
Nota: Pode haver uma discrepância entre o DNS e o DHCP.
Verifique se o endereço IP de Um ou Mais Servidores Cisco ICM NT para o roteador está no arquivo de host no diretório de c:\winnt\system32\drivers\etc.
Verifique se o controlador lógico ID configurado em PG > Setup combina o ID para o controlador da interface lógica PG configura dentro > ICM. Assegure-se de que o ID periférico configurado para o peripheral em PG > Setup combine o ID para o peripheral configure dentro > ICM.
Altere o ICM instalação para combinar a configuração.
Vá a um comando prompt e a um tipo jview e pressione o ENTER. A informação na versão instalada das Javas aparece:
Microsoft (R) Command-line Loader for Java version 5.00.3190
Se você não vê esta saída, ou se a versão está mais adiantada de 3190, você deve instalar a versão correta de Microsoft JVM. Execute msjavx86.exe. Este arquivo é instalado no icr \ diretório bin durante a instalação.
De um comando prompt, vá ao icr \ diretório bin e datilografe o jtapigw e pressione o ENTER. Uma resposta similar 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 aparece:
Java.lang.NoClassDefFoundError: com/cisco/icr/GWThreadGroup
Se você vê a segunda mensagem quando você executa o jtapigw, verifique seu caminho de classe java. Use o editor de registro para olhar o caminho de classe do valor sob o SOFTWARE \ chave de Microsoft \ Javas VM. Ajuste a chave como isto:
C:\WINNT\java\classes;.;c:\icr\bin\icrjavalib.zip
Nota: A letra da unidade e o diretório de sistema Windows podem diferir e os caráteres após classes e antes que c:\icr… estiver: ponto-e-vírgula, período, e ponto-e-vírgula.
De um comando prompt, vá ao icr \ diretório bin, datilografe o jtapigw e pressione o ENTER. Uma resposta similar 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 do acima, você pode ver esta mensagem:
Java.lang.NoClassDefFoundError
Se você vê algo como a segunda mensagem quando você executa o jtapigw, verifique que o cliente Cisco JTAPI está instalado no PG. Verifique para ver se há o arquivo CiscoJtapiVersion.class sob c:\winnt\java\lib.
Se este arquivo não existe, você pode instalar o arquivo no PG do CallManager da Cisco; <callmanager name>/main.asp de http://. Você pode encontrar o arquivo sob a aba do aplicativo.
Se você instalou somente o pacote de serviços do JTAPI 4.1 (SP) 4 com todo o reparo quente menos do que 50 pés no CallManager da Cisco PG, você precisa de promover.
Se você apenas foi executado ICM > Setup para promover o PG, verifique para certificar-se de que a data/hora no arquivo \ icr \ escaninho \ icrjavalib.zip mostra uma data actualizado. A data deve ser aproximadamente a mesma como a data/hora no arquivo, dentro de cerca de um dia.
Nota: A instalação não pode atualizar este arquivo se o arquivo está no uso quando você executa a instalação. Esta situação pode ocorrer se você tem um navegador de Internet aberto porque, o navegador trata o arquivo zip como um diretório para o trajeto da classe se o navegador abre o fecho de correr. A fim evitar este problema, feche todas as sessões de navegador antes que você execute a instalação. Se a instalação não pode atualizar o arquivo, uma mensagem aparece, e instrui-o recarregar seu PC a fim atualizar os arquivos. Você deve recarregar.
O PIM comunica-se com o JTapi Gateway (JTAPIGW), e o JTAPIGW comunica-se com o CallManager da Cisco. Enquanto o PIM tenta ir active, o PIM diz o JTAPIGW para inicializar comunicações com o CallManager da Cisco com o JTAPI.
Você deve ver as mensagens que indicam que o JTAPIGW aceitou uma conexão do PIM e contacta o 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()
Nota: Este exemplo aparece sobre as múltiplas linhas devido às limitações de espaço.
Se você não vê o traço retornado com sucesso, você pode ver outros erros após o atendimento ao getProvider(). O traço ao getProvider() mostra os parâmetros usados para inicializar o JTAPI. O primeiro parâmetro é o nome do serviço, que é o nome de Host IP ou o endereço IP de Um ou Mais Servidores Cisco ICM NT da máquina do CallManager da Cisco. Neste exemplo, o endereço IP de Um ou Mais Servidores Cisco ICM NT é usado. Se um nome é usado, o PG deve poder resolver o nome com um arquivo de host ou um DNS. Certifique-se que você pode sibilar o nome ou o endereço. Se você precisa de mudar o nome do serviço, para tornar a colocar em funcionamento o ICM > Setup e muda o nome no diálogo periférico da edição.
O traço do atendimento ao getProvider() igualmente mostra o nome do início de uma sessão usado. Observe que o traço não mostra a senha. O nome do início de uma sessão e a senha são tomados do que o administrador entra sob ICM > Setup. Estes devem combinar um usuário válido e uma senha configurados no diretório e administrados no página da web das preferências de usuário de Cisco para ter a capacidade para controlar cada um dos dispositivos de agente e dos pontos de rota. Verifique para certificar-se que o nome e a senha estão corretos em ICM > Setup. Configurar o usuário no diretório para ter a permissão controlar somente dispositivos e pontos de rota do agente válido.
O processo do JTAPI GW não pode resolver o endereço do CallManager da Cisco. Configurar o parâmetro de serviço na caixa de diálogo PIM na instalação com o nome de host ou o endereço IP de Um ou Mais Servidores Cisco ICM NT do CallManager da Cisco. Se a configuração do nome de host para o CallManager da Cisco está correta, certifique-se que você pode sibilar o CallManager da Cisco. Se não, use o endereço IP de Um ou Mais Servidores Cisco ICM NT do CallManager da Cisco, em vez do nome de host.
Os logs do JTAPI GW no diretório global com um nome de usuário e senha. O nome de usuário e senha na caixa de diálogo PIM na instalação deve combinar o nome de usuário e senha para o configurado pelo usuário no diretório global no página da web admin do CallManager da Cisco sob o ccmadmin > o usuário > o diretório global.
Se o usuário não existe, adicionar um novo usuário. Certifique-se verificar a caixa de verificação com CTI ativada na parte inferior da página.
Uma caixa de verificação na página de usuário de diretório global do CallManager da Cisco pode permitir ou desabilitar os privilégios CTI para um usuário PIM ou de IVR DE IP. Você deve verificar e atualizar esta caixa de verificação para que o PIM/JTAPI GW para ir active. Esta caixa de verificação assegura-se de que dois dispositivos CTI não possam conectar ao CallManager da Cisco, que podem causar problemas (o limite padrão é 400).
Na versão do CallManager da Cisco 3, este serviço mostra no controle de serviço como o “CallManager da Cisco”. Comece o serviço.
O serviço do CallManager da Cisco está ajustado normalmente para reiniciar se retira anormalmente, mas você pode configurar este a "OFF" para possíveis problemas com migração de dispositivos em cenários de failover.
Verifique o log de eventos para ver se o serviço do CallManager da Cisco reinicia. O sistema reinicia às vezes se o sistema identifica um problema com uso adequado CPU. Os sistemas relata erro ou os avisos no log de eventos que indicam “uma linha lenta do temporizador SDL”. Com este tipo de erro, o CallManager da Cisco reinicia. Esta versão do CallManager da Cisco executa na prioridade normal tão outros aplicativos que são executado no sistema podem interferir com o sinal de chamada.
Quando a memória física é menos ou o sistema encontra outras questões de cronometragem, o CallManager da Cisco pode vir acima com um erro que indique que não poderia inicializar após um intervalo do minuto 10 e reiniciar. Há um serviço do componente DCOM para a camada da base de dados do CallManager da Cisco (DBL) que tem um problema que inicializa. Pare e comece este serviço DBL DCOM com os serviços de componente – componentes DCOM resolver este problema.
Nota: Este não é o mesmo que um serviço de sistema como o CallManager da Cisco.
Abra um caso com o centro de assistência técnica da Cisco (TAC). Este pode provavelmente ser um problema a próxima vez que você reinicia o sistema, a menos que você resolver a questão de cronometragem subjacente.
Confirme que o serviço de diretório é ascendente e é executado corretamente. À revelia, este é o DC Directory Server no controle de serviço na máquina do CallManager da Cisco. Tente ligar a máquina. Você pode encontrar erros.
O serviço de diretório pode entrar em um estado pausado se o sistema é executado fora da memória ou do espaço de disco. Os erros aparecem no log de eventos do Microsoft Windows 2000. Resolva edições do recurso e reinicie o serviço de diretório, caso necessário.
Verifique se o página da web do usuário de diretório global de Cisco pode realmente ver e configurar usuários e atribuir permissões aos dispositivos de controle. o JTAPIGW e o página da web usam o CallManager da Cisco para alcançar o servidor de diretório para alcançar usuários e permissões. Se o problema com JTAPIGW é devido a um problema do servidor de diretório, o página da web do usuário pode igualmente ter problemas. As razões possíveis são que o servidor de diretório não é executado ou o diretório não está configurado corretamente, se de todo.
A fim usar o CallManager da Cisco 3.0.5 e mais atrasado, você deve instalar um servidor de diretório. O DC Directory AVVID é o padrão que está disponível nos CD da instalação Spirian. Depois que você instala o servidor de diretório, a instalação do CallManager da Cisco configura o diretório.
Você deve executar esta instalação corretamente, e o servidor de diretório deve ser ascendente e deve ser executado corretamente para que o JTAPIGW registre no CallManager da Cisco e use o JTAPI.
Certifique-se de que o serviço do DC Directory e o CallManager da Cisco ambos são executado corretamente.
Quando você instala o CallManager da Cisco, você deve incorporar o “ciscocisco” quando você vê a alerta da senha do gerenciador de diretório. Se você entra em qualquer outra coisa, você pode ter que remover o software do DC Directory (adicionar/remova) e reinstalá-lo. Se o processo da remoção lhe diz que alguns arquivos não podem ser removidos, você deve manualmente remover ou rebatizar o diretório atual de c:\dcdsrvr.
Verifique o Control Panel para confirmar que o serviço não pode começar. Em seguida, verifique se o administrador está configurado e o início de uma sessão e a senha estão corretos para o serviço no campo das propriedades.
Comece o DC Directory Admin de seu menu de início do sistema. Entre com seu gerente do diretório de usuário com a senha “ciscocisco” (padrão) ou o que senha o admin configurou. Se você recebe um erro que indique que o usuário não está configurado, execute um dos arquivos de configuração do Cisco AVVID no DCDSrvr \ diretório bin. Se este é o CallManager da Cisco principal, o editor, executa avvid_cfg.cmd do prompt do DOS. Se este é um CallManager da Cisco secundário, execute avvid_scfg.cmd do comando prompt.
Se você vê que os erros que indicam isto estão configurados já, o usuário existe. Se não há nenhum erro, as coisas devem começar trabalhar corretamente agora. Vá para trás e verifique o acesso das páginas de usuário de diretório global no ccmadmin.
Nota: O DC Directory entra no modo da pausa se o diretório é baixo em recursos de sistema.
Este exemplo usa uma configuração de ICM da amostra para um destino do dispositivo:
| Amostra do destino do dispositivo | |
| Nome do empreendimento | Agent9782755100 |
| Endereço global | Agent9782755100 |
| ConfigParm | /devtype CiscoPhone /dn 9782755100 |
O exemplo seguinte usa uma configuração de ICM da amostra para um agente:
| Amostra do agente | |
| Periférico | CCMPG_PIM1 |
| Número periférico | 1234 |
| Senha | XXX |
Quando você é executado ICM > Setup para o PG, você especifica um comprimento de extensão de agente de "4". Assim, na configuração de exemplo, a extensão para o dispositivo de exemplo é os últimos 4 dígitos do parâmetro de /dn (por exemplo, "5100").
Tente entrar com CTITest.
Se você não pode registrar um agente dentro com o telefone de software, tente a mesma operação com mais ctitest. Está aqui um exemplo de lista dos comandos ctitest que você pode usar para entrar o agente da amostra ao alvo do dispositivo de exemplo. Esta lista de comandos supõe que o CTI Server escuta na porta 42027 na máquina CTIServerA. Esta lista igualmente supõe que o dispositivo é uma extensão para o peripheral representado como 5000 ICM periféricos.
config /hostA CTIServerA config /portA 42067 config /service CLIENT_EVENTS+CLIENT_CONTROL agent /periph 5001 /inst 9782755100 open login 1234 XXX /inst 9782755100
Use o comando do “estado” do opctest e confirme o IPCC PIM e a mostra do CTI Server em estados PIM_ACTIVE e CTI_ACTIVE. As barras de títulos do PIM e dos indicadores do log do CTI Server igualmente indicam o estado de processo.
Verifique os ajustes para conectar ao CTI Server. Para o telefone de software do desktop, os ajustes estão no arquivo do .ini (geralmente desktop de c:\program files\geotel\cti \ cticonfig.ini). Os ajustes a verificar incluem:
PeripheralID — Este valor deve combinar o ID periférico para o periférico de IPCC configura dentro > ICM.
SideAHost — Este valor deve ser o nome de Host IP ou o endereço do lado A do CTI Server.
SideBHost — Este valor deve ser nome de Host IP ou endereço do lado B do CTI Server. Se o CTI Server é simples, você pode deixar esta placa do campo.
SideAPort — Este valor deve combinar a porta que o CTI Server no lado A escuta conexões. Este valor é especificado no ICM instalação para o CTI Server. O CTI Server mostra esta porta na barra de títulos e registra este valor quando o CTI Server começa. Verifique se o cliente pode sibilar o CTI Server.
Execute o setup.exe que reside no \ icr \ diretório bin no server PG/CTI. Selecione o componente de gateway CTI. Verifique se o AgentLogin exigiu a caixa de verificação está desmarcado. Esta opção da caixa de verificação não é aplicável para o IPCC ou nenhuns aplicativos de controle da terceira. A finalidade desta caixa de verificação é monitorar aplicativos outros agentes de ACD.
Use o procmon ao pim e “siga o tp*” para girar sobre o tracing de terceira parte (diferenciando maiúsculas e minúsculas). Isto deve mostrar a solicitação de login. Verifique se os parâmetros estão corretos. O instrumento é seguido como “Device=”. Este valor deve combinar a corda de /dn no configparam do destino do dispositivo. O ID do agente é seguido como “AgentID=”. Este valor deve combinar o número periférico de agente em Configure/ICM.
INVALID_PASSWORD
Certifique-se que a senha está correta (a senha não pode ser seguida como o texto claro). Se a senha está incorreta o log deve mostrar um erro INVALID_PASSWORD_SPECIFIED.
INVALID_OBJECT
Indica que os parâmetros de configuração no destino do dispositivo contêm um tipo de dispositivo inválido. Este erro aparece como este com espaços entre palavras-chaves:
/devtype CiscoPhone /dn 9782755100
INVALID_DEVICE_TARGET
Indica que algo no destino do dispositivo é inválido, muito provavelmente algo nos parâmetros de configuração coloca. Com o utilitário dumplog, veja o log PIM pela última vez que o PIM reiniciou. O log valida os destinos do dispositivo e os erros do log quando as cordas da configuração de alvo do dispositivo são inválidas.
Verifique o log do jgw para ver se há todos os erros que ocorrerem em cima das tentativas de login. Use o procmon ao PIM e “siga o *TP*” para girar sobre o tracing de terceira parte (diferenciando maiúsculas e minúsculas). Procure a linha, “MsgAddCallObserver: ADDR: ” onde o é a extensão em que você tenta entrar. Esta extensão deve ser uma extensão válida do CallManager da Cisco em um dispositivo que o usuário PG tenha a permissão controlar. A extensão deve ser o número correto de dígitos para o telefone enquanto o CallManager da Cisco sabe. Ou seja a extensão deve ser o número que você disca de um outro telefone no mesmo CallManager da Cisco para alcançar o telefone na pergunta.
Se o log do jgw mostra uma exceção, que indique que o dispositivo não está no domínio de provedor, o telefone não é associado com o usuário com que o JTAPI GW entra. Certifique-se que a extensão no lado distante da lista da associação de dispositivo de usuário do diretório global está correta. Igualmente assegure-se de que o número de linha do dispositivo não esteja registrado duas vezes. A aparência da linha compartilhada é uma característica do CallManager da Cisco que o IPCC não apoie. Você pode inadvertidamente tentar estabelecer uma aparência da linha compartilhada com dois telefones que têm a mesma linha. Se você muda um número de linha, o outro muda, e o PG não pode registrar no dispositivo correto. A fim resolver este problema, suprima de ambas as linhas e adicionar-las ao CallManager da Cisco.
A fim entrar, um agente deve ser configurado em Configure/ICM como um membro pelo menos de um grupo de habilidades (membro do grupo de habilidades).
Certifique-se de que o agente (como o número periférico de agente representa) não está registrado já em um outro destino do dispositivo. Uma maneira de verificar isto é executar o monitor ICR e executar o livre dos relatórios do agente para o agente na pergunta. Se o agente é entrado, este mostra-lhe o ID de destino de rede do destino do dispositivo em que o agente é entrado. Os dados de agente aparecem no awdb somente se você configurou o ICM para enviar dados de agente para o peripheral a este AW.
Você poderia igualmente perguntar para este no isqlw contra a tabela do Agent_Real_Time no awdb. Primeiramente, encontre o alvo da habilidade para o agente (por exemplo, seleto * do agente onde PeripheralID = XXX e PeripheralNumber = YYY). Então, verificação se o agente está entrado (por exemplo, selecione * do Agent_Real_Time onde SkillTargetID = XXX).
Você pode igualmente verificar para ver se há este quando você conecta ao procmon ao PIM e executa o number> periférico <agent dagent.
Certifique-se que o destino do dispositivo (como o instrumento especifica) já não tem um outro agente entrado.
Uma maneira de verificar isto é executar o isqlw contra a tabela do Agent_Real_Time no awdb. Primeiramente, encontre o ID de destino de rede para o destino do dispositivo na pergunta. Por exemplo, selecione * de Device_Target onde ConfigParam gosta de “%1003%”. Agora, veja se o destino do dispositivo é entrado. Por exemplo, selecione * do Agent_Real_Time onde NetworkTargetID = XXX.
Você pode igualmente verificar para ver se há este quando você conecta ao procmon ao PIM e despeja o destino do dispositivo. Há duas maneiras de despejar o destino do dispositivo. O comando ddt toma um ID de destino de rede como a entrada e despeja o destino do dispositivo. O comando deadt toma a corda de /dn da configuração de alvo do dispositivo como a entrada e despeja o destino do dispositivo. Por exemplo, se a corda de /dn do destino do dispositivo é /dn 9782755100, você despeja o destino do dispositivo como o deadt 9782755100.
Vá ao página da web do CallManager da Cisco, ao usuário seleto/diretório global e encontre o userid que o PG usa. Verifique “associou dispositivos” e certificam-se que o usuário tem a permissão controlar o dispositivo.
Se você não pode encontrar o dispositivo na página de usuário (verificada ou desmarcado), pode haver um problema com a sincronização entre o base de dados (onde o CallManager da Cisco armazena os dispositivos) e o servidor de diretório (que armazena os dispositivos e armazena perfis de usuário). Verifique para ver se o servidor de diretório (DC Directory Server) é executado.
Verifique o log de aplicativo event viewer do Windows NT e procure erros do DC Directory ou do metalink. Se os erros da importação ocorrem, execute o avvid_recfg de c:\dcdsrvr\bin.
Certifique-se que a microsoft java virtual machine (JVM) está instalada na máquina do CallManager da Cisco. A fim testar isto, datilografe o jview de um comando prompt. Para o CallManager da Cisco 2.4, você deve instalar o JVM manualmente. Para o CallManager da Cisco 3, a plataforma é Windows 2000 e a instalação JVM é automática.
Verifique se o telefone esteja posto sobre, registrado com CallManager da Cisco, e capaz de fazer e receber atendimentos do telefone sem controle de agente.
Certifique-se que o agente está entrado e não no estado disponível. Se o agente não está disponível, o agente não pode fazer um atendimento. A fim fazer um atendimento, primeiro clique não pronto.
Se há um erro somente quando você disca determinados números, verifique aqueles números de um telefone físico para certificar-se que você pode discar dentro com sucesso. Se você configurou um plano do número discado ICM, verifique para ver se o número você disca os fósforos um dos convites em seu plano do número discado. Verifique então para ver se as configurações de agente de desktop para o agente permitem o agente discar o tipo de número que a entrada do plano do número discado identifica (por exemplo, internacional).
O plano do número discado configurado para cada PIM pode incorretamente ser configurado ou corretamente configurado para impedir que um agente chame a um determinado número. O erro no log PIM deve indicar um erro de permissão. Os números para agentes e dispositivos não podem sobrepor quando o plano do número discado é usado fazer o agente aos atendimentos do agente.
O roteador faz o agente não disponível quando o agente faz um atendimento ou quando um atendimento está distribuído ao agente. Este mecanismo permite que o roteador distribua um outro atendimento ao agente antes que o PIM relate o atendimento chegou. Algumas redes tomam diversos segundos para distribuir realmente o atendimento. O roteador não cancela o temporizador baseado no estado de agente.
Se o tempo real tomado para distribuir atendimentos ao PIM do cliente de roteamento é relativamente curto, você pode mudar o tempo configurável no roteador. Em um do Roteadores em uma janela de comando dos, use rtsetting.exe. Olhe sob o Extrapolation > Agent. A configuração padrão é os segundos 10. Se o valor é demasiado curto, o roteador distribui atendimentos aos agentes que estão a ponto de receber um atendimento. Isto faz com que o PIM deixe cair atendimentos.
O intervalo de padrão no PIM é os segundos 7. Você pode alterar este valor com o comando regedt32. Adicionar a chave de “AgentReserveTimout” neste trajeto:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<pg_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\EAGENTData\Dynamic\
Nota: Esta chave será adicionada na instalação da versão 4.1.5.
Nota: Esta chave aparece sobre duas linhas aqui devido às limitações de espaço.
O número PIM deve sempre ser alguns segundos menos do que o temporizador de extrapolação de roteador para impedir que o roteador envie eventos novos do PRE-atendimento ao PIM antes que o evento original esteja processado. Isto causa problemas no PIM.
Se o atendimento chega após o tempo PIM para fora, o atendimento está considerado um atendimento NON-ACD, e nenhuma dos variáveis de contexto, do serviço, ou da informação do grupo de habilidades é atribuída ao atendimento.
Se o agente está em um atendimento e clica não pronto, ocupado, ou outro, o estado de agente não muda imediatamente. Isto é intencional. O agente permanece na conversa ou no estado guardado até a conclusão do atendimento. As transições de agente a não se aprontar, trabalhar pronto, ou para trabalhar não pronto, segundo que o botão é pressionado. Se, após o atendimento termina, as transições de agente imediatamente a disponível, você deve verificar as configurações de agente de desktop para ver se há o agente e ver se disponível após entrante ou disponível após que parte são ajustados. Estes ajustes cancelam as tarefas que o agente executa com os botões durante um atendimento.
Verifique configurações de agente de desktop para ver se há o agente no configurar ICM e veja se a razão inativa exigida é verificada. Se a caixa de verificação é verificada, o agente não pode entrar não no estado pronto sem um código de motivo. Altere o Desktop_Settings.cfg para combinar a configuração de agente de desktop no configurar ICM, ou mude a configuração de agente de desktop no configurar ICM.
Se não há nenhuma configuração de agente de desktop atribuída ao agente, o agente pode entrar e ir pronto, mas o agente não pode ir not_ready ou saída. A definição é fechar o aplicativo do agente, atribuir uma configuração de agente de desktop, e entrar outra vez.
O roteador faz o agente não disponível quando o agente faz um atendimento ou quando um atendimento está distribuído ao agente. Este mecanismo permite que o roteador distribua um outro atendimento ao agente antes do PIM relata o atendimento como recebido. Algumas redes tomam diversos segundos para distribuir realmente o atendimento. O roteador não cancela o temporizador baseado no estado de agente.
Se o tempo real tomado para distribuir atendimentos ao PIM do cliente da rota é relativamente curto, você pode mudar o tempo configurável no roteador. Em um do Roteadores em uma janela de comando dos, use rtsetting.exe. Olhe sob o Extrapolation > Agent. O padrão é os segundos 10. Se o valor é demasiado curto, o roteador distribui atendimentos aos agentes que estão a ponto de receber um atendimento. Isto faz com que o PIM deixe cair atendimentos.
Há uma inconsistência nos dados para a solicitação de login e o pedido pronto. Possivelmente, o instrumento, o ID do agente, ou os números periféricos não combinam. Gire sobre o traço do CTI Server com o procmon e ajuste o regset a 0xf8 para ver os traços apropriados. Você pode igualmente ver este nos logs OPC ou PIM, se o traçado (TP) da terceira está ligada.
Se o agente está em um trabalho pronto, o trabalho não pronto, ou o estado disponível, o agente devem primeiramente sair a não pronto antes dos logs do agente. Altere Desktop_Settings.cfg para combinar a configuração de agente de desktop no configurar ICM, ou mude a configuração de agente de desktop no configurar ICM.
Se o agente está não no estado pronto e ainda não pode logout, verifique as configurações de agente de desktop para ver se há o agente no configurar ICM e veja se a razão da saída exigida é verificada.
Se o telefone de software mostra um atendimento que esteja já não fisicamente atual, o estado de agente pode ser colado na fala ou a posse e o agente não são poder logout. Isto pode ser devido a um Bug de Software no JTAPI ou no PIM. A fim cancelar a circunstância, primeira tentativa de cancelar o atendimento do telefone de software se o botão Release Button é permitido. Se isto não trabalha, tente logout o agente. Se o botão Logout Button não funciona, para retirar, e reiniciar o telefone de software. Se a circunstância persiste, retire o telefone de software, execute o gerenciador de tarefa, execute a matança geodcs.exe e common~1.exe, e reinicie o telefone de software. Estes processos podem continuar a executar e recordar o estado de agente inválido.
No procmon, verifique o estado do agente no PIM. Se você reinicia a área de trabalho do agente e a circunstância faz não claro, há mais medidas que você pode tomar. O CTI Server e o OPC fornecem mecanismos para cancelar atendimentos com a relação debugar do procmon ou do opctest. Esta é uma opção levemente preferida à outra opção que é dar um ciclo o serviço PG ou pelo menos o fim a janela de PIM.
Com regedt32, verifique estas configurações de 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
Nota: Estas chaves de registro aparecem sobre duas linhas aqui devido às limitações de espaço.
Ajuste estes valores a 300 e a 28800 respectivamente.
Use a ferramenta de rastreamento de chamada AW para verificar se o atendimento obtém ao script e às corridas do script corretamente. Execute o editor de script e monitore o script. Olhe o roteador, o OPC, e os PIM Log para problemas. A maioria de erros da rota são seguidos incondicionalmente.
Há um ajuste para cada cliente de roteamento no configurar ICM etiquetado, do “mapa uso DN/Label.” Se este ajuste é ajustado ao " sim " você precisa de configurar uma entrada " etiqueta de número discado " para cada combinação de número discado e de etiqueta possível do alvo. Este ajuste não é útil em clientes de roteamento PG e deve ser ajustado a “não”.
Verifique a etiqueta configurada no cliente de roteamento. Você deve configurar a etiqueta em cada cliente mesmo se a etiqueta é idêntica em cada cliente.
A fim usar pós-roteamento você deve configurar “um ponto de rota CTI” no CallManager da Cisco e atribuir uma linha ao ponto de rota com o número de diretório desejado (por exemplo, "5000"). Para o agente chama a pós-roteamento, usam o plano do número discado. Um agente que disca ao CallManager da Cisco CTI o ponto de rota confunde o soft phone de IPCC na versão 4.1.9 do desktop CTI.
Você deve adicionar o dispositivo do ponto de rota CTI à lista de “associou dispositivos” para o usuário PG no página da web do usuário do CallManager da Cisco sob o diretório global. Se você cria um dispositivo novo, adicionar as linhas primeiramente, e adicionar então o dispositivo à lista dos dispositivos do usuário “associou”. Se você adiciona mais linhas a um dispositivo que já exista na lista de dispositivos do usuário, você precisa de reiniciar o JGW para que o JGW reconheça as novas linhas. Contudo, se você adiciona um dispositivo novo, adicionar uma linha ao dispositivo, e adicionar então o dispositivo à lista de dispositivos do usuário, o JGW deve poder reconhecer o dispositivo novo (dentro de cerca de 30 segundos).
Verifique o número discado para certificar-se que o número está configurado para o cliente de roteamento periférico. Execute o procmon ao JGW e gire sobre o traço como o “traço *ROUTE*” (diferenciando maiúsculas e minúsculas). Verifique o log JGW para ver se há erros que se referem o número discado. Em cima da partida, o JGW tenta registrar um retorno de chamada da rota para o número discado. Quando um atendimento é feito ao número discado, o gateway recebe um “RouteEvent”.
Junto com o número discado, verifique se o tipo de chamada está criado e traçado corretamente ao script.
Se você configurou um número discado ICM, estabeleceram o ponto de rota CTI, e adicionar-lo à lista de dispositivos do usuário mas você ainda não recebe solicitações de rota quando o número é discado, você pode precisar de reiniciar o JGW (ou para dar um ciclo o PG). Você precisa somente de reiniciar se você girou sobre o traço em JGW (traço *ROUTE*) e você vê que os erros que mostram o endereço não estão no fornecedor. Geralmente, o JGW deve poder reconhecer os pontos de rota novos CTI que são adicionados à lista de dispositivos do usuário sem a necessidade de reiniciar. Também, se as linhas são adicionadas a um ponto de rota CTI que já exista, o JGW não os reconhece sem a necessidade de reiniciar. Você deve poder evitar um reinício se você adicionar um ponto de ruta cti novo para cada número discado em vez das novas linhas aos dispositivos que já existem.
Nota: Isto supõe que o DeviceListPolling está girado sobre no arquivo JTAPI.ini no WinNT \ diretório das Javas \ liberal no PIM. Se o DeviceListPolling é desligado, você deve girar o DeviceListPolling sobre. Se o DeviceListPolling está desligado, e você adiciona todo o dispositivo à lista de usuários, você deve dar um ciclo o PG ou pelo menos o JTAPI GW para que o PG ver o dispositivo novo.
O opctest do uso para girar sobre a rota que segue “debuga /routing” e verifica logs OPC para ver se há erros quando os atendimentos são feitos ao ponto de rota. Verifique para ver que as solicitações de rota estão sendo recebidas e as etiquetas estão retornadas. As solicitações de rota aparecem como mensagens “CSTA_ROUTE_REQUEST” e “ICR_NEW_CALL_REQ”. As etiquetas retornadas aparecem como mensagens “ICR_CONNECT”. Se os erros ocorrem, você pode ver mensagens “ICR_DIALOGUE_FAIL” em vez das mensagens “ICR_CONNECT”. Neste caso, verifique o log de roteador para ver se há erros.
Use rtsetting.exe para girar sobre o traçado da rota e para verificar log de roteador para ver se há erros quando os atendimentos são feitos ao ponto de rota.
Certifique-se que todos os rótulos requerido estão configurados. Se seu script da rota visa agentes IPCC/EA, você deve ter as etiquetas configuradas para o cliente pós-roteamento para cada destino de dispositivo alvo.
Verifique o log de roteador para ver se há erros. Se não há nenhuns:
Se o nó da fila se enfileira à prioridade baixa, nada acontece quando o agente se torna disponível. Há a opção dois para fixar esta edição:
Há um ajuste do registro do roteador chamado AutoLoginBase (uso rtsetting.exe). Mude este ajuste para permitir que o atendimento seja enfileirado ao grupo de habilidades baixo para trabalhar mais como esperado ou a menos. Não há nenhuma preferência às habilidades secundárias excedentes preliminares quando este tipo de enfileiramento ocorre.
Enfileire ou aos grupos preliminares e/ou da habilidade secundária no nó da fila explicitamente.
Configurar a etiqueta para o destino do dispositivo na pergunta e nos todos alvos restantes a que este cliente de roteamento pode distribuir. Use a ferramenta de configuração do volume AW para que uma maneira de mais eficiente faça isto sobre configuram o ICR.
Os erros da rota devem ser seguidos incondicionalmente.
Você pode usar a ferramenta de rastreamento de chamada para testar o trajeto da rota.
Use a rtrtrace para girar sobre o traço da solicitação de rota e para verificar log de roteador para ver se há erros quando os atendimentos são feitos ao ponto de rota.
Certifique-se que todos os rótulos requerido estão configurados. Se o script da rota visa agentes IPCC/EA, você deve ter as etiquetas configuradas para cada destino de dispositivo alvo. Cada destino do dispositivo deve ter as etiquetas configuradas para cada cliente da rota que tenta enviar atendimentos. Assim, se um atendimento é PRE-roteado da rede diretamente a um agente disponível, o cliente de roteamento da rede deve ter uma etiqueta para o destino do dispositivo associado. Se o atendimento é enfileirado primeiramente em um VRU e entregado então ao agente, o cliente de roteamento VRU deve ter uma etiqueta para o destino do dispositivo associado.
Certifique-se de que o mapa do uso DN/Label não está verificado dentro a aba do cliente de roteamento dentro do explorador da configuração Manager/PG.
Use o procmon para girar sobre o traço no PIM (o traço pré-chamada, segue o *call_event*) e para verificar logs. O mensagem de pré-chamada aparece do roteador. Você igualmente vê que “DeliveredEvent” com o “DevTgDevStr” se ajustou à extensão de agente. Se o atendimento não aparece, assegure-se de que a etiqueta esteja correta para o cliente da rota.
O IPCC não apoia a opção para colocar uma posse chamar e para fazer um atendimento novo porque o CallManager da Cisco fornece resultados inconsistentes. Isto é considerado uma melhoria de produto e pode ser considerado para uma liberação futura.
Quando um atendimento da consulta é comutado/alternado/guardado/recuperado, o CallManager da Cisco quebra a associação da consulta. Isto conduz a um cenário de transferência arbitrária que não seja apoiado. Os agentes podem reconectar ao cliente e começar um novo consultar. O soft phone de IPCC desabilita o botão Alternate Button até que esteja resolved, mas os fornecedores de terceira parte podem queixar-se.
O CallManager da Cisco tem uma limitação que somente o iniciador de conferência pode adicionar mais partidos à conferência. Outros partidos não podem adicionar mais partidos no CallManager da Cisco.
Nas configurações de agente de desktop, há uma configuração de tempo para logout agentes não no estado pronto. O tempo máximo da inatividade é 2 horas mas você pode configurar o momento de ser menos. Os agentes no estado disponível não deverem ser registrado para fora quando no estado da inatividade. As transições de agente de pronto para não se aprontar se o temporizador do Ring No Answer expira (também uma configuração de agente de desktop configurável).
O CTI Server tem uma estadia configurada da pulsação do coração para fora. Uns computadores, uns servidores de CTI sobrecarregados, ou umas redes mais velhas com problemas de largura de banda podem ser a causa de raiz. Os logs do CTI Server devem relatar um erro no log.
As configurações de agente de desktop configuram dentro ICR (M) e o arquivo de configuração do agente ambos têm que concordar com como o agente é segurado.
Há um temporizador do trabalho na configuração de periférico no ICM nos parâmetros de configuração. Ajuste como dos parâmetros \ WORKTIMER 30 para ajustar um atraso 30-second em auto-disponível.
O arquivo de configuração de desktop reside em:
\program files\geotel\cti desktop\Desk_Settings.cfg
O modo de trabalho em entrante deve ser ajustado ao exigido, ao não exigido com dados em Desk_Settings.cfg e configurar ICR (M) configurações de agente de desktop. Exigido com dados substitui a opção auto-disponível.
Olhe o log do JTAPI GW e veja se há algum erro que indicar porque transferência de consulta falha. Verifique se o agente de software permita a posse/a recupere ou as operações alternadas na consulta chamem. Quando um ou outro atendimento é guardado/recuperado, o atendimento está considerado já não consultivo, mas transferência “arbitrária” pelo CallManager da Cisco. O CallManager da Cisco tem problemas com transferências arbitrárias. Limite o usuário para reconectar ou terminar transferência quando em um atendimento consultivo.
O CallManager da Cisco tem atualmente problemas com um evento da disconexão para uma conferência iniciada para consultar quando a conferência não é terminada. Desligue o atendimento um a segunda vez cancelar a aparência da chamada no telefone do agente.
Primeiramente, monitore o script ativo. Verifique então os logs do roteador, OPC, e PIM do cliente de roteamento e do VRU. A maioria de erros são seguidos incondicionalmente, mas você pode girar o traço obtém até uma imagem melhor do que acontece.
Está aqui a sequência da rota da tradução:
O cliente de roteamento faz um pedido de chamada novo ao roteador.
O roteador retorna uma conexão ao cliente de roteamento com uma etiqueta que deva entregar o atendimento ao IVR.
O IVR deve então enviar acima de uma RequestInstruction que os usos do VRU PG olhar acima o alvo periférico.
Os alvos periféricos dos fósforos do roteador da instrução do pedido com a tradução distribuem alvos periféricos que espera sobre.
O script de roteamento continua com script da corrida ou Nós da fila como projetado pelo cliente.
Monitore o script ativo para encontrar o caminho de falha. Olhe o rastreamento de roteador para erros. Verifique para ver se o cliente da rota recebe etiquetas iniciais. Verifique se o VRU recebe o atendimento. Verifique se o VRU envia acima de uma instrução do pedido a nível VRU PIM ou OPC.
Monitore o script e verifique se o pedido obtém à rota da tradução ao nó de VRU.
Primeiramente, no script da rota, um nó seleto seleto ou da rota com uma rota da tradução selecionada não é bastante para traduzir a rota ao serviço VRU controlado. Uma rota da tradução ao nó de VRU é exigida.
Em segundo, o monitor deve mostrar que o atendimento obtém ao nó de rota de tradução. Uma falha aqui significa que uma rota da tradução não pode ser determinada ou a mensagem da solicitação de rota da RequestInstruction não esteve recebida do IVR.
O erro do intervalo da rota da tradução indica que o roteador não recebe a instrução do pedido. Verifique o OPC e o VRU PIM para erros e para ver se a RequestInstruction chega.
Gire acima do “roteamento de tradução” e da “do tracing de VRU rede” com a ferramenta da rtrtrace no roteador para uma indicação melhor do que ocorre no roteador. No VRU PG OPC, gire acima do relatório do controle de serviço com o opctest.
A instrução do pedido deve indicar um grupo de troncos válido que trace a um número periférico de grupo de tronco em um dos grupos de troncos configurados para o VRU PG. Dê um ciclo o VRU PG para receber a atualização do número periférico de grupo de tronco, se alterado.
Certifique-se que o mapeamento da etiqueta DN está desligado no cliente de roteamento do IVR PG. O IVR PG precisa uma atribuição de VRU na rede. A rede VRU deve ser tipo-2. O IVR PG deve ter um grupo de tronco de rede e um grupo de troncos atribuídos. Proveja o grupo de tronco de rede no grupo de troncos.
O roteamento PG NIC/post deve ter uma etiqueta para cada um do DNIS nos alvos periféricos. (Faça às etiquetas o mesmos que o DNIS para o pedido para o cliente de roteamento no wizard da rota de tradução. Você pode ajustar este acima no prefixo, seleciona o prefixo = a opção DNIS.)
O cliente de roteamento VRU precisa uma etiqueta configurada para o destino do dispositivo a que distribui quando um agente se torna disponível.
As tampas desta seção do Cisco IP IVR como pesquisar defeitos erros de configuração entre o IVR DE IP e o ICM e incluem problemas comuns com a instalação para o IVR PG pós-roteamento e o roteamento de tradução. Refira o guia de Troubleshooting do Cisco IP IVR para obter mais informações sobre dos erros de IVR gerais.
Geralmente, verifique os logs MIVR sob o appadmin > o página da web do motor > dos arquivos de rastreamento.
Portas CTI IVR e pontos de rota CTI configurados no CallManager da Cisco, no IVR, e no ICM.
As portas CTI IVR e os pontos de rota CTI são associados com o usuário IVR no diretório global do CallManager da Cisco.
A caixa de verificação do controle de serviço é configuração IVR ICM dentro verificada.
Os nomes de script nas definições de script IVR combinam nomes de script da rede VRU no ICM.
O número de grupo de troncos no VRU PG combina o número do grupo de porta CTI no IVR DE IP.
Junto com todas as outras ações que você se usa para pesquisar defeitos, você pode igualmente tentar estas coisas ajudar a pesquisar defeitos o IVR DE IP.
Verifique o log MIVR. Este log pode geralmente apontar às áreas do problema.
O uso debuga ajustes para girar acima no Cisco IP IVR é SS_TEL e LIB_ICM.
Gire sobre o log do jtapi de Cisco para o IVR DE IP com os jtprefs no IVR DE IP. Veja ferramentas para debug. Pare e ligue o motor do IVR DE IP depois que você girar sobre o traço.
Verifique se o número do grupo da porta CTI no grupo de porta da rota da tradução do JTAPI do IVR DE IP combina o número periférico na configuração do grupo de troncos no ICM.
Verifique os logs do IVR DE IP sob arquivos de Engine-Trace para verificar se:
Execute o script é recebido.
O IVR DE IP pode encontrar o script. Scripts da transferência de arquivo pela rede com a ferramenta administrativa do repositório.
O IVR DE IP pode encontrar a alerta. As alertas definidas pelo utilizador residem \ wfavvid \ alertas \ usuário \ en_us \ no IVR DE IP.
Isto significa geralmente que alguns das portas CTI ou dos pontos de rota CTI configuradas no IVR DE IP não estiveram configurados e/ou estiveram associados com o usuário do IVR DE IP no CallManager da Cisco.
Isto pode igualmente significar que os scripts não estão nomeados corretamente ou para ter sido transferido arquivos pela rede ao gerenciador de repositório.
Geralmente, esta circunstância indica uma configuração parcial ou uma configuração incompatível em um lado ou no outro.
Este é um script de roteamento desconfigurado que permita demasiado pouco intervalo na configuração de script VRU de rede configure dentro o ICR.
Alguns dos scripts que estão disponíveis com o IVR DE IP para a relação ICM executam muito um muito tempo, mas o tempo padrão para fora na configuração de script de rede de ICM são três minutos. Se os tempos do script para fora e o trajeto da falha de script da corrida jogam um outro script da corrida, estes scripts da corrida obtêm basicamente enfileirados no IVR. Quando os scripts dequeued, você ouve muitos scripts jogar sobre se.
As estatísticas de IVR são importantes para relatórios do nível de serviço IPCC. Consequentemente, alguma informação em como pesquisar defeitos é incluída aqui. Como uma vista geral, as mudanças no roteador e o VRU PG onde os atendimentos executados no VRU são contados como enfileirados, em vez do conectado. Quando os atendimentos obtêm roteados, estão relatados como respondido. Quando o cliente na fila desliga atendimentos, estão relatados como abandonados. Refira readme.txt dos reparos quentes 53 e 54 para detalhes adicionais. O roteador envia abaixo dos eventos da fila especial que indicam que estado o atendimento é dentro no roteador.
Há um registro especial estabelecido no VRU PIM assim que você deve voluntariamente girar esta característica sobre a fim assegurar a interrupção mínima.
Os relatórios de tempo real 10 do serviço de empreendimento fazem o uso especial destes dados quando você adiciona os serviços VRU e serviços do CallManager da Cisco PG a uns ou vários relatórios do peripheral da empresa. Os relatórios de tempo real do serviço de empreendimento exigem que os serviços do VRU PG e do CallManager da Cisco PG estejam agrupados em um serviço de empreendimento para relatar finalidades.
Outros relatórios úteis da fila são os relatórios novos do tipo de chamada para o tempo real e os registros históricos, e a grade do tempo real do grupo de habilidades mostra agora os atendimentos enfileirados contra o grupo de habilidades.
O VRU PIM não gerencie eventos CSTA. Gire sobre o relatório do controle de serviço no VRU PG estabelecido. Isto está na chave de registro no ServiceControlQueueReporting abaixo:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\VRUData\Config
Nota: Esta chave de registro aparece sobre duas linhas aqui devido às limitações de espaço.
O log de startup para VRU PIM deve queixar-se se não existe.
Adicionar a chave do ServiceControlQueueReporting e ajuste o valor a 1 em:
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\VRUData\Config
Nota: Esta chave aparece sobre duas linhas aqui devido às limitações de espaço.
O log OPC indica que o mapeamento de serviço não está encontrado quando os atendimentos são contados contra o serviço incorreto ou não aparecem em relatórios do serviço.
Cisco ICM não é projetado para a correlação fácil de tabelas do tipo de chamada de dados, do serviço, e do grupo de habilidades. Os números têm geralmente significados levemente diferentes em cada grupo. Há somente um serviço para um atendimento, mas pode haver dois grupos de habilidades se mais de um agente é involvido. A característica do redirect on no answer (RONA) gerencie provavelmente uma outra rota do cargo sem a geração de um outro registro da terminação.
Sintoma: Os atendimentos segurados ou outros campos da estatística não combinam entre o serviço, o tipo de chamada, e/ou os relatórios do grupo de habilidades.
Condição: O tipo de chamada, serviço, e os grupos de habilidades estabelecem-se com um mapa lógico entre si, mas relatórios ainda não combina exatamente.
Pesquise defeitos: Se o volume da chamada é menos de 1 atendimento por segundo, gire sobre ajustes do traço no OPC, no PIM, e no JTAPI GW, como apropriado para o CSTA, o PIM, o AGENTE, e eventos da terceira. Refira a seção das ferramentas deste original para instruções.
Documente o fluxo de chamadas:
É a rota inicial do cargo no CallManager da Cisco PG ou VRU PG?
Dianteiro na sem resposta (FONA) é configurado e a que o FONA é configurado para reorientar?
É um grupo de habilidades do padrão configurado com número periférico 0 para separar atendimentos para fora distribuídos de NON-roteado e chamadas externas?
Agarre os dados históricos destas tabelas por um dia com “selecionam *” indicações:
Peripheral_Half_Hour
Call_Type_Half_Hour
Service_Half_Hour
Skill_Group_Half_Hour
Termination_Call_Detail
Route_Call_Detail
Quando você recolhe os traços no CallManager da Cisco, você pode girar as bandeiras da página de admin do CallManager da Cisco sob o Serviços > Rastrear Flags. 0xCB05 é um bom flag de rastreamento estabelecido para o SDL traçado dos erros CTI. Ajuste 0xCB05 sob parâmetros de serviço para debugam finalidades. Refira casos de TAC AVVID: Recolhendo a informação de Troubleshooting para mais informação. Refira a documentação on-line do CallManager da Cisco, incluindo guias de Troubleshooting.
Consulte para estabelecer traços do CallManager da Cisco para o Suporte técnico de Cisco para obter informações sobre de como girar sobre o traço para o CallManager da Cisco.
Refira a mudança dos endereços IP de Um ou Mais Servidores Cisco ICM NT do CallManager da Cisco e mude o nome do servidor.
Execute a instalação no CallManager da Cisco PG e mude serviços do JTAPI para o CallManager da Cisco PIM. Se você tem a mobilidade de extensão, e/ou os serviços de telefone.
Pare o Engine de CRA.
No CRA - Mude o endereço IP de Um ou Mais Servidores Cisco ICM NT sob a configuração de Engine.
Mude o IP sob o JTAPI.
Pare o serviço do DC Directory no server.
Mude o endereço IP de Um ou Mais Servidores Cisco ICM NT na configuração de diretório.
No CallManager da Cisco - mude o endereço IP de Um ou Mais Servidores Cisco ICM NT sob o sistema > servidor.
Mude o endereço IP de Um ou Mais Servidores Cisco ICM NT nas URL sob o sistema > parâmetros de empreendimento.
Mude o endereço IP de Um ou Mais Servidores Cisco ICM NT em todas as URL sob o Recursos > Serviços de Telefone.
Endereço IP do servidor da mudança - Propriedades de rede.
Mude a opção de DHCP 150 ao endereço IP de Um ou Mais Servidores Cisco ICM NT novo.
Mude o IP no perfil do hotel no DC Directory, CallManager da Cisco > Perfil de Sistema > Hoteling.
Abra o gerenciador de empreendimento SQL.
Mude endereços IP de Um ou Mais Servidores Cisco ICM NT nas URL na tabela de encaixe.
A fim suportar suas alterações de configuração:
Abra a configuração stiBackup.
Mude endereços IP do servidor sob todas as abas apropriadas.
Procmon é uma ferramenta da linha de comando que você possa usar para debugar processos PIM e de JTAPI GW.
Uso: processo do <node> do name> do <customer do procmon.
Ipcc pg1a pim1 de Procmon
Ipcc pg1a jgw1 de Procmon
Ctisvr do ipcc cg1a de Procmon
Estão aqui alguns ajustes úteis do traço para cada um dos processos:
JTAPI GW (procmon do uso)
traço JT_TPREQUESTS (gerencie sobre traços da requisição de terceira parte)
traço JT_JTAPI_EVENT_USED (gerencie sobre traços para os eventos JTAPI os usos PG)
traço JT_PIM_EVENT (gerencie sobre traços para os mensagens de evento enviados ao PIM)
traço JT_ROUTE_MESSAGE (gerencie sobre traços do cliente de roteamento)
traço JT_LOW* (traços baseados nas camadas subjacentes do JTAPI e CTI)
PIM (procmon do uso)
tp* do traço (gerencie sobre traços da requisição de terceira parte)
traço pré-chamada (gerencie sobre traços pré-chamadas do evento)
traço *event (gerencie sobre traços do agente e do evento de chamada)
csta* do traço (gerencie sobre traços do evento de chamada CSTA)
CTI SERVER (procmon do uso)
EMSTraceMask 0xf8 do regset (gerencie sobre os traços úteis do CTI Server, prováveis envolver ao redor)
O opctest é uma ferramenta da linha de comando para debugar o processo OPC no PG.
Uso: <node> de /node do name> do <customer de /cust do opctest
ipcc /node pg1a de /cust do opctest
Ajustes úteis
debugar /agent (gerencie sobre traços do evento do agente)
debugar /routing (gerencie sobre a distribuição de traços do evento)
debugar /cstacer (gerencie sobre traços do evento do csta)
debugar /tpmsg (gerencie sobre traços do pedido da chamada de terceiros)
Rttest é uma ferramenta da interface da linha de comando para debugar o processo de roteador no ICM. Veja a rtrtrace para a versão do GUI.
Uso: o ipcc o mais rttest de /cust
Ferramenta GUI para mudar ajustes do registro do roteador.
Há uma opção para ajustar ajustes de volta ao padrão.
Ferramenta GUI para girar sobre vários rastreamentos de roteador no ICM.
Os ajustes particularmente úteis para o IPCC são:
Enfileiramento – para os problemas que dequeuing.
Controle de serviço – para problemas com relação VRU.
Roteamento de tradução – para problemas com rotas da tradução.
Arquivos binários de Cisco ICM das descargas aos arquivos de texto. Mude diretórios ao diretório de arquivos de registro do processo.
O OPC, o PIM, e JtapiGW processar o arquivo de Log residem no icr \ <customer_name> \ <node> \ arquivo históricos \.
No PG, há um arquivo de lote chamado cdlog onde você datilografa o <node> do <cust> do >cdlog.
Uso: nome de processo do dumplog
Dumplog/” (para a ajuda em opções de dumplog diferentes)
Dumplog jgw1
Dumplog pim1
Opc do dumplog
Uma ferramenta para ver o arquivo de captura do VRU PG. Trabalha similar ao dumplog.
Ferramenta de Cisco ICM que você pode usar para debugar scripts de roteamento. Você pode encontrar esta ferramenta no item de menu AW no AW.
Esta é uma ferramenta para girar sobre traços do JTAPI para o cliente de JTAPI no IVR DE IP. Os traços do JTAPI no IPCC PG são controlados com a relação do procmon. Esta ferramenta reside nos arquivos de programa \ CiscoJtapiTools \.
Uma ferramenta administrativa do Microsoft Windows 2000 que mostre dados de tempo real para o CallManager da Cisco, o Cisco IP IVR, e o ICM. Você pode ver os atendimentos em andamento, os dispositivos registrados, e a utilização CPU do processo. Você pode encontrar esta ferramenta sob o iniciar > programas > ferramentas administrativas.
Os arquivos de registro de Cisco ICM residem em \ icr \ <cust> \ <node> \ arquivo históricos. Aqui, o cliente provê as referências pg1a do nome de instância do cliente e do nó, o ra para o roteador, o cg1a, e o mais. Use o dumplog para ver os arquivos de registro.
Nota: Você pode ver arquivos de captura do evento com as ferramentas do traço tais como o vrutrace. Estes arquivos estão em um diretório diferente.
Os arquivos de registro do CallManager da Cisco residem normalmente em \ arquivos de programa \ Cisco \ ccm \ traço com os diretórios do traço de:
Ccm - Logs do CallManager SDI.
Dbl - Logs da camada do base de dados.
Sdl - Logs da sinalização de chamada.
Tftp - Logs para o server de tftp.
Você pode alterar os ajustes do traço para estes arquivos da página de admin do CallManager da Cisco sob ajustes do traço. Você pode alterar ajustes do traço SDL sob parâmetros de serviço no CallManager da Cisco.
Os arquivo históricos do IVR DE IP residem em \ arquivos de programa \ wfavvid. Você pode igualmente ver arquivos de registro IPIVR da página appadmin sob arquivos de Engine-Trace.
Você pode ver logs do cliente Cisco JTAPI quando você gerencie sobre eventos JTAPI com o jtprefs.exe e reinicia o motor do IVR DE IP.
Quando você recolhe dados para abrir casos, recolha os dados alistados nesta seção, além do que os arquivos de registro.
Que é o número de agentes configurados?
Quantos gateways são configurados?
CallManager da Cisco, cliente de JTAPI, ICM, Versão do IOS do gateway, e IVR DE IP.
Você pode encontrar a versão do CallManager da Cisco no página da web admin do CallManager da Cisco sob o ajuda > sobre > os detalhes.
A fim encontrar a versão do cliente JTAPI, datilografe simplesmente o jview CiscoJtapiVersion em um comando prompt no diretório \ WinNT \ Javas \ liberal no CallManager da Cisco PG.
Você pode igualmente encontrar a versão do IVR DE IP.
Que tipo de IVR está no uso?
Que tipos de Plataformas estão no uso CPU/e na quantidade de memória física.