CCB(CVP Courtesy Callback) 게이트웨이 용량 검증 실패 문제 해결

소개

이 문서에서는 트렁크 게이트웨이 용량이 초과되어 발신자가 CCB 오퍼를 받지 못한 경우 CVP(Customer Voice Portal) CCB 문제를 해결하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

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

• CVP
• Cisco CVP 콜백

사용되는 구성 요소

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

• CVP 서버 10.5
• UCCE(Unified Contact Center Enterprise) 10.5

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

배경 정보

게이트웨이 용량 문제를 트러블슈팅하기 전에 CCB의 트렁크 검증 프로세스를 이해하는 것이 중요합니다. 기본적으로 이 프로세스는 먼저 EventTypeID가 (21,22,23)인 Callback_current 테이블의 호출 수를 결정합니다.   특정 게이트웨이 및 위치에 대해 보류 중, 진행 중, 미정

두 번째로, 동일한 Callback_current 테이블에서 원인을 연결하여 완료된 통화 수를 결정합니다.   EventTypeID = 24(완료됨) 및 CauseID = 27(연결됨)

마지막으로 이 두 값을 추가하고 Survivability.tcl 서비스 아래에 구성된 트렁크 수와 비교합니다.

결과가 구성된 트렁크 임계값을 초과하면 프로세스에서 오류를 다시 보냅니다(return 1). 그렇지 않으면 ok를 다시 보냅니다(return 0).

요약하면, CCB에 사용된 트렁크를 검증하는 공식은 다음과 같습니다.

CCB 트렁크 < (EventTypeID가 있는 Callback_current 테이블(21,22,23); 보류 중, 진행 중, 특정 게이트웨이에 대한 미정) + EventTypeID = 24(완료됨) 및 CauseID = 27(연결됨)의 Callback_current 테이블

CCB 트렁크 값이 더 낮으면 검증이 실패합니다.

증상

인바운드 통화는 CCB 제안을 받지 않습니다. EWT(Estimated Wait Time)와 상관없이 통화가 대기열로 직접 이동합니다

문제 해결

1단계. VXML(Voice Extensible Markup Language) 서버에서 CallbackEntry 응용 프로그램의 작업 로그를 수집합니다.

2단계. 활동 로그에서 검증이 없는 통화를 검색합니다.

Validate_02,data,result,none

이는 검증이 통과하지 못했음을 의미합니다. 이 통화의 GUID를 가져옵니다.  활동 callid를 기준으로 통화를 필터링하고 다음 예와 같은 callid를 찾습니다.

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

3단계. 보고 서버에 대한 CVP 보고 로그를 수집합니다. CVP 보고 로그에서 동일한 수신자 찾기

ValidateHandler:ValidateHandler.exec: ValidateHandler GUID=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB results:none validation status bitmask=0x00000103  

4단계. 비트 마스크 번호를 이진으로 변환합니다. 프로그래머 계산기 사용: 0001 00000011

5단계. CCB 테이블에 대한 CVP Reporting Guide(CVP 보고 가이드) 비트마스크를 확인합니다. "EXCEED_CAPACITY_GW" 때문에 검증이 실패하는 것을 볼 수 있습니다.

6단계. 문제를 특정 대기열로 좁힙니다. CVP 보고 서버에서 CCB Servelet을 확인하여 CCB가 제공되지 않는 특정 대기열이 있는지 확인하십시오. 웹 브라우저를 열고 를 입력합니다.

http://{보고 서버 IP 주소}:8000/cvp/CallbackServlet?method=Diag

다음은 CCB가 제공되는 대기열의 예입니다.

CCB가 제공되지 않는 대기열의 예입니다

7단계.  큐가 특정 게이트웨이에서 제공되는지 확인합니다. 게이트웨이 컨피그레이션(존속성 애플리케이션 매개변수)을 확인합니다.

application
 service new-call flash:bootstrap.vxml
 !
 service survivability flash:survivability.tcl
  paramspace callfeature med-inact-det enable
  param ccb id:10.201.198.21;loc:CALO;trunks:512

8단계. 컨피그레이션이 올바른 경우 Reporting Server 데이터베이스(Informix)에 저장된 정보를 확인하여 이 특정 게이트웨이 및 위치의 호출 수를 확인합니다. CCB ID(이 예에서는 10.201.198.21) 또는 위치(이 예에서는 CALO)를 기준으로 확인할 수 있습니다.

9단계. 보고 서버에서 Informix 데이터베이스에 액세스합니다.

CMD 프롬프트를 열고 다음을 입력합니다. 데이터베이스 액세스

connection(연결) > connect(연결)로 이동합니다.

cvp 인스턴스 선택

사용자 이름 cvp_dbadmin 입력

유형 암호

callback@cvp 데이터베이스 선택

쿼리 언어를 종료하고 쿼리 언어로 이동

10단계. 질의를 실행합니다.

위치 == "CALO"가 있는 callback_current에서 count(*)를 선택합니다.

11단계. 값이 해당 위치에 대해 게이트웨이에 구성된 트렁크 값과 같거나 그 이상인 경우 Callback_Current 테이블에서 허용된 최대 트렁크 수에 도달했으므로 검증이 실패한 이유입니다.

참고:  CVP 보고 가이드에서 참조한 대로 콜백 테이블은 다음 두 테이블의 뷰입니다. Callback_Current 및 Callback_Historical입니다. 두 테이블이 동일합니다. 완료된 통화에 대한 데이터는 30분마다 Callback_Pending에서 가져와 Callback_Historical로 이동합니다.

12단계. 위치당 트렁크 값이 Callback_Current 테이블에서 제한에 도달했으며 대기열에 콜백이 없는 경우 콜백 레코드를 Callback_Current에서 Callback_Historical 테이블로 이동하는 데 문제가 있음을 나타냅니다.

13단계. CVPCallbackArchive가 일정 작업(CVP 보고 서버)에서 실행되고 있는지 확인합니다. 시작 -> 프로그램 -> 보조프로그램 -> 시스템 도구 -> 예약 작업으로 이동합니다.

.

14단계. 이 작업 CVPCallbackArchive가 완료되면 종료 코드가 (0x0)인지 확인합니다.

15단계. 13단계와 14단계는 괜찮지만 Callback_Historical 테이블에 데이터가 없는 경우 데이터베이스에 정보가 추가되지 않는 이유를 확인해야 합니다. 현재 및 기록 테이블에 저장된 정보의 무결성을 확인합니다.  informix dbaccess CMD 창에서 다음 쿼리를 실행합니다.

Select  count (*) from callback_current where surrogateid in (select surrogateid from callback_historical);

16단계.  카운트가 1 이상이면 현재 테이블의 기본 키가 기록 테이블에 이미 있으며 정보가 데이터베이스에 추가되지 않음을 의미합니다. 이러한 대부분의 시나리오에서 경합 조건은 중복 레코드가 callback_current 테이블에 입력되도록 합니다.

GUID에서 서로게이트 ID로의 매핑이 대기열 테이블에서 발생합니다. 통화가 콜백 대기 상태에서 콜백 대기열 스크립트로 이동하는 경우 아카이브 작업이 현재 레코드에서 기록으로 이동하고 응용 프로그램이 현재 테이블에 동일한 surrogateid로 새 레코드를 입력하는 창이 있는 것 같습니다.  이 문제는 이 CDETS CSCuq와 관련이 있습니다86400

솔루션

1단계. Informix 데이터베이스에 액세스합니다. CMD 프롬프트를 열고 다음을 입력합니다. 데이터베이스 액세스

2단계. connection(연결) > connect(연결)로 이동하여 cvp 인스턴스를 선택합니다. 사용자 이름 cvp_dbadmin을 입력하고 password를 입력합니다.

3단계. callback@cvp 데이터베이스 종료를 선택하고 쿼리 언어로 이동합니다.

4단계. 다음 명령을 실행합니다.

surrogateid가 있는 callback_current에서 삭제(callback_historical에서 surrogateid 선택);

임시 테이블 오류가 있는 경우 다음을 수행합니다.

테이블 t1 삭제;

5단계. 쿼리 언어 창 dbaccess에서 현재 콜백 테이블에서 기록 콜백 테이블로 정보를 이동하는 sp 프로시저를 실행합니다.

프로시저 실행 sp_arch_callback();

6단계. 현재 테이블에 이전만큼 많은 레코드가 없는지 확인합니다.

위치 == "CALO"가 있는 callback_current에서 count(*)를 선택합니다.

영구적 솔루션

1단계. Cisco\CVP\informix_frag로 이동하여 텍스트 편집기에서 sp_arch_callback.sql을 엽니다.

2단계. 파일 시작 부분에서 이 라인의 주석 처리를 제거합니다. —drop 프로시저 sp_arch_callback;   (제거 - 줄 시작 부분)

3단계. 다음 라인을 추가합니다. surrogated in이 있는 callback_current에서 삭제(callback_historical에서 surrogateid 선택); 이후

create 프로시저 sp_arch_callback() 행.

4단계. 파일을 저장합니다.

5단계. 파일의 첫 번째 부분이 어떻게 표시되어야 하는지에 대한 예입니다.

{*********************************************************************************
Stored procedure to move completed calls out of the active table into the
historical table.
*********************************************************************************}
drop procedure sp_arch_callback;
create procedure sp_arch_callback()

DEFINE p_ageoff INTEGER;

-- delete any duplicates found in current table.

 

delete from callback_current where surrogateid in (select surrogateid from callback_historical);

 

 

최종 솔루션 테스트

1단계.  CMD 프롬프트를 열고 다음 명령을 실행합니다. dbschema 

dbschema -d callback -f sp_arch_callback

참고: dbschema 명령을 실행할 때 권한 부여 문제가 있는 경우 보고 서버에 cvp_dbadmin으로 로그인하고 한 번 더 시도하십시오.

2단계. 출력에서 Delete from 명령이 실행되었는지 확인합니다.