Risoluzione dei problemi relativi alla convalida della capacità del gateway CCB (CVP Courtesy Callback)

Introduzione

In questo documento viene descritto come risolvere i problemi relativi a CVP (Customer Voice Portal) quando il chiamante non riceve un'offerta CCB perché la capacità del gateway trunk è stata superata.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• CVP
• Cisco CVP per gentile concessione di Callback

Componenti usati

Le informazioni di questo documento si basano sulle seguenti versioni software:

• CVP Server 10.5
• Unified Contact Center Enterprise (UCCE) 10.5

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Prima di risolvere il problema relativo alla capacità del gateway, è importante comprendere il processo di convalida del trunk in CCB. In pratica, il processo determina innanzitutto il numero di chiamate dalla tabella Callback_current con EventTypeID in (21,22,23);   In sospeso, In corso, Provvisorio per percorsi e percorsi specifici.

In secondo luogo, dalla stessa tabella Callback_current, determinare il numero di chiamate completate con cause connected:   EventTypeID = 24 (Completato) e CauseID = 27 (Connesso).

Il processo aggiunge infine questi due valori e li confronta con il numero di trunk configurati nel servizio Survivability.tcl.

Se il risultato supera la soglia dei trunk configurata, il processo restituisce un errore (valore restituito 1), altrimenti restituisce ok (valore restituito 0).

In sintesi, la formula per la convalida dei tronchi utilizzati per la BCC è la seguente:

CCB Trunks < (tabella Callback_current con EventTypeID in (21,22,23); In sospeso, In corso, Provvisorio per gateway specifici) + tabella Callback_current di EventTypeID = 24 (Completato) e CauseID = 27 (Connesso)

Se il valore CCB Trunks è inferiore, la convalida non riesce.

Sintomi

Una chiamata in entrata non riceve l'offerta CCB. La chiamata passa direttamente alla coda indipendentemente dal tempo di attesa stimato (EWT, Estimated Wait Time)

Risoluzione dei problemi

Passaggio 1. Raccogliere i log attività dall'applicazione CallbackEntry dal server VXML (Voice Extensible Markup Language).

Passaggio 2. Cercare nei log attività tutte le chiamate in cui la convalida non è valida:

Validate_02,data,result,none

Ciò significa che la convalida non è stata superata. Ottenere il GUID per la chiamata.  Filtrare la chiamata in base al callid dell'attività e cercare un callid come questo esempio:

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

Passaggio 3. Raccogliere i log di report CVP per il server di report. Trovare lo stesso callid nei log di report CVP.

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

Passaggio 4. Convertire il numero della maschera di bit in formato binario. Utilizzare una calcolatrice: 0001 00000011

Passaggio 5. Controllare la maschera di bit della guida CVP Reporting per le tabelle CCB. Si noti che la convalida non riesce a causa di "EXCEED_CAPACITY_GW".

Passaggio 6. Limitare l'emissione a una coda specifica. Controllare il servelet CCB dal server di reporting CVP per determinare se vi sono code specifiche in cui CCB non è offerta. Aprire un browser Web e digitare.

http://{Reporting Server Indirizzo IP}:8000/cvp/CallbackServlet?method=Diag

Questo è un esempio di coda in cui è offerta la funzione di BCC:

Questo è un esempio di coda in cui non viene offerta la funzione di BCC

Passaggio 7.  Verificare se le code sono servite da un gateway specifico. Controllare la configurazione del gateway (parametri dell'applicazione Survivability).

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

Passaggio 8. Se la configurazione è corretta, controllare le informazioni archiviate nel database del server di report (Informix) per determinare il numero di chiamate su questo gateway e percorso specifici. È possibile effettuare il controllo in base all'ID della BCC (in questo caso 10.201.198.21) o alla località (CALO nell'esempio).

Passaggio 9. Sul server di report, accedere al database Informix.

Aprire il prompt di CMD e digitare: dbacces

Selezionare connessione > connetti

Seleziona istanza cvp

digitare username cvp_dbadmin

digitare la password

selezionare callback@cvp database

uscire e passare a Linguaggi query

Passaggio 10. Eseguire la query:

Selezionare count(*) da callback_current dove location == "CALO";

Passaggio 11. Se il valore è uguale o superiore al valore del trunk configurato nel gateway per le posizioni, la convalida non riesce per questo motivo, in quanto è stato raggiunto il numero massimo di trunk consentiti nella tabella Callback_Current.

Nota:  Come indicato nella guida di CVP Reporting, la tabella Callback è una vista di due tabelle: Callback_Current e Callback_Historical. Le due tabelle sono identiche. Ogni 30 minuti, i dati per le chiamate completate vengono estratti da Callback_Pending e spostati in Callback_Historical.

Passaggio 12. Se il valore del trunk per posizione ha raggiunto i limiti nella tabella Callback_Current e non sono presenti callback nella coda, si è verificato un problema durante lo spostamento dei record di callback da Callback_Current alla tabella Callback_Historical.

Passaggio 13. Verificare che CVPCallbackArchive sia in esecuzione in Pianificazione attività (CVP Reporting Server). Selezionare Start -> Programmi -> Accessori -> Utilità di sistema -> Operazioni pianificate.

.

Passaggio 14. Se l'attività CVPCallbackArchive viene completata, verificare che il codice di uscita sia (0x0).

Passaggio 15. Se i passaggi 13 e 14 sono corretti ma non contengono ancora dati nella tabella Callback_Historical, sarà necessario determinare il motivo per cui le informazioni non vengono aggiunte nel database. Controllare l'integrità delle informazioni memorizzate nella tabella corrente e nella tabella cronologica.  Eseguire questa query nella finestra CMD di informix dbaccess:

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

Passaggio 16.  Se il conteggio è uguale o superiore a 1, la chiave primaria della tabella corrente esiste già nella tabella cronologica e le informazioni non vengono aggiunte al database. Nella maggior parte di questi scenari, una race condition determina l'immissione di record duplicati nella tabella callback_current.

Il mapping da GUID a ID surrogato viene eseguito nella tabella di coda. In situazioni in cui la chiamata si sposta dalla richiamata in attesa dello script della coda di richiamata, sembra esserci una finestra in cui il job di archiviazione sposta i record dalla posizione corrente alla cronologia e l'applicazione immette un nuovo record nella tabella corrente con lo stesso surrogateid.  Questo problema è correlato a CDETS CSCuq86400

Soluzione

Passaggio 1. Accedere al database Informix. Aprire il prompt di CMD e digitare: dbacces

Passaggio 2. Passare a connessione > connetti seleziona istanza cvp. Digitare il nome utente cvp_dbadmin e la password

Passaggio 3. Selezionare callback@cvp database e passare a Linguaggi query

Passaggio 4. Eseguire i seguenti comandi:

delete from callback_current where surrogateid in (selezionare surrogateid from callback_history);

In caso di errore temporaneo della tabella, procedere come segue:

drop table t1;

Passaggio 5. Eseguire la routine sp che sposta le informazioni dalla tabella di callback Corrente alla tabella di callback cronologica dalla finestra dbaccess della lingua della query.

EXECUTE PROCEDURE sp_arch_callback();

Passaggio 6. Verificare che nella tabella corrente non siano presenti tutti i record precedenti.

Selezionare count(*) da callback_current dove location == "CALO";

Soluzione permanente

Passaggio 1. Passare a Cisco\CVP\informix_frag e aprire sp_arch_callback.sql in un editor di testo.

Passaggio 2. Rimuovere il commento da questa riga all'inizio del file: - procedura di rilascio sp_arch_callback;   (rimuovi — all'inizio della riga).

Passaggio 3. Aggiungere la riga: delete from callback_current where surrogato in (selezionare surrogateid from callback_history) ; dopo

create procedure sp_arch_callback() riga.

Passaggio 4. Salvare il file.

Passaggio 5. Questo è un esempio di come dovrebbe apparire la prima parte del file.

{*********************************************************************************
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);

 

 

Soluzione finale di test

Passaggio 1.  Aprire il prompt di CMD ed eseguire il comando: schema DB 

dbschema -d callback -f sp_arch_callback

Nota: se si verifica un problema di autorizzazione durante l'esecuzione del comando dbschema, accedere come cvp_dbadmin al server di report e riprovare.

Passaggio 2. Dall'output, verificare che il comando Elimina da sia stato eseguito.