이 문서에서는 PG(Peripheral Gateway) 및 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 서버는 많은 오류를 지정되지 않은 오류로 기록합니다.
PIM 로그가 있는지 확인합니다.PIM 로그가 없는 경우 Cisco ICM 설정에서 주변 장치가 활성화되었는지 확인합니다.주변 장치가 추가되지만 주변 장치를 활성화해야 하는 경우도 있습니다.
Edit(편집) > Peripheral(주변 장치)을 선택하고 Enabled(활성화됨) 확인란을 선택합니다.
PIM 프로세스가 다시 시작되면 dumplog 유틸리티를 사용하여 Cisco CallManager PG의 PIM 로그를 봅니다.로그 파일에 OPCHearchBeatTimeout에 오류가 있는 경우 이 레지스트리 설정을 수정해야 합니다.regedt32를 사용하여 변경합니다.
eagtpim 동적 데이터를 10으로 기록하는 레지스트리에서 OPCHearchBeatTimeout을 수정합니다. 경로는 다음과 같습니다.
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\EAGENTData\Dynamic
참고: 공간 제한으로 인해 이 키가 두 행 위에 나타납니다.
PIM 프로세스가 유휴 상태인 경우 다음 검사를 실행합니다.
PIM 로그를 확인합니다."Attempt to Activate(활성화 시도)"가 1분에 한 번 이상 표시되어야 합니다.
PIM이 활성화되지 않은 경우 dumplog 유틸리티를 사용하여 OPC 로그를 확인합니다.opctest를 실행하여 OPC 프로세스가 라우터에서 컨피그레이션을 수신하는지 확인합니다.
OPC 프로세스가 라우터에서 컨피그레이션을 받지 못한 경우 dumplog 유틸리티를 사용하여 pgagent 로그를 봅니다.pgagent 프로세스에는 중앙 컨트롤러에 대한 활성 경로가 있어야 합니다.pgagent에 활성 경로가 없으면 PG 설정에서 네트워크 연결과 DMP 컨피그레이션을 확인하십시오.라우터에서 dumplog 유틸리티를 사용하여 ccagent 로그를 봅니다.PG 디바이스(DMP 시스템 ID)가 라우터에서 디바이스로 활성화되었는지 확인합니다.
설정을 통해 또는 DMP 레지스트리 아래의 레지스트리에서 라우터 컨피그레이션에서 PG를 활성화합니다.
명령 창에서 tracert 명령을 사용하여 라우터와 PG 간의 네트워크 연결을 확인합니다.
참고: DNS와 DHCP 간에 불일치가 있을 수 있습니다.
라우터의 IP 주소가 c:\winnt\system32\drivers\etc 디렉토리의 호스트 파일에 있는지 확인합니다.
PG > 설정에 구성된 논리적 컨트롤러 ID가 구성 > ICM에서 PG 논리적 인터페이스 컨트롤러의 ID와 일치하는지 확인합니다. PG > 설정의 주변 장치에 대해 구성된 주변 장치 ID가 구성 > ICM에서 주변 장치의 ID와 일치하는지 확인합니다.
컨피그레이션과 일치하도록 ICM 설정을 수정합니다.
명령 프롬프트로 이동하여 jview를 입력하고 Enter 키를 누릅니다. 설치된 Java 버전에 대한 정보가 나타납니다.
Microsoft (R) Command-line Loader for Java version 5.00.3190
이 출력이 표시되지 않거나 버전이 3190 이전인 경우 올바른 버전의 Microsoft JVM을 설치해야 합니다.msjavx86.exe를 실행합니다.이 파일은 설치 중 icr\bin 디렉터리에 설치됩니다.
명령 프롬프트에서 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 key폴더 아래의 Classpath 값을 확인합니다. 다음과 같은 키를 설정합니다.
C:\WINNT\java\classes;.;c:\icr\bin\icrjavalib.zip
참고: 드라이브 문자와 Windows 시스템 디렉토리는 다를 수 있으며 클래스 및 c:\icr 이전 문자는 다음과 같습니다.세미콜론, 마침표 및 세미콜론입니다.
명령 프롬프트에서 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.애플리케이션 탭 아래에서 파일을 찾을 수 있습니다.
Cisco CallManager PG에 핫픽스가 50개 미만인 JTAPI 4.1 SP(서비스 팩) 4만 설치한 경우 업그레이드해야 합니다.
ICM PG > Setup을 실행하여 PG를 업그레이드한 경우 \icr\bin\icrjavalib.zip 파일의 날짜/시간이 업데이트된 날짜를 표시하는지 확인합니다.날짜는 약 1일 내에 bldXXXXX.version 파일의 날짜/시간과 거의 같아야 합니다.
참고: 설치 프로그램을 실행할 때 파일이 사용 중인 경우 이 파일을 업데이트할 수 없습니다.브라우저가 zip을 여는 경우 브라우저에서 zip 파일을 클래스 경로의 디렉터리로 간주하기 때문에 인터넷 브라우저가 열려 있는 경우 이러한 상황이 발생할 수 있습니다.이 문제를 방지하려면 설치를 실행하기 전에 모든 브라우저 세션을 닫으십시오. Setup에서 파일을 업데이트할 수 없는 경우 파일을 업데이트하기 위해 PC를 재부팅하라는 메시지가 나타납니다.재부팅해야 합니다.
PIM은 JTAPI 게이트웨이(JTAPIGW)와 통신하며 JTAPIGW는 Cisco CallManager와 통신합니다.PIM이 활성화하려고 하면 PIM은 JTAPI를 통해 JTAPIGW에 Cisco CallManager와의 통신을 초기화하도록 지시합니다.
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 > ICM에서 이름과 암호가 올바른지 확인하십시오 설치. 디렉터리에서 유효한 에이전트 장치 및 경로 지점만 제어할 수 있는 권한을 갖도록 사용자를 구성합니다.
JTAPI GW 프로세스에서 Cisco CallManager 주소를 확인할 수 없습니다.Cisco CallManager 호스트 이름 또는 IP 주소를 사용하여 Setup의 PIM 대화 상자에서 서비스 매개변수를 구성합니다.Cisco CallManager에 대한 호스트 이름 컨피그레이션이 올바른 경우 Cisco CallManager를 ping할 수 있는지 확인합니다.그렇지 않은 경우 호스트 이름 대신 Cisco CallManager의 IP 주소를 사용합니다.
JTAPI GW는 사용자 이름과 비밀번호를 사용하여 전역 디렉토리에 로그인합니다.Setup(설정)의 PIM 대화 상자의 사용자 이름 및 비밀번호는 Cisco CallManager 관리 웹 페이지의 ccmadmin(ccmadmin) > User(사용자) > Global Directory(전역 디렉토리)에서 전역 디렉토리에 구성된 사용자의 사용자 이름 및 비밀번호와 일치해야 합니다.
사용자가 없는 경우 새 사용자를 추가합니다.페이지 하단에서 CTI Enabled(CTI 활성화) 확인란을 선택해야 합니다.
Cisco CallManager 전역 디렉토리 사용자 페이지의 확인란은 PIM 또는 IP IVR 사용자에 대한 CTI 권한을 활성화 또는 비활성화할 수 있습니다.PIM/JTAPI GW가 액티브 상태가 되려면 이 확인란을 선택하고 업데이트해야 합니다.이 확인란을 선택하면 두 CTI 디바이스가 Cisco CallManager에 연결할 수 없으며, 이로 인해 문제가 발생할 수 있습니다(기본 제한은 400임).
Cisco CallManager 버전 3에서 이 서비스는 서비스 제어에서 "Cisco CallManager"로 표시됩니다. 서비스를 시작합니다.
Cisco CallManager 서비스가 비정상적으로 종료되면 일반적으로 다시 시작되도록 설정되지만, 장애 조치 시나리오에서 디바이스 마이그레이션과 관련된 문제가 발생할 수 있는 경우 이를 "해제"로 구성할 수 있습니다.
이벤트 로그를 확인하여 Cisco CallManager 서비스가 다시 시작되는지 확인합니다.시스템이 적절한 CPU 사용에 문제가 있는 경우 시스템이 다시 시작되는 경우도 있습니다.시스템은 "느린 SDL 타이머 스레드"를 나타내는 오류 또는 경고를 이벤트 로그에 보고합니다. 이러한 유형의 오류로 인해 Cisco CallManager가 다시 시작됩니다.이 버전의 Cisco CallManager는 정상 우선 순위로 실행되므로 시스템에서 실행되는 다른 애플리케이션이 통화 신호를 방해할 수 있습니다.
물리적 메모리가 부족하거나 시스템에서 다른 시간 문제가 발생할 경우 Cisco CallManager에서 10분 제한 후 다시 시작한 후 초기화할 수 없음을 나타내는 오류가 나타날 수 있습니다.Cisco DBL(CallManager 데이터베이스 계층)에 대한 DCOM 구성 요소 서비스를 초기화하는 데 문제가 있습니다.이 문제를 해결하려면 구성 요소 서비스 - DCOM 구성 요소를 통해 이 DBL DCOM 서비스를 중지하고 시작합니다.
참고: 이는 Cisco CallManager와 같은 시스템 서비스와 다릅니다.
Cisco TAC(Technical Assistance Center)에서 케이스를 엽니다. 기본 타이밍 문제를 해결하지 않으면 다음에 시스템을 다시 시작할 때 문제가 될 수 있습니다.
디렉터리 서비스가 실행 중이고 제대로 실행되는지 확인합니다. 기본적으로 이 서버는 Cisco CallManager 시스템의 서비스 제어에 있는 DC 디렉토리 서버입니다.기계를 시작해 보세요.오류가 발생할 수 있습니다.
시스템이 메모리 또는 디스크 공간이 부족하면 디렉터리 서비스가 일시 중지 상태로 전환될 수 있습니다.Microsoft Windows 2000 이벤트 로그에 오류가 나타납니다.필요한 경우 리소스 문제를 해결하고 디렉터리 서비스를 다시 시작합니다.
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(속성) 필드에서 서비스에 대해 올바른지 확인합니다.
시스템 시작 메뉴에서 DC 디렉토리 관리를 시작합니다.비밀번호 "ciscocisco"(기본값) 또는 관리자가 구성한 비밀번호로 사용자 디렉토리 관리자로 로그인합니다.사용자가 구성되지 않았음을 나타내는 오류가 표시되면 DCDSrvr\bin 디렉토리에서 Cisco AVVID 컨피그레이션 파일 중 하나를 실행합니다.기본 Cisco CallManager인 Publisher인 경우 DOS 프롬프트에서 avvid_cfg.cmd를 실행합니다.보조 Cisco CallManager인 경우 명령 프롬프트에서 avvid_scfg.cmd를 실행합니다.
이미 구성되었음을 나타내는 오류가 표시되면 사용자가 존재합니다.오류가 없는 경우 지금 제대로 작동하기 시작해야 합니다.돌아가 ccmadmin의 Global Directory User 페이지에서 액세스를 확인합니다.
참고: DC 디렉토리는 시스템 리소스가 부족한 경우 일시 중지 모드로 전환됩니다.
이 예에서는 디바이스 대상에 대해 샘플 ICM 컨피그레이션을 사용합니다.
장치 대상 샘플 | |
기업 이름 | 상담원9782755100 |
전역 주소 | 상담원9782755100 |
구성 요소 | /devtype CiscoPhone /dn 9782755100 |
다음 예에서는 에이전트에 대해 샘플 ICM 컨피그레이션을 사용합니다.
에이전트 샘플 | |
주변 장치 | CCMPG_PIM1 |
주변 장치 번호 | 1234 |
비밀번호 | XXX |
PG에 대해 ICM > 설정을 실행할 때 에이전트 확장 길이인 "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
opctest "status" 명령을 사용하고 PIM_ACTIVE 및 CTI_ACTIVE 상태의 IPCC PIM 및 CTI Server 표시를 확인합니다.PIM 및 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 서버는 제목 표시줄에 이 포트를 표시하고 CTI 서버가 시작될 때 이 값을 기록합니다.클라이언트가 CTI 서버를 ping할 수 있는지 확인합니다.
PG/CTI 서버의 \icr\bin 디렉토리에 있는 setup.exe를 실행합니다.CTI 게이트웨이 구성 요소를 선택합니다.에이전트 로그인 필요 확인란이 선택 되어 있는지 확인합니다.이 확인란 선택은 IPCC 또는 타사 제어 응용 프로그램에 적용되지 않습니다.이 확인란의 목적은 다른 ACD 에이전트를 모니터링하는 것입니다.
pim에 procmon을 사용하고 "trace tp*"를 사용하여 서드파티 추적을 설정합니다(대/소문자 구분). 로그인 요청을 표시해야 합니다.매개변수가 올바른지 확인합니다.악기는 "Device="로 추적됩니다. 이 값은 디바이스 대상 configparam의 /dn 문자열과 일치해야 합니다.에이전트 ID는 "AgentID="로 추적됩니다. 이 값은 구성/ICM의 상담원 주변 장치 번호와 일치해야 합니다.
잘못된 암호
암호가 올바른지 확인합니다(암호가 일반 텍스트로 추적되지 않을 수 있음). 비밀번호가 잘못된 경우 로그에 INVALID_PASSWORD_SPECIFIED 오류가 표시되어야 합니다.
잘못된 개체
장치 대상의 구성 매개 변수에 잘못된 장치 유형이 포함되어 있음을 나타냅니다.이 오류는 다음과 같이 표시되며 키워드 사이에 공백이 있습니다.
/devtype CiscoPhone /dn 9782755100
유효하지 않음_DEVICE_TARGET
Device Target(디바이스 대상)에 잘못된 항목이 있음을 나타내며, 컨피그레이션 매개변수 필드에 있는 것일 수 있습니다.dumplog 유틸리티를 사용하여 PIM이 마지막으로 재시작된 시간의 PIM 로그를 확인합니다.로그는 디바이스 대상 컨피그레이션 문자열이 유효하지 않은 경우 디바이스 대상을 확인하고 오류를 기록합니다.
로그인 시도 시 발생하는 오류에 대해서는 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에 추가하십시오.
로그인하려면 구성/ICM에서 하나 이상의 직무 그룹(직무 그룹 멤버)의 구성원으로 에이전트를 구성해야 합니다.
상담원 주변 장치 번호가 나타내는 상담원이 다른 장치 대상에 아직 로그인되어 있지 않은지 확인합니다.이를 확인하는 한 가지 방법은 모니터 ICR을 실행하고 해당 상담원에 대해 상담원으로부터 사용 가능 보고서를 실행하는 것입니다.상담원이 로그인된 경우 상담원이 로그인된 장치 대상의 네트워크 대상 ID를 표시합니다.주변 장치에 대한 에이전트 데이터를 이 AW로 전송하도록 ICM을 구성한 경우에만 에이전트 데이터가 awdb에 나타납니다.
awdb의 Agent_Real_Time 테이블에 대해 isqlw에서 이에 대해 쿼리할 수도 있습니다.먼저 상담원에 대한 직무 대상을 찾습니다(예: PeripheralID = XXX 및 PeripheralNumber = YYY인 상담원에서 *를 선택합니다). 그런 다음 상담원이 로그인되었는지 확인합니다(예: SkillTargetID = XXX인 Agent_Real_Time에서 *를 선택합니다).
PIM에 연결하고 dagent <agent peripheral number>를 실행할 때도 이를 확인할 수 있습니다.
디바이스 대상(악기에서 지정한 대로)에 이미 다른 에이전트가 로그인되어 있지 않은지 확인합니다.
이를 확인하는 한 가지 방법은 awdb의 Agent_Real_Time 테이블에 대해 isqlw를 실행하는 것입니다.먼저 문제의 디바이스 대상에 대한 네트워크 대상 ID를 찾습니다.예를 들어 Device_Target에서 *를 선택합니다. 여기서 ConfigParam은 '%1003%'입니다.이제 디바이스 대상이 로그인되었는지 확인합니다.예를 들어 Agent_Real_Time에서 *를 선택합니다. 여기서 NetworkTargetID = XXX입니다.
또한 PIM에 연결하고 디바이스 대상을 덤프할 때 이를 확인할 수 있습니다.디바이스 대상을 덤프하는 방법에는 두 가지가 있습니다.ddt 명령은 네트워크 대상 ID를 입력으로 가져와 디바이스 대상을 덤프합니다.deadt 명령은 디바이스 대상 컨피그레이션에서 /dn 문자열을 입력으로 가져오고 디바이스 대상을 덤프합니다.예를 들어 디바이스 대상 /dn 문자열이 /dn 9782755100인 경우 디바이스 대상을 deadt 9782755100으로 덤프합니다.
Cisco CallManager 웹 페이지로 이동하여 사용자/전역 디렉터리를 선택하고 PG에서 사용하는 사용자 ID를 찾습니다. "연결된 장치"를 확인하고 사용자에게 장치를 제어할 권한이 있는지 확인하십시오.
사용자 페이지에서 디바이스를 찾을 수 없는 경우(선택 또는 선택 취소), 데이터베이스(Cisco CallManager가 디바이스를 저장하는 경우)와 디렉토리 서버(디바이스를 저장하고 사용자 프로필을 저장하는 디렉토리 서버) 간의 동기화에 문제가 있을 수 있습니다. 디렉터리 서버(DC Directory Server)가 실행되는지 확인합니다.
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에 등록되어 있으며 상담원이 제어하지 않고 전화기에서 전화를 걸고 받을 수 있는지 확인합니다.
상담원이 로그인되어 있고 사용 가능 상태가 아닌지 확인합니다. 상담원을 사용할 수 없는 경우 상담원이 전화를 걸 수 없습니다.전화를 걸려면 먼저 준비 안 됨을 클릭합니다.
특정 번호로 전화를 걸 때만 오류가 발생하면 실제 전화기에서 해당 번호를 확인하여 전화를 성공적으로 걸 수 있는지 확인합니다.ICM 전화 건 번호 계획을 구성한 경우 다이얼하는 번호가 전화 건 번호 계획의 와일드카드 중 하나와 일치하는지 확인합니다.그런 다음 상담원에 대한 상담원 데스크 설정에서 전화를 건 번호 계획 항목이 식별하는 번호 유형(예: 국제)으로 전화를 걸 수 있는지 확인합니다.
각 PIM에 대해 구성된 전화 건 번호 계획을 잘못 구성하거나 올바르게 구성하여 상담원이 특정 번호로 전화를 걸 수 없게 할 수 있습니다.PIM 로그의 오류는 사용 권한 오류를 나타내야 합니다.전화를 건 번호 계획을 사용하여 상담원과 상담원 간 통화를 만드는 경우 상담원 및 장치 번호가 겹칠 수 없습니다.
상담원이 전화를 걸거나 통화가 상담원에게 라우팅될 때 라우터는 상담원을 사용할 수 없게 합니다.이 메커니즘을 사용하면 PIM에서 통화가 도착했다고 보고하기 전에 라우터가 다른 통화를 에이전트로 라우팅할 수 있습니다.일부 네트워크는 실제로 통화를 라우팅하는 데 몇 초가 걸립니다.라우터는 에이전트 상태에 따라 타이머를 취소하지 않습니다.
라우팅 클라이언트에서 PIM으로 통화를 라우팅하는 데 걸린 실제 시간이 비교적 짧은 경우 라우터에서 구성 가능한 시간을 변경할 수 있습니다.DOS 명령 창의 라우터 중 하나에서 rtsetting.exe를 사용합니다.Extranation(추정치) > 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 통화로 간주되며 컨텍스트 변수, 서비스 또는 직무 그룹 정보가 통화에 할당되지 않습니다.
상담원이 통화 중이며 통화 불가능, 통화 중 또는 기타를 클릭하면 상담원 상태가 즉시 변경되지 않습니다.이것은 의도적인 것이다.상담원은 통화가 완료될 때까지 통화 또는 보류 상태로 유지됩니다.누른 단추에 따라 상담원은 준비 안 됨, 작업 준비됨 또는 작업 준비 안 됨으로 전환됩니다.통화가 종료된 후 상담원이 즉시 사용 가능으로 전환되면 상담원에 대한 상담원 데스크 설정을 확인하고 수신 후 사용 가능 또는 발신 후 사용 가능이 설정되어 있는지 확인해야 합니다.이러한 설정은 상담원이 통화 중에 단추를 사용하여 수행하는 작업을 재정의합니다.
ICM 구성에서 상담원에 대한 상담원 데스크 설정을 확인하고 Idle Reason Required(유휴 사유 필요)가 선택되어 있는지 확인합니다.확인란을 선택하면 이유 코드 없이 상담원이 준비 안 됨 상태로 들어갈 수 없습니다.Desktop_Settings.cfg를 Configure ICM의 에이전트 데스크 설정과 일치하도록 수정하거나 Configure ICM에서 에이전트 데스크 설정을 변경합니다.
상담원에게 할당된 상담원 데스크 설정이 없는 경우 상담원은 로그인하여 준비될 수 있지만 상담원은 준비 안 됨 또는 로그아웃할 수 없습니다.상담원 응용 프로그램을 닫고 상담원 데스크 설정을 할당한 후 다시 로그인하는 것이 해결 방법입니다.
상담원이 전화를 걸거나 통화가 상담원에게 라우팅될 때 라우터는 상담원을 사용할 수 없게 합니다.이 메커니즘을 사용하면 PIM이 통화를 수신됨으로 보고하기 전에 라우터가 다른 통화를 에이전트로 라우팅할 수 있습니다.일부 네트워크는 실제로 통화를 라우팅하는 데 몇 초가 걸립니다.라우터는 에이전트 상태에 따라 타이머를 취소하지 않습니다.
라우트 클라이언트에서 PIM으로 통화를 라우팅하는 데 걸린 실제 시간이 비교적 짧은 경우 라우터에서 구성 가능한 시간을 변경할 수 있습니다.DOS 명령 창의 라우터 중 하나에서 rtsetting.exe를 사용합니다.Extranation(추정치) > Agent(상담원)에서 확인합니다.기본값은 10초입니다.값이 너무 짧으면 라우터는 통화를 수신하려고 하는 에이전트로 통화를 라우팅합니다.이로 인해 PIM이 통화를 삭제합니다.
로그인 요청 및 준비 요청에 대한 데이터가 일치하지 않습니다.기기, 상담원 ID 또는 주변 장치 번호가 일치하지 않을 수 있습니다.CTI 서버 추적을 procmon으로 설정하고 regeset를 0xf8로 설정하여 적절한 추적을 확인합니다.서드파티(TP) 추적이 켜져 있는 경우 OPC 또는 PIM 로그에서 이를 볼 수도 있습니다.
상담원이 작업 준비됨, 작업 준비 안 됨 또는 사용 가능 상태인 경우 상담원이 로그아웃하기 전에 먼저 준비 안 됨으로 전환해야 합니다.ICM 구성의 에이전트 데스크 설정과 일치하도록 Desktop_Settings.cfg를 수정하거나 ICM 구성에서 에이전트 데스크 설정을 변경합니다.
상담원이 준비 안 됨 상태이고 아직 로그아웃할 수 없는 경우 ICM 구성에서 상담원에 대한 상담원 데스크 설정을 확인하고 로그아웃 사유 필요가 선택되어 있는지 확인합니다.
소프트폰에 더 이상 물리적으로 존재하지 않는 통화가 표시되면 상담원 상태가 통화 중 또는 보류에 머물러 상담원은 로그아웃할 수 없습니다.이는 JTAPI 또는 PIM의 소프트웨어 버그 때문일 수 있습니다.조건을 지우려면 먼저 릴리스 단추가 활성화된 경우 소프트폰에서 통화를 지워야 합니다.그래도 작동하지 않으면 상담원을 로그아웃하십시오.로그아웃 단추가 작동하지 않으면 소프트폰을 종료하고 다시 시작합니다.상태가 지속되면 소프트폰을 종료하고 작업 관리자를 실행하고 kill geodcs.exe 및 common~1.exe를 실행하고 소프트폰을 다시 시작합니다.이러한 프로세스는 계속 실행되어 잘못된 에이전트 상태를 기억할 수 있습니다.
PIM에서 상담원의 상태를 확인합니다.Agent Desktop을 다시 시작해도 조건이 해결되지 않으면 더 많은 조치를 취할 수 있습니다.CTI Server 및 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 로그에서 문제를 확인합니다.대부분의 경로 오류는 조건 없이 추적됩니다.
Configure ICM(ICM 구성)에는 "Use DN/Label Map(DN/레이블 맵 사용)"이라는 레이블이 지정된 각 라우팅 클라이언트에 대한 설정이 있습니다. 이 설정을 "예"로 설정하면 전화를 건 번호와 가능한 대상 레이블의 각 조합에 대해 "전화 건 번호 레이블" 항목을 구성해야 합니다.이 설정은 PG 라우팅 클라이언트에서 유용하지 않으며 "No"로 설정해야 합니다.
라우팅 클라이언트에 구성된 레이블을 확인합니다.각 클라이언트에서 레이블이 동일하더라도 각 클라이언트에서 Label을 구성해야 합니다.
사후 라우팅을 사용하려면 Cisco CallManager에서 "CTI Route Point"를 구성하고 원하는 디렉토리 번호(예: "5000")를 가진 경로를 경로 포인트에 할당해야 합니다. 상담원 통화가 라우팅을 게시하려면 전화 건 번호 계획을 사용합니다.Cisco CallManager CTI Route Point에 다이얼하는 에이전트는 CTI 데스크톱 버전 4.1.9에서 IPCC 소프트폰을 구성합니다.
전역 디렉터리 아래의 Cisco CallManager 사용자 웹 페이지에서 PG 사용자의 "연결된 장치" 목록에 CTI 경로 포인트 장치를 추가해야 합니다.새 디바이스를 생성하는 경우 먼저 회선을 추가한 다음 사용자 "Associated Devices" 목록에 디바이스를 추가합니다.사용자 디바이스 목록에 이미 있는 디바이스에 라인을 추가하는 경우 JGW가 새 라인을 인식하도록 JGW를 다시 시작해야 합니다.그러나 새 디바이스를 추가하고 디바이스에 라인을 추가한 다음 사용자 디바이스 목록에 디바이스를 추가하는 경우 JGW는 새 디바이스를 인식할 수 있어야 합니다(약 30초).
전화 건 번호를 확인하여 주변 장치 라우팅 클라이언트에 대해 번호가 구성되어 있는지 확인합니다.JGW로 procmon을 실행하고 추적을 "trace *ROUTE*"로 설정합니다(대/소문자 구분). JGW 로그에서 전화 건 번호와 관련된 오류를 확인합니다.시작 시 JGW는 전화를 건 번호에 대해 경로 통화를 다시 등록하려고 시도합니다.전화를 건 번호로 전화를 걸면 게이트웨이가 "RouteEvent"를 수신합니다.
전화 건 번호와 함께 통화 유형이 생성되어 스크립트에 올바르게 매핑되었는지 확인합니다.
ICM 전화 건 번호를 구성한 경우 CTI 경로 포인트를 설정하고 사용자 디바이스 목록에 추가했지만 번호가 전화를 걸어도 경로 요청을 받지 않는 경우 JGW를 다시 시작하거나 PG를 순환해야 할 수 있습니다. JGW에서 추적을 켜고(trace *ROUTE*)에서 주소가 공급자에 없음을 표시하는 오류가 표시되는 경우에만 다시 시작해야 합니다.일반적으로 JGW는 다시 시작할 필요 없이 사용자 디바이스 목록에 추가된 새 CTI 경로 포인트를 인식할 수 있어야 합니다.또한 이미 존재하는 CTI 경로 포인트에 라인을 추가하는 경우 JGW는 다시 시작할 필요 없이 라인을 인식하지 못합니다.이미 존재하는 장치에 새 회선 대신 각 전화 건 번호에 대해 새 CTI 경로 포인트를 추가하는 경우 재시작을 피할 수 있어야 합니다.
참고: DeviceListPolling이 PIM의 winnt\java\lib 디렉토리에 있는 JTAPI.ini 파일에서 설정된 것으로 가정합니다.DeviceListPolling이 꺼져 있으면 DeviceListPolling을 켜야 합니다.DeviceListPolling이 꺼져 있고 사용자 목록에 디바이스를 추가하는 경우 PG에 대해 PG 또는 JTAPI GW 이상을 순환하여 새 디바이스를 확인해야 합니다.
opctest를 사용하여 경로 추적 "debug /routing"을 설정하고 경로 포인트에 대한 호출이 이루어진 경우 OPC 로그에서 오류를 확인합니다.경로 요청이 수신되고 레이블이 반환되는지 확인합니다.경로 요청은 "CSTA_ROUTE_REQUEST" 및 "ICR_NEW_CALL_REQ" 메시지로 나타납니다.반환된 레이블은 "ICR_CONNECT" 메시지로 나타납니다.오류가 발생하면 "ICR_CONNECT" 메시지 대신 "ICR_DIALOG_FAIL" 메시지를 볼 수 있습니다.이 경우 라우터 로그에서 오류를 확인합니다.
rtsetting.exe를 사용하여 경로 추적을 설정하고 경로 포인트에 대한 호출이 이루어진 경우 라우터 로그에서 오류를 확인합니다.
모든 필수 레이블이 구성되어 있는지 확인합니다.경로 스크립트가 IPCC/EA 에이전트를 대상으로 하는 경우 각 대상 디바이스 대상에 대해 사후 라우팅 클라이언트에 대해 레이블을 구성해야 합니다.
라우터 로그에서 오류를 확인합니다.없는 경우:
대기열 노드가 기본 우선 순위로 대기하는 경우 상담원을 사용할 수 있게 되면 아무 일도 일어나지 않습니다.이 문제를 해결하는 두 가지 옵션이 있습니다.
AutoLoginBase라는 라우터 레지스트리 설정이 있습니다(rtsetting.exe 사용). 통화를 기본 직무 그룹으로 대기시켜 예상대로 더 적게 작동하도록 하려면 이 설정을 변경합니다.이러한 유형의 대기가 발생할 경우 보조 기술보다 기본 기술에 대한 기본 설정은 없습니다.
대기열 노드의 기본 및/또는 보조 기술 집합에 명시적으로 대기합니다.
문제의 디바이스 대상 및 이 라우팅 클라이언트가 라우팅할 수 있는 다른 모든 대상에 대한 레이블을 구성합니다.ICR 구성을 통해 보다 효율적인 방법으로 AW 대량 구성 도구를 사용합니다.
경로 오류는 무조건 추적해야 합니다.
통화 추적기 도구를 사용하여 경로 경로를 테스트할 수 있습니다.
rtrtrace를 사용하여 경로 요청 추적을 설정하고 라우트 포인트에 대한 호출이 이루어진 경우 라우터 로그에서 오류를 확인합니다.
모든 필수 레이블이 구성되어 있는지 확인합니다.경로 스크립트가 IPCC/EA 에이전트를 대상으로 하는 경우 각 대상 디바이스 대상에 대해 레이블을 구성해야 합니다.각 디바이스 대상에는 통화를 전송하려고 시도하는 각 경로 클라이언트에 대해 구성된 레이블이 있어야 합니다.따라서 통화가 네트워크에서 사용 가능한 에이전트로 직접 사전 라우팅되는 경우 네트워크 라우팅 클라이언트에는 연결된 디바이스 대상에 대한 레이블이 있어야 합니다.통화가 먼저 VRU에서 대기된 다음 에이전트로 전달된 경우 VRU 라우팅 클라이언트에는 연결된 디바이스 대상에 대한 레이블이 있어야 합니다.
Configuration Manager/PG 탐색기 내의 Routing Client(라우팅 클라이언트) 탭에서 Use DN/Label map(DN/레이블 맵 사용)이 선택되어 있지 않은지 확인합니다.
PIM에서 추적(추적 전통화, trace *call_event*)을 설정하고 로그를 확인하려면 procmon을 사용합니다.라우터에서 통화 전 메시지가 나타납니다.또한 에이전트 내선 번호로 "DevTgDevStr"이 설정된 "DeliveredEvent"가 표시됩니다.통화가 표시되지 않으면 경로 클라이언트에 대한 레이블이 올바른지 확인합니다.
Cisco CallManager에서 일관성 없는 결과를 제공하므로 IPCC는 통화를 보류하고 새 통화를 하는 옵션을 지원하지 않습니다.이는 제품 개선으로 간주되며 향후 릴리스에서 고려할 수 있습니다.
상담 통화가 전환/대체/보류/검색되면 Cisco CallManager는 상담 연결을 끊습니다.따라서 지원되지 않는 임의 전송 시나리오가 발생합니다.상담원은 고객과 다시 연결하여 새 상담을 시작할 수 있습니다.IPCC 소프트폰은 해결될 때까지 대체 버튼을 비활성화하지만 타사 공급업체는 불만을 제기할 수 있습니다.
Cisco CallManager에는 전화회의 개시자만 전화회의에 참가자를 더 추가할 수 있는 제한이 있습니다.다른 참가자는 Cisco CallManager에서 상대방을 추가할 수 없습니다.
상담원 데스크 설정에는 통화 불가능 상태의 상담원을 로그아웃하는 시간 설정이 있습니다.최대 비활성 시간은 2시간이지만 더 적게 사용하도록 구성할 수 있습니다.비활성 상태에서는 사용 가능 상태의 상담원이 로그아웃되지 않습니다.벨소리 없음 타이머(구성 가능한 상담원 데스크 설정)가 만료되면 상담원은 준비됨에서 준비 안 됨으로 전환됩니다.
CTI 서버에 구성된 하트비트 시간 초과가 있습니다.오래된 컴퓨터, 과중한 CTI 서버 또는 대역폭 문제가 있는 네트워크가 근본 원인이 될 수 있습니다.CTI 서버 로그는 로그에 오류를 보고해야 합니다.
ICR 구성(M)의 에이전트 데스크 설정과 에이전트 구성 파일 모두 에이전트 처리 방법에 동의해야 합니다.
구성 매개 변수의 ICM에서 주변 장치 구성에 작업 타이머가 있습니다.매개 변수를 \WORKTIMER 30으로 설정하여 자동 사용 시 30초 지연을 설정합니다.
데스크톱 구성 파일은 다음 위치에 있습니다.
\program files\geotel\cti desktop\Desk_Settings.cfg
Desk_Settings.cfg의 데이터 및 ICR(M) 에이전트 데스크 구성 설정에서 [수신]의 작업 모드는 [필요]로 설정해야 합니다.Required with Data는 자동 사용 가능 옵션을 대체합니다.
JTAPI GW 로그를 보고 상담 전송 실패 이유를 나타내는 오류가 있는지 확인합니다.상담원 소프트웨어가 상담원 통화에서 보류/검색 또는 대체 작업을 허용하는지 확인합니다.두 통화 중 하나가 보류/검색되면 통화가 더 이상 협의로 간주되지 않고 Cisco CallManager에서 "임의" 호전환으로 간주됩니다.Cisco CallManager에 임의 전송 문제가 있습니다.상담 통화 시 재연결하거나 전송을 완료하도록 사용자를 제한합니다.
현재 Cisco CallManager에서 전화회의가 완료되지 않은 경우 전화회의 시작 상담에 대한 연결 끊기 이벤트에 문제가 있습니다.통화를 두 번째로 분리하여 상담원 전화기의 통화 모양을 지웁니다.
먼저 활성 스크립트를 모니터링합니다.그런 다음 라우팅 클라이언트 및 VRU의 라우터, OPC 및 PIM 로그를 확인합니다.대부분의 오류는 무조건적으로 추적되지만, 어떤 일이 일어나는지 더 잘 이해하기 위해 추적을 할 수 있습니다.
다음은 변환 경로 시퀀스입니다.
라우팅 클라이언트가 라우터에 새 통화 요청을 생성합니다.
라우터는 IVR에 통화를 전달해야 하는 레이블이 있는 라우팅 클라이언트에 연결을 반환합니다.
그런 다음 IVR은 VRU PG가 주변 장치 대상을 찾는 데 사용하는 RequestInstruction을 보내야 합니다.
라우터는 요청 명령의 주변 장치 대상을 변환 라우트가 대기하는 주변 장치 대상과 일치시킵니다.
라우팅 스크립트는 고객이 설계한 대로 실행 스크립트 또는 대기열 노드를 계속 진행합니다.
활성 스크립트를 모니터링하여 오류 경로를 찾습니다.라우터 추적에서 오류를 확인합니다.경로 클라이언트가 초기 레이블을 수신하는지 확인합니다.VRU에서 통화를 수신하는지 확인합니다.VRU가 VRU PIM 또는 OPC 레벨에서 요청 명령을 전송하는지 확인합니다.
스크립트를 모니터링하고 요청이 VRU 노드에 대한 변환 경로로 이동하는지 확인합니다.
먼저, 경로 스크립트에서 변환 경로가 선택된 선택 또는 경로 선택 노드는 서비스 제어 VRU로 경로를 변환하기에 충분하지 않습니다.VRU 노드에 대한 변환 경로가 필요합니다.
두 번째, 통화는 변환 경로 노드에 도달함을 모니터에서 표시해야 합니다.여기서 오류가 발생하면 변환 경로를 확인할 수 없거나 IVR에서 RequestInstruction 경로 요청 메시지를 받지 못했음을 의미합니다.
변환 경로 시간 초과 오류는 라우터가 요청 명령을 받지 않음을 나타냅니다.OPC 및 VRU PIM에서 오류를 확인하고 RequestInstruction이 도착했는지 확인합니다.
라우터에서 어떤 일이 발생하는지 더 잘 파악하기 위해 라우터에서 rtrtrace 툴을 사용하여 "변환 라우팅" 및 "네트워크 VRU 추적"을 활성화합니다.VRU PG OPC에서 opctest로 서비스 제어 보고를 설정합니다.
요청 지시사항은 VRU PG에 대해 구성된 트렁크 그룹 중 하나에서 트렁크 그룹 주변 장치 번호에 매핑되는 유효한 트렁크 그룹을 나타내야 합니다.수정된 경우 VRU PG를 순환하여 트렁크 그룹 주변 장치 번호의 업데이트를 수신합니다.
IVR PG 라우팅 클라이언트에서 DN 레이블 매핑이 꺼져 있는지 확인합니다.IVR PG에는 네트워크 VRU 할당이 필요합니다.네트워크 VRU는 유형 2여야 합니다. IVR PG에는 네트워크 트렁크 그룹 및 트렁크 그룹이 할당되어 있어야 합니다.트렁크 그룹에서 네트워크 트렁크 그룹을 참조합니다.
NIC/사후 라우팅 PG에는 주변 장치 대상의 각 DNIS에 대한 레이블이 있어야 합니다.(변환 경로 마법사에서 라우팅 클라이언트에 대한 요청에 대한 DNIS와 동일한 레이블을 만듭니다.접두사에서 이를 설정하고 prefix = DNIS 옵션을 선택합니다.
VRU 라우팅 클라이언트에는 에이전트가 사용 가능해질 때 라우팅하는 디바이스 대상에 대해 구성된 레이블이 필요합니다.
이 Cisco IP IVR 섹션에서는 IP IVR과 ICM 간의 컨피그레이션 오류를 해결하는 방법에 대해 설명하며 IVR PG 사후 라우팅 및 변환 라우팅 설정과 관련된 일반적인 문제를 다룹니다.일반적인 IVR 오류에 대한 자세한 내용은 Cisco IP IVR 트러블슈팅 가이드를 참조하십시오.
일반적으로 appadmin(appadmin) > Engine(엔진) > Trace files(추적 파일) 웹 페이지 아래에서 MIVR 로그를 확인합니다.
Cisco CallManager, IVR 및 ICM에 구성된 IVR CTI 포트 및 CTI 경로 포인트
IVR CTI 포트 및 CTI 경로 포인트는 Cisco CallManager 전역 디렉터리의 IVR 사용자와 연결됩니다.
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\에 있습니다.
이는 일반적으로 IP IVR에 구성된 일부 CTI 포트 또는 CTI 경로 포인트가 구성되지 않았거나 Cisco CallManager의 IP IVR 사용자와 연결되지 않았음을 의미합니다.
또한 스크립트 이름이 올바르게 지정되지 않았거나 저장소 관리자에 업로드되지 않았음을 의미할 수 있습니다.
일반적으로 이 조건은 한 쪽 또는 다른 쪽의 부분 컨피그레이션 또는 일치하지 않는 컨피그레이션을 나타냅니다.
이는 잘못 구성된 라우팅 스크립트로, ICR 구성의 네트워크 VRU 스크립트 컨피그레이션에서 시간 초과를 너무 적게 허용합니다.
ICM용 IP IVR 인터페이스에서 사용할 수 있는 스크립트 중 일부는 매우 오래 실행되지만 ICM 네트워크 스크립트 컨피그레이션의 기본 시간 제한은 3분입니다.스크립트 시간이 초과되고 스크립트 실행 실패 경로가 다른 실행 스크립트를 재생하는 경우 이러한 실행 스크립트는 기본적으로 IVR에서 대기됩니다.스크립트가 대기열에서 제거되면 많은 스크립트가 서로 재생됩니다.
IVR 통계는 IPCC 서비스 수준 보고서에 중요합니다.따라서 문제 해결 방법에 대한 일부 정보가 여기에 포함됩니다.개괄적으로, VRU에서 구현된 통화가 연결된 대신 대기열에 있는 라우터 및 VRU PG의 변경 사항이 계산됩니다.통화가 라우팅되면 응답된 것으로 보고됩니다.대기열에 있는 고객이 통화의 연결을 끊으면 취소된 것으로 보고됩니다.자세한 내용은 핫픽스 53 및 54의 readme.txt를 참조하십시오.라우터는 라우터에 통화가 있는 상태를 나타내는 특수 대기열 이벤트를 전송합니다.
VRU PIM에 특별한 레지스트리가 설정되어 있으므로 중단을 최소화하려면 이 기능을 자발적으로 활성화해야 합니다.
엔터프라이즈 서비스 실시간 보고서 10은 하나 이상의 엔터프라이즈 주변 장치 보고서에 VRU 서비스 및 Cisco CallManager PG 서비스를 추가할 때 이 데이터를 특별히 사용합니다.엔터프라이즈 서비스 실시간 보고서를 사용하려면 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 PIM의 시작 로그가 존재하지 않는 경우 항의해야 합니다.
ServiceControlQueueReporting 키를 추가하고 값을 1로 설정합니다.
HKEY_LOCAL_MACHINE\SOFTWARE\GeoTel\ICR\<cust_inst>\<PG_inst>\PG\CurrentVersion\ PIMS\<pim_inst>\VRUData\Config
참고: 공간 제한으로 인해 이 키가 두 행 위에 나타납니다.
OPC 로그는 잘못된 서비스에 대해 통화가 계산되거나 서비스 보고서에 나타나지 않는 경우 서비스 매핑을 찾을 수 없음을 나타냅니다.
Cisco ICM은 데이터 통화 유형, 서비스 및 직무 그룹 테이블의 손쉬운 상관관계를 분석하도록 설계되지 않았습니다.숫자들은 일반적으로 각 그룹에서 약간 다른 의미를 갖습니다.통화에 대한 서비스는 하나만 있지만 둘 이상의 상담원이 관련된 경우 두 개의 직무 그룹이 있을 수 있습니다.RONA(Redirect On Answer 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분
종료_통화_세부 정보
경로_통화_세부 정보
Cisco CallManager에서 추적을 수집하는 경우 Services(서비스) > Trace Flags(추적 플래그)의 Cisco CallManager Admin(Cisco CallManager 관리) 페이지에서 플래그를 전환할 수 있습니다.0xCB05는 CTI 오류의 SDL 추적을 위해 설정된 올바른 추적 플래그입니다.디버그를 위해 서비스 매개 변수 아래에 0xCB05를 설정합니다.AVVID TAC 케이스 참조:자세한 내용은 문제 해결 정보를 수집합니다.문제 해결 가이드를 포함하여 Cisco CallManager 온라인 설명서를 참조하십시오.
Cisco CallManager의 추적을 켜는 방법에 대한 자세한 내용은 Cisco CallManager Traces for Cisco Technical Support 설정을 참조하십시오.
Cisco CallManager IP 주소 변경 및 서버 이름 변경을 참조하십시오.
Cisco CallManager PG에서 설정을 실행하고 Cisco CallManager PIM에 대한 JTAPI 서비스를 변경합니다.내선 이동 및/또는 전화 서비스가 있는 경우
CRA 엔진을 중지합니다.
CRA - Engine Configuration(엔진 컨피그레이션)에서 IP 주소를 변경합니다.
JTAPI에서 IP를 변경합니다.
서버에서 DC 디렉터리 서비스를 중지합니다.
디렉터리 구성에서 IP 주소를 변경합니다.
Cisco CallManager에서 System(시스템) > Server(서버)에서 IP Address(IP 주소)를 변경합니다.
System(시스템) > Enterprise Parameters(엔터프라이즈 매개변수)에서 URL의 IP 주소를 변경합니다.
Features(기능) > Phone Services(전화 서비스)의 모든 URL에서 IP 주소를 변경합니다.
서버 IP 주소 변경 - 네트워크 속성.
DHCP 옵션 150을 새 IP 주소로 변경합니다.
DC Directory, Cisco CallManager > System Profile > Hoteling의 호텔 프로필에서 IP를 변경합니다.
SQL Enterprise Manager를 엽니다.
플러그인 테이블의 URL에서 IP 주소를 변경합니다.
컨피그레이션 변경 사항을 백업하려면
stiBackup 구성을 엽니다.
모든 해당 탭에서 서버 IP 주소를 변경합니다.
Procmon은 PIM 및 JTAPI GW 프로세스를 디버깅하는 데 사용할 수 있는 명령줄 도구입니다.
사용법:procmon <customer name> <node> 프로세스
Procmon ipcc pg1a pim1
Procmon ipcc pg1a jgw1
Procmon ipcc cg1a ctisvr
각 프로세스에 대한 몇 가지 유용한 추적 설정은 다음과 같습니다.
JTAPI GW(procmon 사용)
trace JT_TPREQUEST(서드파티 요청 추적 사용)
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(통화 전 이벤트 추적 켜기)
trace *event(에이전트 및 통화 이벤트 추적 켜기)
trace csta*(CSTA 통화 이벤트 추적 설정)
CTI 서버(procmon 사용)
regset EMSTraceMask 0xf8(유용한 CTI 서버 추적 사용, 줄 바꿈 가능)
Opctest는 PG에서 OPC 프로세스를 디버깅하는 명령줄 도구입니다.
사용법:opctest /cust <고객 이름> /node <노드>
opctest /cust ipcc /노드 pg1a
유용한 설정
debug /agent(에이전트 이벤트 추적 설정)
debug /routing(라우팅 이벤트 추적 설정)
debug /cstacer(csta 이벤트 추적 설정)
debug /tpmsg(서드파티 통화 요청 추적 설정)
Rttest는 ICM에서 라우터 프로세스를 디버깅하는 명령줄 인터페이스 도구입니다.GUI 버전은 trtrace를 참조하십시오.
사용법:rttest /cust ipcc
라우터 레지스트리 설정을 변경하는 GUI 툴입니다.
설정을 기본값으로 다시 설정하는 옵션이 있습니다.
ICM에서 다양한 라우터 추적을 켜는 GUI 툴
IPCC에 특히 유용한 설정:
큐잉 - 큐잉 해제 문제
서비스 제어 - VRU 인터페이스 문제
Translation Routing(변환 라우팅) - 변환 경로 관련 문제
Cisco ICM 이진 파일을 텍스트 파일로 덤프합니다.디렉토리를 process logfiles 디렉토리로 변경합니다.
OPC, PIM 및 JtapiGW 프로세스 로그 파일은 icr\<customer_name>\<node>\logfiles\에 있습니다.
PG에는 cdlog라는 배치 파일이 있습니다. 여기서 >cdlog <cust> <node>를 입력합니다.
사용법:dumplog 프로세스 이름
dumplog /"(다른 dumplog 옵션에 대한 도움말)
dumplog jgw1
dumplog pim1
휴지통 로그 opc
VRU PG 캡처 파일을 보는 도구입니다.휴지통 로그와 비슷한 방식으로 작동합니다.
라우팅 스크립트를 디버깅하는 데 사용할 수 있는 Cisco ICM 툴입니다. 이 도구는 AW의 AW 메뉴 항목에서 찾을 수 있습니다.
IP IVR에서 JTAPI 클라이언트에 대한 JTAPI 추적을 설정하는 툴입니다.IPCC PG의 JTAPI 추적은 procmon 인터페이스로 제어됩니다.이 툴은 files\CiscoJtapiTools\ 프로그램에 있습니다.
Cisco CallManager, Cisco IP IVR 및 ICM에 대한 실시간 데이터를 표시하는 Microsoft Windows 2000 관리 툴입니다.진행 중인 통화, 등록된 디바이스 및 프로세스 CPU 사용률을 확인할 수 있습니다.이 도구는 시작 > 프로그램 > 관리 도구에서 찾을 수 있습니다.
Cisco ICM 로그 파일은 \icr\<cust>\<node>\logfiles에 있습니다.여기서 고객은 고객 인스턴스 이름 및 노드 참조 pg1a, 라우터, cg1a 등을 참조합니다.dumplog를 사용하여 로그 파일을 봅니다.
참고: vrutrace와 같은 추적 도구로 이벤트 캡처 파일을 볼 수 있습니다.이러한 파일은 다른 디렉토리에 있습니다.
Cisco CallManager 로그 파일은 일반적으로 \program files\cisco\ccm\trace에 있으며 추적 디렉토리는 다음과 같습니다.
CCM - CallManager SDI 로그
Dbl - 데이터베이스 레이어 로그
sdl - 통화 신호 로그
Tftp - tftp 서버에 대한 로그입니다.
추적 설정 아래의 Cisco CallManager 관리 페이지에서 이러한 파일에 대한 추적 설정을 수정할 수 있습니다.Cisco CallManager의 서비스 매개 변수에서 SDL 추적 설정을 수정할 수 있습니다.
IP IVR 로그 파일은\program files\wfavvid에 있습니다.appadmin 페이지에서 engine-trace 파일 아래의 IPIVR 로그 파일을 볼 수도 있습니다.
jtprefs.exe를 사용하여 JTAPI 이벤트를 켜고 IP IVR 엔진을 다시 시작할 때 Cisco JTAPI 클라이언트 로그를 볼 수 있습니다.
케이스를 열기 위해 데이터를 수집할 때 로그 파일 외에 이 섹션에 나열된 데이터를 수집합니다.
구성된 상담원 수는 얼마입니까?
구성된 게이트웨이는 몇 개입니까?
Cisco CallManager, JTAPI Client, ICM, Gateway IOS 버전 및 IP IVR
Cisco CallManager 버전은 Help(도움말) > About(정보) > Details(세부 정보)의 Cisco CallManager 관리 웹 페이지에서 찾을 수 있습니다.
JTAPI 클라이언트 버전을 찾으려면 Cisco CallManager PG의 \winnt\java\lib 디렉토리에 있는 명령 프롬프트에 jview CiscoJtapiVersion을 입력하면 됩니다.
또한 IP IVR 버전을 찾을 수 있습니다.
어떤 유형의 IVR을 사용 중입니까?
사용 중인 플랫폼 유형/CPU/물리적 메모리 양