IPCC 문제 해결 가이드

소개

이 문서에서는 주변 장치 게이트웨이(PG) 및 Cisco ICM(Intelligent Contact Management)에 중점을 둔 IPCC(Internet Protocol Contact Center) 문제 해결에 대한 정보를 제공합니다. 이 문서에는 Cisco CallManager 및 Cisco Global Directory의 일반적인 문제에 대한 몇 가지 정보가 포함되어 있지만, 이 문서에서는 이러한 구성 요소를 완전히 설명하려고 시도하지는 않습니다. 오히려 이 문서에서는 PG가 보는 문제의 원인을 파악하기 위한 증상과 방법을 중점적으로 다룹니다.  소프트웨어 또는 컨피그레이션과 관련된 문제일 수 있습니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Cisco ICM PG 문제 해결 및 지원 방법

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• Cisco ICM 버전 4.6.2

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

증상 및 문제 해결 작업

IPCC에 대한 PG 로그를 확인합니다. PIM(Peripheral Interface Manager), OPC(Open Peripheral Controller) 또는 CTI(Computer Telephony Interface) 서버 로그에 지정되지 않은 오류가 표시되면 JTapi Gateway (GW) 로그로 직접 이동하여 문제에 대한 더 나은 텍스트 설명을 참조하십시오. JTAPI 인터페이스는 일반적으로 서드파티 요청에서 문제가 발생하는 경우 예외를 제공합니다. 이러한 예외는 오류 코드 없이 문자열 설명만 제공합니다. 따라서 PIM/OPC/CTI 서버는 많은 오류를 지정되지 않은 오류로 기록합니다.

Cisco IPCC PIM이 활성 상태가 아님

PIM 사용 안 함

PIM 로그가 있는지 확인합니다. PIM 로그가 없는 경우 Cisco ICM Setup에서 주변 장치가 활성화되었는지 확인합니다. 주변 장치가 추가되기도 하지만 주변 장치를 활성화해야 합니다.

Edit(편집) > Peripheral(주변 장치)을 선택하고 Enabled(활성화됨) 확인란을 선택합니다.

PIM 재시작

PIM 프로세스가 다시 시작되는 경우 dumplog 유틸리티를 사용하여 Cisco CallManager PG의 PIM 로그를 확인합니다. 로그 파일에 OPCHeartbeatTimeout 오류가 표시되면 이 레지스트리 설정을 수정해야 합니다. regedt32를 사용하여 변경합니다.

레지스트리에서 eagtpim 동적 데이터 아래의 OPCHeartbeatTimeout을 10으로 수정합니다. 경로는 다음과 같습니다.

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

참고: 이 키는 공간 제한으로 인해 여기에서 두 줄에 걸쳐 나타납니다.

PIM Log(PIM 로그) 창의 PIM in Idle State(유휴 상태의 PIM)

PIM 프로세스가 유휴 상태인 경우 다음 검사를 실행합니다.

• PIM 로그를 확인합니다. 1분에 한 번 이상 "활성화 시도"를 봐야 합니다.

• PIM이 활성 상태가 아니면 dumplog 유틸리티를 사용하여 OPC 로그를 확인합니다. opc 프로세스가 라우터에서 컨피그레이션을 수신하는지 확인하려면 opctest를 실행합니다.

• OPC 프로세스가 라우터에서 컨피그레이션을 수신하지 않는 경우 dumplog 유틸리티를 사용하여 pgagent 로그를 볼 수 있습니다. pgagent 프로세스에는 중앙 컨트롤러에 대한 활성 경로가 있어야 합니다. pgagent에 활성 경로가 없는 경우 PG 설정에서 네트워크 연결 및 DMP 컨피그레이션을 확인합니다. 라우터에서 dumplog 유틸리티를 사용하여 cagent 로그를 볼 수 있습니다. PG 디바이스(DMP System ID)가 라우터의 디바이스로 활성화되어 있는지 확인합니다.

• 설정을 통해 라우터 컨피그레이션에서 또는 DMP 레지스트리 아래의 레지스트리에서 PG를 활성화합니다.

• 명령 창에서 tracert 명령을 사용하여 라우터와 PG 간의 네트워크 연결을 확인합니다.

  참고: DNS와 DHCP 간에 차이가 있을 수 있습니다.

• 라우터의 IP 주소가 c:\winnt\system32\drivers\etc 디렉토리의 호스트 파일에 있는지 확인합니다.

• PG > 설정에 구성된 논리 컨트롤러 ID가 구성 > ICM에서 PG 논리 인터페이스 컨트롤러의 ID와 일치하는지 확인합니다. PG > 설정에서 주변 장치에 대해 구성된 주변 장치 ID가 구성 > ICM에서 주변 장치의 ID와 일치하는지 확인합니다.

• 컨피그레이션과 일치하도록 ICM 설정을 수정합니다.

JGW 프로세스가 활성화되지 않음

잘못된 버전의 Microsoft JVM(Java Virtual Machine)이 설치되었습니다.

• 명령 프롬프트로 이동하여 jview를 입력하고 Enter를 누릅니다. 설치된 Java 버전에 대한 정보가 나타납니다.

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

• 이 출력이 표시되지 않거나 버전이 3190 이전인 경우 올바른 버전의 Microsoft JVM을 설치해야 합니다. msjavx86.exe를 실행합니다. 이 파일은 설치 중에 icr\bin 디렉토리에 설치됩니다.

Java 클래스 경로가 잘못되었습니다.

• 명령 프롬프트에서 icr\bin 디렉토리로 이동하여 jtapigw를 입력하고 Enter 키를 누릅니다.  다음과 유사한 응답이 나타납니다.

  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)

• 또는 다음 메시지가 나타납니다.

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

• jtapigw를 실행할 때 두 번째 메시지가 표시되면 Java 클래스 경로를 확인합니다.  레지스트리 편집기를 사용하여 SOFTWARE\Microsoft\Java VM 키 아래의 Classpath 값을 확인합니다.  다음과 같이 키를 설정합니다.

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

참고: 드라이브 문자와 Windows 시스템 디렉토리는 다를 수 있으며 클래스 뒤와 c:\icr... 앞에 문자는 다음과 같습니다. 세미콜론, 마침표 및 세미콜론입니다.

Cisco JTAPI Client PG에 설치되지 않음

• 명령 프롬프트에서 icr\bin 디렉토리로 이동하여 jtapigw를 입력하고 Enter 키를 누릅니다.  다음과 유사한 응답이 나타납니다.

  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)

• 위 메시지 대신 다음 메시지를 볼 수 있습니다.

  Java.lang.NoClassDefFoundError

• jtapigw를 실행할 때 두 번째 메시지와 같은 메시지가 표시되면 Cisco JTAPI 클라이언트가 PG에 설치되어 있는지 확인합니다. c:\winnt\java\lib 아래의 CiscoJtapiVersion.class 파일을 확인합니다.

• 이 파일이 없으면 Cisco CallManager에서 PG에 파일을 설치할 수 있습니다. http://<callmanager name>/main.asp. 애플리케이션 탭에서 파일을 찾을 수 있습니다.

호환되지 않는 JTAPI 버전에 대한 JTAPI GW 로그 불만

• Cisco CallManager PG에 핫픽스가 50개 미만인 JTAPI 4.1 SP(서비스 팩) 4만 설치한 경우 업그레이드해야 합니다.

• ICM > Setup을 실행하여 PG를 업그레이드한 경우 \icr\bin\icrjavalib.zip 파일의 날짜/시간에 업데이트된 날짜가 표시되는지 확인합니다. 날짜는 약 일 이내에 bldXXXXX.version 파일의 날짜/시간과 거의 동일해야 합니다.

참고: 설치 프로그램을 실행할 때 이 파일이 사용 중이면 설치 프로그램에서 이 파일을 업데이트할 수 없습니다. 인터넷 브라우저가 열려 있으면 브라우저에서 zip을 열면 zip 파일이 클래스 경로의 디렉토리로 처리되므로 이 상황이 발생할 수 있습니다. 이 문제를 방지하려면 설치 프로그램을 실행하기 전에 모든 브라우저 세션을 닫으십시오.  설치 프로그램에서 파일을 업데이트할 수 없는 경우, 파일을 업데이트하기 위해 PC를 재부팅하라는 메시지가 나타납니다. 재부팅해야 합니다.

JTAPIGW에서 Cisco CallManager에 연결할 수 없습니다.

• PIM은 JTAPI 게이트웨이(JTAPI)와 통신하며 JTAPI는 Cisco CallManager와 통신합니다. PIM이 활성화하려고 하면 PIM은 JTAPI를 통해 Cisco CallManager와의 통신을 초기화하도록 JTAPIGW에 지시합니다.

• 다음과 같이 JTAPIGW가 PIM 및 연락처 getProvider()의 연결을 수락했음을 나타내는 메시지가 표시되어야 합니다.

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

  참고: 이 예는 공간 제한으로 인해 여러 행에 걸쳐 나타납니다.

성공적으로 반환된 추적이 표시되지 않으면 getProvider()를 호출한 후 다른 오류를 볼 수 있습니다.  getProvider()에 대한 추적은 JTAPI를 초기화하는 데 사용되는 매개 변수를 표시합니다.  첫 번째 매개변수는 서비스 이름이며, 이는 Cisco CallManager 시스템의 IP 호스트 이름 또는 IP 주소입니다.  이 예에서는 IP 주소가 사용됩니다.  이름이 사용되는 경우 PG는 호스트 파일 또는 DNS를 통해 이름을 확인할 수 있어야 합니다.  이름 또는 주소를 ping할 수 있는지 확인합니다.  서비스 이름을 변경해야 하는 경우 ICM > Setup을 다시 실행하고 Edit Peripheral(주변 장치 수정) 대화 상자에서 이름을 변경합니다.

getProvider() 호출의 추적에는 사용된 로그인 이름도 표시됩니다. 추적에는 비밀번호가 표시되지 않습니다. 로그인 이름과 비밀번호는 관리자가 ICM > 설정 아래 입력한 항목에서 가져옵니다. 이러한 항목은 디렉토리에 구성되어 있고 Cisco 사용자 기본 설정 웹 페이지에서 관리되는 유효한 사용자 및 비밀번호와 일치해야 각 에이전트 장치 및 경로 포인트를 제어할 수 있습니다. ICM > 설정에서 이름과 비밀번호가 올바른지 확인하십시오. 유효한 에이전트 장치 및 경로 포인트만 제어할 수 있는 권한을 갖도록 디렉토리의 사용자를 구성합니다.

JGW 로그가 알 수 없는 호스트를 나타냄

JTAPI GW 프로세스에서 Cisco CallManager의 주소를 확인할 수 없습니다. Cisco CallManager 호스트 이름 또는 IP 주소로 Setup(설정)의 PIM(PIM) 대화 상자에서 서비스 매개변수를 구성합니다. Cisco CallManager에 대한 호스트 이름 컨피그레이션이 올바른 경우 Cisco CallManager에 ping을 수행할 수 있는지 확인합니다. 그렇지 않은 경우 호스트 이름 대신 Cisco CallManager의 IP 주소를 사용합니다.

JGW 로그가 잘못된 비밀번호 또는 사용자를 나타냄

JTAPI GW는 사용자 이름과 비밀번호를 사용하여 Global Directory에 로그인합니다. 설치 프로그램의 PIM 대화 상자에 있는 사용자 이름 및 비밀번호는 Cisco CallManager 관리 웹 페이지의 ccmadmin > User > Global Directory에 있는 글로벌 디렉토리에 구성된 사용자의 사용자 이름 및 비밀번호와 일치해야 합니다.

사용자가 없는 경우 새 사용자를 추가합니다. 페이지 하단의 CTI Enabled 확인란을 선택해야 합니다.

CTI 확인란이 Global Directory User(전역 디렉토리 사용자) 페이지에서 활성화되지 않음

Cisco CallManager 전역 디렉토리 사용자 페이지의 확인란을 사용하여 PIM 또는 IP IVR 사용자에 대한 CTI 권한을 활성화하거나 비활성화할 수 있습니다. PIM/JTAPI GW를 활성화하려면 이 확인란을 선택하고 업데이트해야 합니다. 이 확인란을 선택하면 두 CTI 디바이스가 Cisco CallManager에 연결할 수 없으므로 문제가 발생할 수 있습니다(기본 제한은 400).

Cisco CallManager 서비스가 실행되지 않음

• Cisco CallManager 버전 3에서 이 서비스는 서비스 제어에서 "Cisco CallManager"로 표시됩니다. 서비스를 시작합니다.

• Cisco CallManager 서비스가 비정상적으로 종료되면 재시작하도록 일반적으로 설정되지만 장애 조치 시나리오에서 디바이스 마이그레이션에 발생할 수 있는 문제에 대해서는 "해제"로 구성할 수 있습니다.

• 이벤트 로그를 확인하여 Cisco CallManager 서비스가 다시 시작되는지 확인합니다. 시스템이 적절한 CPU 사용과 관련된 문제를 식별하면 시스템이 다시 시작되는 경우가 있습니다. 시스템은 "느린 SDL 타이머 스레드"를 나타내는 오류 또는 경고를 이벤트 로그에 보고합니다. 이러한 유형의 오류가 발생하면 Cisco CallManager가 다시 시작됩니다. 이 버전의 Cisco CallManager는 시스템에서 실행되는 다른 애플리케이션이 통화 신호를 방해할 수 있도록 일반 우선 순위에서 실행됩니다.

• 물리적 메모리가 부족하거나 시스템에서 다른 타이밍 문제가 발생하는 경우, Cisco CallManager에서 10분 시간 초과 후 초기화할 수 없음을 나타내는 오류를 발견하여 재시작할 수 있습니다. 초기화하는 동안 문제가 발생한 Cisco CallManager DBL(데이터베이스 계층)에 대한 DCOM 구성 요소 서비스가 있습니다. 이 문제를 해결하려면 구성 요소 서비스 - DCOM 구성 요소를 통해 이 DBL DCOM 서비스를 중지하고 시작합니다.

  참고: 이는 Cisco CallManager와 같은 시스템 서비스와 동일하지 않습니다.

  Cisco TAC(Technical Assistance Center)에서 케이스를 엽니다. 기본 타이밍 문제를 해결하지 않으면 다음에 시스템을 다시 시작할 때 이 문제가 발생할 수 있습니다.

디렉토리 문제(컨피그레이션, 실행 안 함, 디렉토리 비밀번호)

디렉터리 서비스가 실행되지 않음

• 디렉토리 서비스가 실행 중이고 올바르게 실행되는지 확인합니다.  기본적으로 Cisco CallManager 시스템의 서비스 제어에서 사용되는 DC 디렉토리 서버입니다. 기계를 작동시켜보세요 오류가 발생할 수 있습니다.

• 시스템에 메모리 또는 디스크 공간이 부족하면 디렉터리 서비스가 일시 중지된 상태로 전환될 수 있습니다. Microsoft Windows 2000 이벤트 로그에 오류가 나타납니다. 리소스 문제를 해결하고 필요한 경우 디렉터리 서비스를 다시 시작합니다.

Cisco CallManager 웹 사용자 페이지가 작동하지 않음

Cisco Global Directory 사용자 웹 페이지에서 실제로 사용자를 보고 구성하며 제어 장치에 권한을 할당할 수 있는지 확인합니다. JTAPIGW와 웹 페이지 모두 Cisco CallManager를 사용하여 디렉토리 서버에 액세스하여 사용자 및 권한에 액세스합니다. JTAPIGW의 문제가 디렉터리 서버 문제로 인한 경우 사용자 웹 페이지에도 문제가 있을 수 있습니다. 디렉터리 서버가 실행되지 않거나 디렉터리가 제대로 구성되지 않은 것(있는 경우)이 원인일 수 있습니다.

디렉터리 서버가 설치되지 않음

Cisco CallManager 3.0.5 이상을 사용하려면 디렉토리 서버를 설치해야 합니다. AVVID DC 디렉토리는 Spirian 설치 CD에서 사용할 수 있는 기본값입니다. 디렉토리 서버를 설치하면 Cisco CallManager가 디렉토리를 구성합니다.

이 설치를 올바르게 수행해야 하며, JTAPIGW가 Cisco CallManager에 로그인하고 JTAPI를 사용하려면 디렉토리 서버가 작동하고 올바르게 실행되어야 합니다.

DC 디렉터리 서비스와 Cisco CallManager가 모두 제대로 실행되는지 확인하십시오.

Cisco CallManager를 설치할 때 디렉토리 관리자 비밀번호 프롬프트가 표시되면 "ciscocisco"를 입력해야 합니다. 다른 내용을 입력한 경우 DC 디렉터리 소프트웨어를 제거하고(추가/제거) 다시 설치해야 할 수 있습니다. 제거 프로세스에서 일부 파일을 제거할 수 없다고 표시되면 수동으로 현재 c:\dcdsrvr 디렉토리를 제거하거나 이름을 변경해야 합니다.

디렉터리 서버가 설치되었지만 실행되지 않음

제어판에서 서비스를 시작할 수 없는지 확인합니다. 그런 다음 관리자가 구성되어 있는지, Properties(속성) 필드에서 서비스에 대한 로그인 및 비밀번호가 올바른지 확인합니다.

디렉터리 서버가 설치되어 실행되지만 DCD 관리 도구로 로그인할 수 없습니다.

시스템 시작 메뉴에서 DC 디렉터리 관리를 시작합니다. "ciscocisco"(기본값) 암호 또는 관리자가 구성한 모든 암호를 사용하여 사용자 디렉토리 관리자에 로그인합니다. 사용자가 구성되지 않았음을 나타내는 오류가 발생하면 DCDSrvr\bin 디렉토리에서 Cisco AVVID 컨피그레이션 파일 중 하나를 실행합니다. 기본 Cisco CallManager 게시자인 경우 DOS 프롬프트에서 avvid_cfg.cmd를 실행합니다. 보조 Cisco CallManager인 경우 명령 프롬프트에서 avvid_scfg.cmd를 실행합니다.

이미 구성되었음을 나타내는 오류가 표시되면 사용자가 존재하지 않는 것입니다. 오류가 없다면 지금 일이 제대로 되기 시작해야 한다. ccmadmin의 Global Directory User(글로벌 디렉토리 사용자) 페이지로 돌아가서 액세스를 확인합니다.

참고: DC 디렉터리의 시스템 리소스가 부족하면 DC 디렉터리가 일시 중지 모드로 전환됩니다.

에이전트가 로그인할 수 없음

이 예에서는 디바이스 대상에 대한 샘플 ICM 컨피그레이션을 사용합니다.

장치 대상 샘플
기업 이름	상담원9782755100
글로벌 주소	상담원9782755100
컨피그레이션 팜	/devtype CiscoPhone /dn 9782755100

다음 예에서는 에이전트에 대한 샘플 ICM 컨피그레이션을 사용합니다.

에이전트 샘플
주변 장치	CCMPG_PIM1
주변 장치 번호	1234
암호	XXX

PG에 대해 ICM > Setup을 실행할 때 에이전트 확장 길이를 "4"로 지정합니다. 따라서 샘플 컨피그레이션에서는 샘플 디바이스의 내선 번호가 /dn 매개 변수의 마지막 4자리 숫자입니다(예: "5100").

CTITest로 로그인합니다.

소프트폰으로 에이전트를 로그인할 수 없는 경우 ctitest를 통해 동일한 작업을 시도하십시오. 샘플 장치 대상에 샘플 에이전트를 로그인하는 데 사용할 수 있는 ctitest 명령의 샘플 목록입니다. 이 명령 목록에서는 CTI 서버가 CTIServerA 시스템의 포트 42027에서 수신 대기한다고 가정합니다. 이 목록에서는 또한 디바이스가 ICM 주변 장치 5000으로 표시된 주변 장치에 대한 확장인 것으로 가정합니다.

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

PIM 및 CTI 서버는 OPC에서 활성 상태가 아님

opctest "status" 명령을 사용하여 IPCC PIM 및 CTI 서버가 PIM_ACTIVE 및 CTI_ACTIVE 상태로 표시되는지 확인합니다. PIM 및 CTI Server 로그 창의 제목 표시줄도 프로세스 상태를 나타냅니다.

CTI 클라이언트가 연결할 수 없음

CTI 서버에 연결하기 위한 설정을 확인합니다. 데스크톱 소프트폰의 경우 설정은 .ini 파일(대개 c:\program files\geotel\cti desktop\cticonfig.ini)에 있습니다. 확인할 설정은 다음과 같습니다.

• PeripheralID - 이 값은 Configure(구성) > ICM의 IPCC 주변 장치에 대한 주변 장치 ID와 일치해야 합니다.

• SideAHost - 이 값은 CTI 서버 측 A의 IP 호스트 이름 또는 주소여야 합니다.

• SideBHost - 이 값은 CTI 서버 측 B의 IP 호스트 이름 또는 주소여야 합니다.  CTI 서버가 단순화되면 이 필드를 비워둘 수 있습니다.

• SideAPort - 이 값은 A측의 CTI 서버가 연결을 수신하는 포트와 일치해야 합니다. 이 값은 CTI 서버의 ICM 설정에서 지정합니다. CTI Server는 제목 표시줄에 이 포트를 표시하고 CTI Server가 시작될 때 이 값을 기록합니다. 클라이언트가 CTI 서버를 ping할 수 있는지 확인합니다.

CTI 클라이언트가 오류를 표시함 - 상담원이 ACD에 로그인해야 함

PG/CTI 서버의 \icr\bin 디렉토리에 있는 setup.exe를 실행합니다. CTI 게이트웨이 구성 요소를 선택합니다. Agent Login Required(에이전트 로그인 필요) 확인란이 선택 취소되었는지 확인합니다. IPCC 또는 서드파티 제어 애플리케이션에는 이 확인란 선택을 적용할 수 없습니다. 이 확인란의 목적은 다른 ACD 상담원이 애플리케이션을 모니터링하는 것입니다.

PIM 로그에는 다음 로그인 오류 중 하나가 표시됩니다

pim에 대해 procmon을 사용하고 "trace tp*"를 사용하여 서드파티 추적(대/소문자 구분)을 켭니다. 로그인 요청을 표시해야 합니다. 매개변수가 정확한지 확인합니다. 계측기는 "Device="로 추적됩니다. 이 값은 디바이스 대상 configparam의 /dn 문자열과 일치해야 합니다. 에이전트 ID는 "AgentID="로 추적됩니다. 이 값은 구성/ICM의 에이전트 주변 장치 번호와 일치해야 합니다.

• 잘못된 암호(_P)

  암호가 올바른지 확인하십시오(암호가 일반 텍스트로 추적되지 않을 수 있음). 비밀번호가 잘못된 경우 로그에 INVALID_PASSWORD_SPECIFIED 오류가 표시되어야 합니다.

• INVALID_OBJECT

  Device Target(디바이스 대상)의 컨피그레이션 매개 변수에 잘못된 디바이스 유형이 포함되어 있음을 나타냅니다. 이 오류는 키워드 사이에 공백이 있는 경우 다음과 같이 나타납니다.

  /devtype CiscoPhone /dn 9782755100

• INVALID_DEVICE_TARGET

  Device Target(디바이스 대상)에 있는 항목이 잘못되었음을 나타냅니다. Configuration parameters(컨피그레이션 매개변수) 필드에 있을 가능성이 높습니다. dumplog 유틸리티에서는 PIM이 마지막으로 재시작된 시간에 대한 PIM 로그를 확인합니다. 로그는 디바이스 대상을 검증하고 디바이스 대상 컨피그레이션 문자열이 잘못된 경우 오류를 기록합니다.

JGW 로그에 로그인 오류 표시

jgw 로그에서 로그인 시도 시 발생하는 모든 오류를 확인합니다. PIM에 대해 procmon을 사용하고 "trace *TP*"를 사용하여 서드파티 추적(대/소문자 구분)을 켭니다. "MsgAddCallObserver: 주소: XXXX" 여기서 XXXX는 로그인을 시도하는 내선입니다. 이 확장은 PG 사용자에게 제어 권한이 있는 디바이스에서 유효한 Cisco CallManager 확장이어야 합니다. 내선 번호는 Cisco CallManager가 알고 있는 전화기의 올바른 자릿수여야 합니다. 즉, 내선 번호는 해당 전화기에 연결하기 위해 동일한 Cisco CallManager에 있는 다른 전화기에서 다이얼하는 번호여야 합니다.

디바이스가 공급자 도메인에 없음

jgw 로그에 예외가 표시되면 디바이스가 사업자 도메인에 있지 않음을 나타내는 경우, 전화기는 JTAPI GW가 로그인하는 사용자와 연결되지 않습니다. Global Directory 사용자 장치 연결 목록의 맨 끝에 있는 내선 번호가 올바른지 확인하십시오. 또한 디바이스 라인 번호가 두 번 등록되지 않았는지 확인합니다. 공유 회선 기능은 IPCC에서 지원하지 않는 Cisco CallManager 기능입니다. 실수로 같은 회선을 사용하는 두 개의 전화기로 공유 회선 모양을 설정하려고 할 수 있습니다. 회선 번호 하나를 변경하면 다른 번호가 변경되고 PG가 올바른 디바이스에 로그인할 수 없습니다. 이 문제를 해결하려면 두 행을 모두 삭제하고 Cisco CallManager에 추가하십시오.

INVALID_SKILL_GROUP_SPECIFIED

로그인하려면 에이전트가 구성/ICM에서 하나 이상의 직무 그룹(직무 그룹 구성원)의 구성원으로 구성되어야 합니다.

상담원이 이미 다른 전화기에 로그인했습니다.

상담원 주변 장치 번호가 나타내는 대로 상담원이 다른 장치 대상에 아직 로그인되어 있지 않은지 확인합니다. 이를 확인하는 한 가지 방법은 모니터 ICR을 실행하고 문제의 에이전트에 대해 [에이전트에서 사용 가능] 보고서를 실행하는 것입니다. 상담원이 로그인하면 상담원이 로그인된 장치 대상의 네트워크 대상 ID가 표시됩니다. 주변 장치에 대한 에이전트 데이터를 이 AW로 전송하도록 ICM을 구성한 경우에만 에이전트 데이터가 awdb에 나타납니다.

• 또한 awdb의 Agent_Real_Time 테이블에 대해 isqlw에서 이를 쿼리할 수 있습니다. 먼저 상담원에 대한 기술 대상을 찾습니다(예: PeripheralID가 XXX이고 PeripheralNumber가 YYY인 상담원에서 * 선택). 그런 다음 상담원이 로그인되어 있는지 확인합니다(예: SkillTargetID가 XXX인 경우 Agent_Real_Time에서 * 선택).

• PIM에 procmon에 연결하여 dagent <agent peripheral number>를 실행할 때도 이 점을 확인할 수 있습니다.

디바이스 대상이 이미 로그인됨

장비가 지정하는 대로 디바이스 대상에 이미 다른 에이전트가 로그인되어 있지 않은지 확인합니다.

• 이를 확인하는 한 가지 방법은 awdb의 Agent_Real_Time 테이블에 대해 isqlw를 실행하는 것입니다. 먼저 해당 디바이스 대상의 네트워크 대상 ID를 찾습니다. 예를 들어 ConfigParam이 '%1003%'인 경우 Device_Target에서 *를 선택합니다. 이제 디바이스 대상이 로그인되어 있는지 확인합니다. 예를 들어 NetworkTargetID = XXX인 경우 Agent_Real_Time에서 *를 선택합니다.

• PIM에 procmon에 연결하여 디바이스 대상을 덤프할 때도 이를 확인할 수 있습니다. 디바이스 대상을 덤프하는 방법에는 두 가지가 있습니다. ddt 명령은 네트워크 대상 ID를 입력으로 사용하여 디바이스 대상을 덤프합니다. deadt 명령은 디바이스 대상 컨피그레이션에서 /dn 문자열을 입력으로 가져와 디바이스 대상을 덤프합니다. 예를 들어, 디바이스 대상 /dn 문자열이 /dn 9782755100이면 디바이스 대상을 deadt 9782755100으로 덤프합니다.

PG 사용자와 연결되지 않은 장치

Cisco CallManager 웹 페이지로 이동하여 User/Global Directory를 선택하고 PG가 사용하는 사용자 ID를 찾습니다. "연결된 장치"를 확인하고 사용자에게 장치를 제어할 권한이 있는지 확인합니다.

• 사용자 페이지에서 디바이스를 찾을 수 없는 경우(선택 또는 선택 취소), 데이터베이스(Cisco CallManager가 디바이스를 저장하는 위치)와 디렉토리 서버(디바이스를 저장하고 사용자 프로필을 저장하는 위치) 간의 동기화에 문제가 있을 수 있습니다. 디렉터리 서버(DC 디렉터리 서버)가 실행되는지 확인합니다.

• Windows NT 이벤트 뷰어 응용 프로그램 로그를 확인하고 DC 디렉터리 또는 metalink에서 오류를 찾습니다. 가져오기 오류가 발생하면 c:\dcdsrvr\bin에서 avvid_recfg를 실행합니다.

• Cisco CallManager 시스템에 Microsoft JVM(Java Virtual Machine)이 설치되어 있는지 확인합니다. 이를 테스트하려면 명령 프롬프트에서 jview를 입력합니다. Cisco CallManager 2.4의 경우 JVM을 수동으로 설치해야 합니다. Cisco CallManager 3의 경우 플랫폼은 Windows 2000이고 JVM 설치는 자동입니다.

전화 장치가 활성 상태가 아님

전화기의 전원이 켜져 있고 Cisco CallManager에 등록되어 있으며 상담원 제어 없이 전화기에서 전화를 걸고 받을 수 있는지 확인합니다.

상담원이 전화를 걸 수 없음

상담원 준비 안 됨 상태

상담원이 로그인되어 있고 사용 가능 상태가 아닌지 확인합니다.  상담원을 사용할 수 없는 경우 상담원이 전화를 걸 수 없습니다. 전화를 걸려면 먼저 Not Ready(통화 불가능)를 클릭합니다.

잘못된 상담원 데스크 설정

특정 번호를 다이얼할 때만 오류가 발생하는 경우, 물리적 전화기에서 해당 번호를 확인하여 성공적으로 다이얼인할 수 있는지 확인합니다. ICM 전화 건 번호 요금제를 구성한 경우 전화 건 번호가 전화 건 번호 요금제의 와일드카드 중 하나와 일치하는지 확인합니다. 그런 다음 상담원에 대한 상담원 데스크 설정이 전화를 건 번호 계획 항목이 식별하는 번호 유형(예: 국제)을 상담원이 다이얼할 수 있도록 허용하는지 확인합니다.

PIM 블록 액세스에서 전화 건 번호 요금제

각 PIM에 대해 구성된 전화 건 번호 플랜을 잘못 구성하거나 에이전트가 특정 번호로 발신하지 못하도록 올바르게 구성할 수 있습니다. PIM 로그의 오류는 권한 오류를 나타내야 합니다. 전화를 건 번호 요금제를 사용하여 상담원을 상담원 대 상담원 통화에 사용하는 경우 상담원 및 장치 번호가 중복될 수 없습니다.

상담원이 짧은 통화를 하므로 새 전화를 걸 때까지 기다려야 합니다.

라우터는 상담원이 전화를 걸거나 상담원에게 통화가 라우팅될 때 상담원을 사용할 수 없게 합니다. 이 메커니즘은 라우터가 PIM에서 통화가 도착했다고 보고하기 전에 다른 통화를 에이전트로 라우팅할 수 있도록 합니다. 일부 네트워크는 실제로 통화를 라우팅하는 데 몇 초가 걸립니다. 라우터는 에이전트 상태를 기준으로 타이머를 취소하지 않습니다.

라우팅 클라이언트에서 PIM으로 통화를 라우팅하는 데 걸리는 실제 시간이 비교적 짧은 경우 라우터에서 구성 가능한 시간을 변경할 수 있습니다. DOS 명령 창의 라우터 중 하나에서 rtsetting.exe를 사용합니다. Extrapolation(외삽) > Agent(상담원)를 살펴봅니다. 기본 설정은 10초입니다. 값이 너무 짧으면 라우터는 통화를 수신하려고 하는 에이전트에게 통화를 라우팅합니다. 그러면 PIM에서 통화를 삭제합니다.

PIM의 기본 시간 제한은 7초입니다. regedt32 명령을 사용하여 이 값을 수정할 수 있습니다. 이 경로에 "AgentReserveTimeout" 키를 추가합니다.

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

참고: 이 키는 버전 4.1.5 설정에 추가됩니다.

참고: 이 키는 공간 제한으로 인해 여기에서 두 줄에 걸쳐 나타납니다.

원래 이벤트가 처리되기 전에 라우터가 새 사전 호출 이벤트를 PIM에 전송하지 못하게 하려면 PIM 번호는 항상 라우터 외삽 타이머보다 몇 초 적어야 합니다. 이로 인해 PIM에 문제가 발생합니다.

PIM 시간 초과 후 통화가 수신되면 해당 통화는 비 ACD 통화로 간주되며 컨텍스트 변수, 서비스 또는 직무 그룹 정보가 통화에 할당되지 않습니다.

상담원이 이동할 수 없음 - 준비 안 됨, 통화 중 또는 기타

"활성" 상태의 상담원

상담원이 통화 중이고 통화 불가능, 통화 중 또는 기타를 클릭하면 상담원 상태가 즉시 변경되지 않습니다. 이것은 의도적인 것입니다. 상담원은 통화가 완료될 때까지 통화 또는 보류 상태로 유지됩니다. 상담원은 누른 단추에 따라 준비 안 됨, 작업 준비됨 또는 작업 준비 안 됨으로 전환됩니다. 통화가 끝난 후 상담원이 사용 가능으로 즉시 전환되는 경우, 상담원에 대한 상담원 데스크 설정을 확인하고 Available After Incoming(수신 후 사용 가능) 또는 Available After Outgoing(발신 후 사용 가능)이 설정되어 있는지 확인해야 합니다. 이러한 설정은 상담원이 통화 중 단추로 수행하는 작업을 재정의합니다.

상담원 데스크 설정 전환 금지

Configure ICM(ICM 구성)에서 에이전트에 대한 에이전트 데스크 설정을 확인하고 Idle Reason Required(유휴 사유 필요)가 선택되었는지 확인합니다. 이 확인란을 선택하면 상담원은 사유 코드 없이 통화 불가능 상태로 전환할 수 없습니다. ICM 구성의 에이전트 데스크 설정과 일치하도록 Desktop_Settings.cfg를 수정하거나 ICM 구성에서 에이전트 데스크 설정을 변경합니다.

상담원에게 할당된 상담원 데스크 설정이 없는 경우 상담원은 로그인하여 준비 상태로 전환할 수 있지만 상담원은 not_ready 상태로 전환하거나 로그아웃할 수 없습니다. 해결책은 상담원 응용 프로그램을 닫고 상담원 데스크 설정을 할당한 후 다시 로그인하는 것입니다.

상담원이 준비 안 됨 상태로 전환하려면 기다려야 합니다.

라우터는 상담원이 전화를 걸거나 상담원에게 통화가 라우팅될 때 상담원을 사용할 수 없게 합니다. 이 메커니즘은 라우터가 PIM이 통화를 수신 상태로 보고하기 전에 다른 통화를 에이전트로 라우팅할 수 있도록 합니다. 일부 네트워크는 실제로 통화를 라우팅하는 데 몇 초가 걸립니다. 라우터는 에이전트 상태를 기준으로 타이머를 취소하지 않습니다.

라우트 클라이언트에서 PIM으로 통화를 라우팅하는 데 걸리는 실제 시간이 비교적 짧은 경우 라우터에서 구성 가능한 시간을 변경할 수 있습니다. DOS 명령 창의 라우터 중 하나에서 rtsetting.exe를 사용합니다. Extrapolation(외삽) > Agent(상담원)를 살펴봅니다. 기본값은 10초입니다. 값이 너무 짧으면 라우터는 통화를 수신하려고 하는 에이전트에게 통화를 라우팅합니다. 그러면 PIM에서 통화를 삭제합니다.

상담원이 준비될 수 없음

PRIVILEGE_VIOLATION_ON_SPECIFIED_DEVICE

로그인 요청과 준비 요청에 대한 데이터가 일치하지 않습니다. 계측기, 상담원 ID 또는 주변 장치 번호가 일치하지 않을 수 있습니다. procmon을 사용하여 CTI 서버 추적을 켜고 regset을 0xf8로 설정하여 적절한 추적을 확인합니다. 서드파티(TP) 추적이 설정된 경우 OPC 또는 PIM 로그에서도 이를 볼 수 있습니다.

상담원이 로그아웃할 수 없음

상담원 현재 상태로 인해 통화 불가능

상담원이 작업 준비됨, 작업 준비 안 됨 또는 사용 가능 상태인 경우 상담원은 로그아웃하기 전에 먼저 준비 안 됨으로 전환해야 합니다. ICM 구성의 에이전트 데스크 설정과 일치하도록 Desktop_Settings.cfg를 수정하거나 ICM 구성에서 에이전트 데스크 설정을 변경합니다.

상담원 데스크 설정으로 인해 상태 변경이 방지됨

상담원이 준비 안 됨 상태이지만 여전히 로그아웃할 수 없는 경우 ICM 구성에서 상담원에 대한 상담원 데스크 설정을 확인하고 로그아웃 사유 필요가 선택되었는지 확인합니다.

상담원이 활성 통화 또는 상담원 통화 내용을 표시하지만 전화 통화는 표시하지 않음

상담원 로그아웃 후 다시 로그인

소프트폰에 더 이상 물리적으로 존재하지 않는 통화가 표시되면 상담원 상태가 통화 또는 보류로 고착되어 상담원이 로그아웃할 수 없습니다. 이는 JTAPI 또는 PIM의 소프트웨어 버그 때문일 수 있습니다. 조건을 지우려면 먼저 릴리스 버튼이 활성화된 경우 소프트폰에서 통화를 지웁니다. 이 방법이 작동하지 않으면 상담원을 로그아웃시키십시오. 로그아웃 단추가 작동하지 않으면 소프트폰을 종료하고 다시 시작합니다. 상태가 지속되면 소프트폰을 종료하고 작업 관리자를 실행하고 geodcs.exe 및 common~1.exe를 종료하고 소프트폰을 다시 시작합니다. 이러한 프로세스는 계속 실행되어 잘못된 에이전트 상태를 기억할 수 있습니다.

PIM에서 상담원 상태가 올바르지 않습니다.

promon에서 PIM의 에이전트 상태를 확인합니다. Agent Desktop을 다시 시작했는데 상태가 명확하지 않으면 추가 조치를 수행할 수 있습니다. CTI 서버 및 OPC는 procmon 또는 opctest의 디버그 인터페이스를 사용하여 통화를 지우는 메커니즘을 제공합니다. 이는 PG 서비스를 순환하거나 적어도 PIM 창을 닫는 다른 옵션보다 약간 선호하는 옵션입니다.

알림 또는 설정 후 통화 지우기

레지스트리 설정이 잘못되었습니다.

regedt32를 사용하여 다음 레지스트리 설정을 확인합니다.

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

및

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

참고: 이 레지스트리 키는 공간 제한으로 인해 여기에서 두 줄에 걸쳐 나타납니다.

이러한 값을 각각 300과 28800으로 설정합니다.

포스트 라우팅이 작동하지 않음

경로 및 경로 스크립트 확인

AW Call Tracer 툴을 사용하여 통화가 스크립트에 도달하고 스크립트가 올바르게 실행되는지 확인합니다. 스크립트 편집기를 실행하고 스크립트를 모니터링합니다. 라우터, OPC 및 PIM 로그에서 문제를 확인합니다. 대부분의 경로 오류는 무조건 추적됩니다.

주변 장치의 라우팅 클라이언트에 대해 'DN 레이블 맵 사용' 선택

ICM 구성에 각 라우팅 클라이언트에 대한 설정이 "Use DN/Label Map(DN/레이블 맵 사용)"으로 표시되어 있습니다. 이 설정을 "예"로 설정하면 전화를 건 번호와 가능한 대상 레이블의 각 조합에 대해 "전화 건 번호 레이블" 항목을 구성해야 합니다. 이 설정은 PG 라우팅 클라이언트에서는 유용하지 않으며 "아니요"로 설정해야 합니다.

라우티드 디바이스 대상에 대해 구성된 레이블 없음

라우팅 클라이언트에 구성된 레이블을 확인합니다. 각 클라이언트의 레이블이 동일한 경우에도 각 클라이언트의 레이블을 구성해야 합니다.

CTI 경로 포인트가 Cisco CallManager에 구성되지 않았습니다.

Post 라우팅을 사용하려면 Cisco CallManager에서 "CTI 경로 포인트"를 구성하고 원하는 디렉토리 번호(예: "5000")로 경로를 경로 포인트에 할당해야 합니다. 상담원 통화의 라우팅 게시를 위해 전화 건 번호 요금제를 사용합니다. Cisco CallManager CTI Route Point로 전화를 거는 상담원은 CTI Desktop 버전 4.1.9의 IPCC 소프트폰을 혼동합니다.

CTI 경로 포인트에 대한 디바이스가 PG 사용자가 제어하는 디바이스 목록에 없음

Cisco CallManager 사용자 웹 페이지의 전역 디렉터리 아래에 있는 PG 사용자에 대한 "연결된 장치" 목록에 CTI 경로 포인트 장치를 추가해야 합니다. 새 디바이스를 생성하는 경우 먼저 행을 추가한 다음 사용자 "Associated Devices(연결된 디바이스)" 목록에 디바이스를 추가합니다. 사용자 디바이스 목록에 이미 있는 디바이스에 라인을 추가하는 경우 JGW가 새 라인을 인식하도록 JGW를 다시 시작해야 합니다. 그러나 새 디바이스를 추가하고 디바이스에 라인을 추가한 다음 디바이스를 사용자 디바이스 목록에 추가하면 JGW가 새 디바이스를 인식할 수 있어야 합니다(약 30초 이내).

Cisco ICM에 구성된 전화 건 번호 없음

전화를 건 번호를 확인하여 해당 번호가 주변 장치 라우팅 클라이언트에 대해 구성되어 있는지 확인합니다. JGW로의 procmon을 실행하고 "trace *ROUTE*"(대/소문자 구분)로 추적을 켭니다. JGW 로그에서 전화를 건 번호와 관련된 오류를 확인합니다. 시작 시 JGW는 전화를 건 번호에 대한 경로 콜백을 등록하려고 시도합니다. 전화를 건 번호로 전화를 걸면 게이트웨이에서 "RouteEvent"를 수신합니다.

전화 건 번호와 함께 통화 유형이 생성되어 스크립트에 올바르게 매핑되었는지 확인합니다.

JGW 재시작이 필요하지 않은지 확인

ICM 전화 건 번호를 구성했고 CTI 경로 포인트를 설정했으며 사용자 디바이스 목록에 추가했지만 해당 번호로 전화를 걸어도 경로 요청이 수신되지 않는 경우 JGW를 다시 시작하거나 PG를 순환해야 할 수 있습니다. JGW에서 추적을 켜고(trace *ROUTE*) 주소가 공급자에 없음을 나타내는 오류가 표시되는 경우에만 재시작해야 합니다. 일반적으로 JGW는 다시 시작할 필요 없이 사용자 디바이스 목록에 추가된 새 CTI 경로 포인트를 인식할 수 있어야 합니다. 또한 이미 존재하는 CTI Route Point에 라인이 추가되면 JGW는 재시작할 필요 없이 이를 인식하지 못합니다. 이미 존재하는 디바이스에 새 회선 대신 전화를 건 각 번호에 대해 새 CTI 경로 포인트를 추가하는 경우 재시작을 방지할 수 있어야 합니다.

참고: PIM의 winnt\java\lib 디렉터리에 있는 JTAPI.ini 파일에서 DeviceListPolling이 설정된 것으로 가정합니다. DeviceListPolling이 꺼져 있는 경우 DeviceListPolling을 켜야 합니다. DeviceListPolling이 꺼져 있고 사용자 목록에 디바이스를 추가하는 경우 새 디바이스를 보려면 PG를 순환하거나 PG에 대해 JTAPI GW 이상을 순환해야 합니다.

OPC 로그에서 경로 대화 상자 확인

opctest를 사용하여 경로 추적 "debug /routing"을 설정하고 경로 지점에 대한 호출이 수행될 때 OPC 로그에서 오류를 확인합니다. 경로 요청을 수신하고 레이블을 반환하는지 확인합니다. 경로 요청은 "CSTA_ROUTE_REQUEST" 및 "ICR_NEW_CALL_REQ" 메시지로 나타납니다. 반환된 레이블은 "ICR_CONNECT" 메시지로 표시됩니다. 오류가 발생하면 "ICR_CONNECT" 메시지 대신 "ICR_DIALOG_FAIL" 메시지를 볼 수 있습니다. 이 경우 라우터 로그에서 오류를 확인합니다.

라우터 로그에서 경로 대화 상자 확인

rtsetting.exe를 사용하여 경로 추적을 설정하고 경로 지점에 대한 통화가 수행될 때 라우터 로그에서 오류를 확인합니다.

모든 필수 레이블이 구성되어 있는지 확인합니다. 경로 스크립트가 IPCC/EA 에이전트를 대상으로 하는 경우 각 대상 장치 대상에 대해 Post Routing 클라이언트에 대해 구성된 레이블이 있어야 합니다.

상담원이 사용 가능해지면 라우팅 스크립트에서 통화 대기열에서 빼지 않음

라우터 로그에서 오류를 확인합니다. 없는 경우

라우터 로그에 오류 없음 — 대기열 노드가 직무 그룹 기본 우선 순위로 대기됩니다.

대기열 노드가 기본 우선순위에 대기하면 에이전트가 사용 가능해지면 아무 일도 일어나지 않습니다. 이 문제를 해결하기 위한 두 가지 옵션이 있습니다.

• AutoLoginBase라는 라우터 레지스트리 설정이 있습니다(rtsetting.exe 사용). 기본 직무 그룹에 대한 통화 대기열이 예상대로 더 많이 또는 적게 작동하도록 이 설정을 변경합니다. 이러한 유형의 대기가 발생할 경우 보조 기술보다 기본 기술을 선호하지 않습니다.

• 대기열 노드의 기본 및/또는 보조 직무 집합에 명시적으로 대기합니다.

라우터 로그는 대상에 대해 구성되지 않은 레이블을 나타냅니다.

문제의 장치 대상 및 이 라우팅 클라이언트가 라우팅할 수 있는 다른 모든 대상에 대한 레이블을 구성합니다. ICR을 구성하는 것보다 효율적인 방법으로 AW 대량 컨피그레이션 툴을 사용합니다.

모든 상담원 및 대기열 포트가 사용 중일 때 벨울림 응답 없음

라우터 로그 확인

• 경로 오류는 무조건 추적해야 합니다.

• 통화 추적기 툴을 사용하여 경로 경로를 테스트할 수 있습니다.

• rtrtrace를 사용하여 경로 요청 추적을 켜고 경로 포인트로 전화를 걸 때 라우터 로그에서 오류를 확인합니다.

• 모든 필수 레이블이 구성되어 있는지 확인합니다. 경로 스크립트가 IPCC/EA 에이전트를 대상으로 하는 경우 각 대상 장치 대상에 대해 레이블이 구성되어 있어야 합니다. 각 디바이스 대상에 통화를 전송하려는 각 경로 클라이언트에 대해 구성된 레이블이 있어야 합니다. 따라서 통화가 네트워크에서 사용 가능한 에이전트로 직접 사전 라우팅되는 경우 네트워크 라우팅 클라이언트에는 연결된 장치 대상에 대한 레이블이 있어야 합니다. 통화가 VRU에서 처음 대기열에 추가된 다음 상담원에게 전달되는 경우 VRU 라우팅 클라이언트에는 연결된 장치 대상에 대한 레이블이 있어야 합니다.

ICM 구성의 라우팅 클라이언트에서 DN 레이블 매핑이 꺼져 있는지 확인합니다.

Configuration Manager/PG Explorer의 Routing Client(라우팅 클라이언트) 탭에서 Use DN/Label map(DN/레이블 맵 사용)이 선택되어 있지 않아야 합니다.

PIM 로그 확인

• procmon을 사용하여 PIM에서 추적을 켜고(trace precall, trace *call_event*) 로그를 확인합니다. 통화 전 메시지가 라우터에서 나타납니다. 또한 에이전트 내선 번호로 설정된 "DevTgDevStr"의 "DeliveredEvent"를 볼 수 있습니다. 통화가 표시되지 않으면 라우트 클라이언트에 대한 레이블이 올바른지 확인합니다.

임의 전송으로 일관성 없는 결과 발생

IPCC는 Cisco CallManager가 일관성 없는 결과를 제공하므로 통화를 보류하고 새 통화를 발신하는 옵션을 지원하지 않습니다. 이는 제품 개선으로 간주되며 향후 릴리스에서 고려될 수 있습니다.

대안이 작동하지 않음

상담 통화가 전환/대체/보류/검색되면 Cisco CallManager가 상담 연결을 끊습니다. 따라서 지원되지 않는 임의 전송 시나리오가 발생합니다. 상담원은 고객과 다시 연결하고 새 상담을 시작할 수 있습니다. IPCC 소프트폰은 교대 버튼이 해결될 때까지 비활성화하지만 서드파티 벤더가 불만을 제기할 수 있습니다.

전화회의 상대방은 다른 상대방과 전화회의를 할 수 없습니다.

Cisco CallManager에는 전화회의 개시자만 전화회의에 상대방을 더 추가할 수 있다는 제한이 있습니다. 다른 상대방은 Cisco CallManager에서 더 많은 상대방을 추가할 수 없습니다.

에이전트 스테이션이 예기치 않게 로그아웃되었습니다.

상담원 데스크 설정 비활성 타이머

상담원 데스크 설정에는 준비 안 됨 상태의 상담원을 로그아웃하는 시간 설정이 있습니다. 최대 비활성 시간은 2시간이지만 더 짧게 구성할 수 있습니다. 사용 가능 상태의 상담원은 비활성 상태일 때 로그아웃되지 않습니다. 벨울림 응답 없음 타이머가 만료되면 상담원이 준비됨에서 준비 안 됨으로 전환됩니다(구성 가능한 상담원 데스크 설정도 포함).

CTI 서버 하트비트 시간 초과

CTI 서버에 구성된 하트비트 시간 초과가 있습니다. 오래된 컴퓨터, 과로한 CTI 서버 또는 대역폭 문제가 있는 네트워크가 근본 원인이 될 수 있습니다. CTI 서버 로그는 로그에 오류를 보고해야 합니다.

상담원이 상담원 데스크 설정에서 구성한 대로 작동하지 않음

Configure ICR(M)(ICR 구성)의 에이전트 데스크 설정과 에이전트 컨피그레이션 파일은 모두 에이전트 처리 방법에 동의해야 합니다.

구성 매개 변수의 ICM에 있는 주변 장치 구성에 작업 타이머가 있습니다. 매개변수를 \WORKTIMER 30으로 설정하여 자동 사용 가능에서 30초 지연을 설정합니다.

데스크톱 컨피그레이션 파일은 다음 위치에 있습니다.

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

Desk_Settings.cfg의 데이터 및 ICR(M) 에이전트 데스크 구성 설정에서 Incoming의 작업 모드를 Required, not Required로 설정해야 합니다. 데이터는 자동 사용 가능 옵션보다 우선합니다.

상담 전송 실패

JTAPI GW 로그를 참조하여 상담 전송 실패 이유를 나타내는 오류가 있는지 확인합니다. 상담원 소프트웨어에서 상담 통화에 대한 보류/검색 또는 대체 작업을 허용하는지 확인합니다. 통화가 보류/검색될 때 해당 통화는 더 이상 상담으로 간주되지 않으며 Cisco CallManager에 의한 "임의" 호전환으로 간주됩니다. Cisco CallManager의 임의 전송에 문제가 있습니다. 상담 통화에 있을 때 사용자가 다시 연결하거나 호전환을 완료할 수 있도록 제한합니다.

상담 상대방이 전화를 끊어도 통화 내용이 사라지지 않음

Cisco CallManager에서 현재 전화회의가 완료되지 않은 경우 전화회의에서 시작된 상담을 위한 연결 끊기 이벤트에 문제가 있습니다. 에이전트 폰에서 통화 표시를 지우려면 두 번째 통화 연결을 끊습니다.

VRU로의 변환 경로가 작동하지 않음

먼저 활성 스크립트를 모니터링합니다. 그런 다음 라우팅 클라이언트와 VRU의 라우터, OPC 및 PIM 로그를 확인합니다. 대부분의 오류는 무조건 추적되지만, 추적 결과를 돌려서 어떤 일이 일어나는지 더 잘 파악할 수 있습니다.

다음은 변환 경로 시퀀스입니다.

• 라우팅 클라이언트가 라우터에 새 통화 요청을 합니다.

• 라우터는 통화를 IVR로 전달해야 하는 레이블을 사용하여 라우팅 클라이언트에 대한 연결을 반환합니다.

• 그런 다음 IVR은 VRU PG가 주변 장치 대상을 조회하는 데 사용하는 RequestInstruction을 전송해야 합니다.

• 라우터는 요청 명령의 주변 장치 대상을 대기하는 변환 경로 주변 장치 대상과 일치시킵니다.

• 라우팅 스크립트는 고객이 설계한 대로 실행 스크립트 또는 대기열 노드를 계속 사용합니다.

장애 경로를 찾기 위해 활성 스크립트를 모니터링합니다. 라우터 추적에서 오류를 확인합니다. 경로 클라이언트가 초기 레이블을 수신하는지 여부를 확인합니다. VRU가 통화를 수신하는지 확인합니다. VRU가 VRU PIM 또는 OPC 레벨에서 요청 명령을 전송하는지 확인합니다.

경로 요청이 경로 스크립트의 "VRU 노드로 변환 경로"에 도달하지 않음

스크립트를 모니터링하고 요청이 VRU 노드로의 변환 라우트에 도달하는지 확인합니다.

먼저 경로 스크립트에서 변환 경로가 선택된 선택 또는 경로 선택 노드는 경로를 서비스 제어 VRU로 변환하기에 충분하지 않습니다. VRU 노드로의 변환 경로가 필요합니다.

둘째, 통화가 변환 경로 노드로 전송됨을 모니터에 표시해야 합니다. 여기서 오류가 발생하면 변환 경로를 확인할 수 없거나 IVR에서 RequestInstruction 경로 요청 메시지를 받지 못한 것입니다.

라우터 로그의 변환 경로 시간 초과

변환 경로 시간 초과 오류는 라우터가 요청 명령을 수신하지 않음을 나타냅니다. OPC 및 VRU PIM에서 오류가 있는지 확인하고 RequestInstruction이 도착하는지 확인합니다.

라우터의 어떤 상황을 더 잘 나타내기 위해 라우터의 rtrtrace 툴을 사용하여 "변환 라우팅"과 "네트워크 VRU 추적"을 설정하십시오. VRU PG OPC에서 opctest로 서비스 제어 보고를 활성화합니다.

VRU PIM 로그는 트렁크 그룹 X에서 DNIS를 찾을 수 없음을 나타냄

요청 명령은 VRU PG에 대해 구성된 트렁크 그룹 중 하나의 트렁크 그룹 주변 장치 번호에 매핑되는 유효한 트렁크 그룹을 나타내야 합니다. 수정된 경우 VRU PG를 순환하여 트렁크 그룹 주변 장치 번호의 업데이트를 수신합니다.

ICM 구성 확인

IVR PG 라우팅 클라이언트에서 DN Label Mapping(DN 레이블 매핑)이 꺼져 있는지 확인합니다. IVR PG에는 네트워크 VRU 할당이 필요합니다. 네트워크 VRU는 유형 2여야 합니다. IVR PG에는 네트워크 트렁크 그룹과 트렁크 그룹이 할당되어야 합니다. 트렁크 그룹에서 네트워크 트렁크 그룹을 참조합니다.

NIC/포스트 라우팅 PG에는 주변 장치 대상의 각 DNIS에 대한 레이블이 있어야 합니다. (변환 경로 마법사에서 라우팅 클라이언트 요청에 대한 DNIS와 레이블을 동일하게 만듭니다. 접두사에서 이를 설정할 수 있습니다. prefix = DNIS 옵션을 선택합니다.)

VRU 라우팅 클라이언트에는 에이전트가 사용 가능해질 때 라우팅하는 디바이스 대상에 대해 구성된 레이블이 필요합니다.

Cisco IP IVR - ICM 인터페이스 트러블슈팅

이 Cisco IP IVR 섹션에서는 IP IVR과 ICM 간의 컨피그레이션 오류를 해결하는 방법을 다룹니다. 여기에는 IVR PG 사후 라우팅 및 변환 라우팅 설정에 대한 일반적인 문제가 포함됩니다. 일반적인 IVR 오류에 대한 자세한 내용은 Cisco IP IVR 문제 해결 가이드를 참조하십시오.

일반적으로 appadmin > Engine > Trace files 웹 페이지에서 MIVR 로그를 확인합니다.

• Cisco CallManager, IVR 및 ICM에 구성된 IVR CTI 포트 및 CTI 경로 포인트

• IVR CTI 포트 및 CTI 경로 포인트는 Cisco CallManager 글로벌 디렉토리의 IVR 사용자와 연결됩니다.

• Service Control(서비스 제어) 확인란은 IVR ICM 컨피그레이션에서 선택됩니다.

• IVR 스크립트 정의의 스크립트 이름은 ICM의 네트워크 VRU 스크립트 이름과 일치합니다.

• VRU PG의 트렁크 그룹 번호는 IP IVR의 CTI 포트 그룹 번호와 일치합니다.

변환 경로 실패

트러블슈팅에 사용하는 다른 모든 작업과 함께 IP IVR 트러블슈팅을 위해 이러한 작업을 시도할 수도 있습니다.

• MIVR 로그를 확인합니다. 이 로그는 일반적으로 문제 영역을 가리킬 수 있습니다.

• 디버그 설정을 사용하여 Cisco IP IVR을 켭니다(SS_TEL 및 LIB_ICM).

• IP IVR에서 jtprefs를 사용하여 IP IVR에 대한 Cisco Jtapi 로그를 켭니다. 디버그 도구를 참조하십시오. 추적을 켠 후 IP IVR 엔진을 중지하고 시작합니다.

• IP IVR JTAPI 변환 경로 포트 그룹의 CTI 포트 그룹 번호가 ICM의 트렁크 그룹 컨피그레이션에 있는 주변 장치 번호와 일치하는지 확인합니다.

스크립트가 재생되지 않거나 오류 메시지가 재생됩니다.

engine-trace 파일 아래의 IP IVR 로그를 확인하여 다음을 확인합니다.

• 스크립트 실행이 수신되었습니다.

• IP IVR에서 스크립트를 찾을 수 있습니다. 저장소 관리 도구를 사용하여 스크립트를 업로드합니다.

• IP IVR에서 프롬프트를 찾을 수 있습니다. 사용자 정의 프롬프트는 IP IVR의 \wfavvid\prompts\ user\en_us\에 상주합니다.

JTAPI 상태가 부분 서비스를 표시합니다.

이는 일반적으로 IP IVR에 구성된 일부 CTI 포트 또는 CTI 경로 포인트가 Cisco CallManager의 IP IVR 사용자와 구성 및/또는 연결되지 않았음을 의미합니다.

이는 스크립트 이름이 올바르게 지정되지 않았거나 저장소 관리자에 업로드되지 않았음을 의미할 수도 있습니다.

IP IVR의 ICM 상태가 부분 상태를 표시합니다.

일반적으로 이 조건은 한 쪽 또는 다른 쪽의 일부 컨피그레이션 또는 일치하지 않는 컨피그레이션을 나타냅니다.

라우터에서 통화가 대기열에서 제거되었을 때 들리는 스터터 프롬프트

이것은 ICR 구성의 네트워크 VRU 스크립트 컨피그레이션에서 너무 적은 시간 초과를 허용하는 잘못 구성된 라우팅 스크립트입니다.

ICM용 IP IVR 인터페이스에서 사용할 수 있는 일부 스크립트는 매우 오래 실행되지만, ICM 네트워크 스크립트 컨피그레이션의 기본 시간 제한은 3분입니다. 스크립트가 시간 초과되고 스크립트 실행 실패 경로가 다른 실행 스크립트를 재생하는 경우 이러한 실행 스크립트는 기본적으로 IVR에서 대기됩니다. 스크립트의 대기열에서 제거되면 여러 스크립트가 서로 재생되는 소리가 들립니다.

IVR 서비스 통계 문제 해결

IVR 통계는 IPCC 서비스 수준 보고서에 중요합니다. 따라서 문제 해결 방법에 대한 일부 정보가 여기에 포함되어 있습니다. 개요에서는 VRU에 구현된 통화가 연결된 상태가 아니라 대기열에 있는 것으로 계산되는 라우터 및 VRU PG의 변경 내용을 살펴봅니다. 통화가 라우팅되면 응답된 것으로 보고됩니다. 대기열에 있는 고객이 통화 연결을 끊으면 취소된 것으로 보고됩니다. 자세한 내용은 핫픽스 53 및 54의 readme.txt를 참조하십시오. 라우터는 라우터에서 통화가 어떤 상태에 있는지 나타내는 특수 대기열 이벤트를 전송합니다.

VRU PIM에는 특수 레지스트리가 설정되어 있으므로 중단을 최소화하려면 이 기능을 자발적으로 켜야 합니다.

Enterprise Service Real Time Report 10에서는 하나 이상의 기업 주변 장치 보고서에 VRU 서비스 및 Cisco CallManager PG 서비스를 추가할 때 이 데이터를 특별히 사용합니다. Enterprise Service Real Time Report(엔터프라이즈 서비스 실시간 보고서)에서는 보고를 위해 VRU PG 및 Cisco CallManager PG 서비스를 엔터프라이즈 서비스로 그룹화해야 합니다.

기타 유용한 대기열 보고서는 실시간 및 기록 레코드에 대한 새 통화 유형 보고서이며, 이제 직무 그룹 실시간 그리드에 직무 그룹에 대해 대기된 통화가 표시됩니다.

서비스 통계 또는 종료 통화 세부 정보 레코드가 생성되지 않음

VRU PIM은 CSTA 이벤트를 생성하지 않습니다. VRU PG 설정에서 서비스 제어 보고를 켭니다. ServiceControlQueueReporting의 레지스트리 키에 있는 값은 다음과 같습니다.

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

참고: 이 레지스트리 키는 공간 제한으로 인해 여기에서 두 줄에 걸쳐 나타납니다.

VRU는 모든 통화를 연결됨으로 보고하며, 필요에 따라 대기열에 추가되지 않음

ServiceControlQueueReporting 레지스트리 키가 페이스가 없거나 1로 설정되지 않았습니다.

VRU PIM의 시작 로그가 존재하지 않는 경우 이를 항의해야 합니다.

ServiceControlQueueReporting 키를 추가하고 값을 1로 설정합니다.

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

참고: 이 키는 공간 제한으로 인해 여기에서 두 줄에 걸쳐 나타납니다.

잘못된 서비스에 대해 통화가 계산되거나 서비스 보고서에 표시되지 않음

OPC 로그는 서비스 매핑을 찾을 수 없음을 나타냅니다.

OPC 로그는 잘못된 서비스에 대해 통화가 계산되거나 서비스 보고서에 나타나지 않을 때 서비스 매핑을 찾을 수 없음을 나타냅니다.

Cisco ICM 보고 문제

Cisco ICM은 데이터 통화 유형, 서비스 및 직무 그룹 테이블의 용이한 상관관계를 위해 설계되지 않았습니다. 숫자는 일반적으로 각 그룹에서 약간 다른 의미를 가집니다. 통화에는 하나의 서비스만 있지만 둘 이상의 상담원이 관련되어 있는 경우 두 개의 직무 그룹이 있을 수 있습니다. RONA(Redirect on No Answer) 기능은 다른 종료 레코드를 생성하지 않고 다른 사후 경로를 생성할 가능성이 있습니다.

상담원 직무 그룹, 직무 그룹, 서비스, 통화 유형 번호의 균형이 맞지 않습니다.

• 증상: 처리된 통화 또는 기타 통계 필드가 서비스, 통화 유형 및/또는 직무 그룹 보고서 간에 일치하지 않습니다.

• 조건: 통화 유형, 서비스 및 직무 그룹은 서로에 대한 논리적 맵으로 설정되지만 여전히 보고서가 정확하게 일치하지 않습니다.

• 문제 해결: 통화 볼륨이 초당 통화 1개 미만인 경우 OPC, PIM 및 JTAPI GW에서 CSTA, PIM, AGENT 및 서드파티 이벤트에 적합한 추적 설정을 켭니다. 지침은 이 문서의 툴 섹션을 참조하십시오.

• 통화 흐름을 문서화합니다.

  • Cisco CallManager PG 또는 VRU PG의 초기 게시 경로입니까?

  • FONA(Forward on No Answer)가 구성되어 있습니까? 그리고 FONA가 리디렉션하도록 구성되어 있습니까?

  • 라우팅된 통화를 라우팅되지 않은 통화와 아웃바운드 통화에서 분리하기 위해 주변 장치 번호가 0인 기본 직무 그룹이 구성되어 있습니까?

"select *" 문을 사용하여 하루 동안 다음 표의 기록 데이터를 가져옵니다.

• 주변 장치_30분

• 통화 유형 30분

• 서비스 30분

• 직무 그룹 30분

• 종료_통화_세부 정보

• Route_Call_Detail

Cisco CallManager 문제 해결

Cisco CallManager에서 추적을 수집할 때 Cisco CallManager Admin(Cisco CallManager 관리) 페이지의 Services(서비스) > Trace Flags(추적 플래그) 아래에서 플래그를 변경할 수 있습니다. 0xCB05는 CTI 오류의 SDL 추적을 위해 설정된 올바른 추적 플래그입니다. 디버그를 위해 서비스 매개 변수 아래에 0xCB05를 설정합니다. AVVID TAC 케이스 참조: 자세한 내용은 문제 해결 정보를 수집하는 중입니다. 문제 해결 가이드를 포함하여 Cisco CallManager 온라인 설명서를 참조하십시오.

Cisco CallManager 추적 켜기

Cisco CallManager에 대한 추적을 설정하는 방법에 대한 자세한 내용은 Cisco Technical Support에 대한 Cisco CallManager 추적 설정을 참조하십시오.

Cisco CallManager IP 주소 변경

Cisco CallManager IP 주소 변경을 참조하고 서버 이름을 변경합니다.

1. Cisco CallManager PG에서 설치 프로그램을 실행하고 Cisco CallManager PIM에 대한 JTAPI 서비스를 변경합니다. 내선 이동 및/또는 전화 서비스가 있는 경우

2. CRA 엔진을 중지합니다.

3. CRA에서 - Engine Configuration(엔진 컨피그레이션) 아래의 IP 주소를 변경합니다.

4. JTAPI에서 IP를 변경합니다.

5. 서버에서 DC 디렉터리 서비스를 중지합니다.

6. 디렉토리 컨피그레이션에서 IP 주소 변경

7. Cisco CallManager의 System > Server 아래에서 IP 주소를 변경합니다.

8. System > Enterprise Parameters 아래의 URL에서 IP 주소를 변경합니다.

9. Features(기능) > Phone Services(전화 서비스) 아래의 모든 URL에서 IP Address(IP 주소)를 변경합니다.

10. 서버 IP 주소 - 네트워크 속성 변경.

11. DHCP 옵션 150을 새 IP 주소로 변경합니다.

12. DC Directory(DC 디렉토리), Cisco CallManager > System Profile(시스템 프로파일) > Hoteling(호텔링)에서 호텔 프로파일의 IP를 변경합니다.

13. SQL Enterprise Manager를 엽니다.

14. 플러그인 테이블의 URL에서 IP 주소를 변경합니다.

컨피그레이션 변경 사항을 백업하려면

1. stiBackup 구성을 엽니다.

2. 해당되는 모든 탭에서 서버 IP 주소를 변경합니다.

디버그 도구

프로크몬

Procmon은 PIM 및 JTAPI GW 프로세스를 디버깅하는 데 사용할 수 있는 명령줄 도구입니다.

• 사용법: procmon <customer name> <node> 프로세스

  • Procmon ipcc pg1a pim1

  • Procmon ipcc pg1a jgw1

  • Procmon ipcc1a ctisvr

각 프로세스에 대한 몇 가지 유용한 추적 설정은 다음과 같습니다.

• JTAPI GW(procmon 사용)

  • trace JT_TPREQUESTS(서드파티 요청 추적 켜기)

  • trace JT_JTAPI_EVENT_USED(PG에서 사용하는 JTAPI 이벤트에 대한 추적을 켜짐)

  • trace JT_PIM_EVENT(PIM으로 전송되는 이벤트 메시지에 대한 추적을 켭니다.)

  • trace JT_ROUTE_MESSAGE(라우팅 클라이언트 추적 켜기)

  • trace JT_LOW*(기본 JTAPI 및 CTI 레이어를 기반으로 추적)

• PIM(procmon 사용)

  • trace tp*(서드파티 요청 추적 켜기)

  • trace precall(precall 이벤트 추적 실행)

  • trace *event(상담원 및 통화 이벤트 추적 설정)

  • trace csta*(CSTA 통화 이벤트 추적 켜기)

• CTI 서버(procmon 사용)

  • regset EMSTraceMask 0xf8(래핑할 수 있는 유용한 CTI 서버 추적을 켭니다.)

OPC테스트

Opctest는 PG에서 OPC 프로세스를 디버깅하는 명령줄 도구입니다.

• 사용법: opctest /cust <고객 이름> /node <노드>

  • opctest /cust ipcc /node pg1a

• 유용한 설정

  • debug /agent(에이전트 이벤트 추적 켜기)

  • debug /routing(라우팅 이벤트 추적 사용)

  • debug /cstacer(csta 이벤트 추적 활성화)

  • debug /tpmsg(서드파티 통화 요청 추적 설정)

rttest

Rttest는 ICM에서 라우터 프로세스를 디버깅하는 명령줄 인터페이스 도구입니다. GUI 버전에 대한 rtrtrace를 참조하십시오.

• 사용법: rttest /cust ipcc

rtsetting.exe

라우터 레지스트리 설정을 변경하는 GUI 도구입니다.

• 설정을 기본값으로 다시 설정할 수 있는 옵션이 있습니다.

rtrtrace.exe

ICM에서 다양한 라우터 추적을 켜는 GUI 도구입니다.

• IPCC에 특히 유용한 설정은 다음과 같습니다.

  • Queuing - 대기열에서 빼는 동안 문제가 발생했습니다.

  • 서비스 제어 - VRU 인터페이스 문제

  • 변환 라우팅 - 변환 라우트에 문제가 있는 경우

덤플라그

Cisco ICM 이진 파일을 텍스트 파일로 덤프합니다. 디렉토리를 process logfiles 디렉토리로 변경합니다.

• OPC, PIM 및 JtapiGW 프로세스 로그 파일은 icr\<customer_name>\<node>\logfiles\에 있습니다.

• PG에는 cdlog라는 배치 파일이 있습니다. 여기서 >cdlog <cust> <node>를 입력합니다.

• 사용법: dumplog 프로세스 이름

  • Dumplog /"(다른 dumplog 옵션에 대한 도움말)

  • 덤플록 jgw1

  • Dumplog pim1

  • 덤플로그 opc

브루트레이스

VRU PG 캡처 파일을 보는 도구입니다. 덤플로그와 비슷한 작품.

콜 트레이서

라우팅 스크립트를 디버깅하는 데 사용할 수 있는 Cisco ICM 툴입니다.  이 도구는 AW의 AW 메뉴 항목에서 찾을 수 있습니다.

jtprefs

IP IVR에서 JTAPI 클라이언트에 대한 JTAPI 추적을 설정하는 도구입니다. IPCC PG의 JTAPI 추적은 procmon 인터페이스로 제어됩니다. 이 도구는 프로그램 파일\CiscoJtapiTools\에 있습니다.

성능 모니터

Cisco CallManager, Cisco IP IVR 및 ICM에 대한 실시간 데이터를 보여주는 Microsoft Windows 2000 관리 도구입니다. 진행 중인 통화, 등록된 디바이스 및 프로세스 CPU 사용률을 볼 수 있습니다. 이 도구는 시작 > 프로그램 > 관리 도구에서 찾을 수 있습니다.

로그 파일

Cisco ICM 로그 파일

Cisco ICM 로그 파일은 \icr\<cust>\<node>\logfiles에 있습니다. 여기서 고객은 고객 인스턴스 이름을 참조하고 노드는 라우터, cg1a 등에 대한 pg1a, ra를 참조합니다. 로그 파일을 보려면 dumplog를 사용합니다.

참고: vrutrace와 같은 추적 툴을 사용하여 이벤트 캡처 파일을 볼 수 있습니다. 이러한 파일은 다른 디렉토리에 있습니다.

Cisco CallManager 로그 파일

Cisco CallManager 로그 파일은 일반적으로 \program files\cisco\ccm\trace에 있으며 추적 디렉토리는 다음과 같습니다.

• Ccm - CallManager SDI 로그

• Dbl - 데이터베이스 레이어 로그

• Sdl - 통화 신호 로그

• Tftp - tftp 서버에 대한 로그

추적 설정 아래의 Cisco CallManager 관리 페이지에서 이러한 파일에 대한 추적 설정을 수정할 수 있습니다. Cisco CallManager의 서비스 매개변수에서 SDL 추적 설정을 수정할 수 있습니다.

IP IVR 로그 파일

IP IVR 로그 파일은 \program files\wfavid에 있습니다. appadmin 페이지의 engine-trace files 아래에서 IPIVR 로그 파일을 볼 수도 있습니다.

jtprefs.exe를 사용하여 JTAPI 이벤트를 켜고 IP IVR 엔진을 다시 시작할 때 Cisco JTAPI 클라이언트 로그를 볼 수 있습니다.

유용한 프로필 데이터

케이스 열기를 위해 데이터를 수집하는 경우 로그 파일 외에도 이 섹션에 나열된 데이터를 수집합니다.

상담원 수

구성된 상담원 수는 몇 명입니까?

사용된 게이트웨이

구성된 게이트웨이는 몇 개입니까?

구성 요소의 소프트웨어 버전

Cisco CallManager, JTAPI Client, ICM, Gateway IOS 버전 및 IP IVR.

• Cisco CallManager 관리 웹 페이지의 도움말 > 정보 > 세부사항 아래에서 Cisco CallManager 버전을 찾을 수 있습니다.

• JTAPI 클라이언트 버전을 찾으려면 Cisco CallManager PG의 \winnt\java\lib 디렉터리에 있는 명령 프롬프트에 jview CiscoJtapiVersion을 입력하면 됩니다.

• IP IVR 버전도 찾을 수 있습니다.

IVR 유형

어떤 유형의 IVR을 사용 중입니까?

플랫폼

사용 중인 플랫폼 유형/CPU/및 물리적 메모리의 양.

관련 정보

• 원격 프로세스 모니터 콘솔 사용(Procmon)
• Dumplog 유틸리티 사용 방법
• OPCTest 명령줄 유틸리티 사용
• Cisco ICM 테스트 유틸리티
• 추적 설정
• Drwtsn32 로그 파일 읽기
• AVVID TAC 사례: 문제 해결 정보 수집
• Cisco CallManager IP 주소 변경
• 기술 지원 및 문서 − Cisco Systems