Fehlerbehebung: CVP - Fehler bei der Validierung der Gateway-Kapazität mit Rückruf (CCB)

Einleitung

In diesem Dokument wird die Fehlerbehebung bei einem CCB-Problem mit Customer Voice Portal (CVP) beschrieben, wenn der Anrufer kein CCB-Angebot erhält, weil die Trunk-Gateway-Kapazität überschritten wurde.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• CVP
• Cisco CVP - Rückruf mit Genehmigung

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf folgenden Software-Versionen:

• CVP-Server 10.5
• Unified Contact Center Enterprise (UCCE) 10,5

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Hintergrundinformationen

Bevor das Gateway-Kapazitätsproblem behoben wird, ist es wichtig, den Trunk-Validierungsprozess in CCB zu verstehen. Grundsätzlich bestimmt der Prozess zuerst die Anzahl der Aufrufe aus der Callback_current-Tabelle mit EventTypeID in (21, 22, 23).   Ausstehend, in Bearbeitung, Vorübergehend für bestimmte Gateways und Standorte.

Bestimmen Sie zweitens aus derselben Callback_current-Tabelle die Anzahl der mit der verbundenen Ursache abgeschlossenen Anrufe:   EventTypeID = 24 (abgeschlossen) und CauseID = 27 (verbunden).

Schließlich werden diese beiden Werte hinzugefügt und mit der Anzahl der Trunks verglichen, die unter dem Service Survivability.tcl konfiguriert wurden.

Wenn das Ergebnis den konfigurierten Trunk-Grenzwert überschreitet, sendet der Prozess einen Fehler zurück (Rückgabe 1), andernfalls wird er ok zurückgesendet (Rückgabe 0).

Zusammenfassend lässt sich sagen, dass die für CCB verwendete Formel zum Validieren der Trunks lautet:

CCB-Trunks < (Callback_current-Tabelle mit EventTypeID in (21, 22, 23); Pending (Ausstehend), Inprogress, Tentative (für bestimmte Gateways) + Callback_current (Tabelle von EventTypeID = 24 (abgeschlossen) und CauseID = 27 (verbunden)

Wenn der Wert für CCB-Trunks niedriger ist, schlägt die Validierung fehl.

Symptome

Ein eingehender Anruf erhält kein CCB-Angebot. Der Anruf wird direkt an die Warteschlange weitergeleitet, unabhängig von der geschätzten Wartezeit

Fehlerbehebung

Schritt 1: Sammeln von Aktivitätsprotokollen aus der CallbackEntry-Anwendung des VXML-Servers (Voice Extensible Markup Language)

Schritt 2: Suchen Sie in den Aktivitätsprotokollen nach Anrufen, deren Validierung nicht erfolgt:

Validate_02,data,result,none

Das bedeutet, dass die Validierung nicht bestanden hat. Rufen Sie die GUID für diesen Anruf ab.  Filtern Sie den Anruf nach der Aktivitätsbezeichnung, und suchen Sie nach einem Anruf wie diesem Beispiel:

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

Schritt 3: Sammeln Sie CVP-Berichtsprotokolle für den Reporting Server. Suchen Sie in den CVP-Berichtsprotokollen nach derselben Kennung.

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

Schritt 4: Konvertieren Sie die Bitmaskennummer in eine Binärzahl. Verwenden Sie einen Programmierer-Rechner: 0001 00000011

Schritt 5: Überprüfen Sie die Bitmaske des CVP Reporting-Leitfadens auf CCB-Tabellen. Sie sollten sehen, dass die Validierung aufgrund von "EXCEED_CAPACITY_GW" fehlschlägt.

Schritt 6: Eingrenzen des Problems auf eine bestimmte Warteschlange. Überprüfen Sie das CCB-Servelet vom CVP-Reporting-Server, um festzustellen, ob es eine oder mehrere bestimmte Warteschlangen gibt, für die CCB nicht angeboten wird. Öffnen Sie einen Webbrowser, und geben Sie ein.

http://{IP-Adresse des Berichtsservers}:8000/cvp/CallbackServlet?method=Diag

Dies ist ein Beispiel für eine Warteschlange, in der CCB angeboten wird:

Dies ist ein Beispiel für eine Warteschlange, in der kein CCB angeboten wird.

Schritt 7.  Überprüfen Sie, ob die Warteschlangen von einem bestimmten Gateway bedient werden. Überprüfen Sie die Gateway-Konfiguration (Überlebensfähigkeit Anwendungsparameter).

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

Schritt 8: Wenn die Konfiguration korrekt ist, überprüfen Sie die in der Reporting Server-Datenbank (Informix) gespeicherten Informationen, um die Anzahl der Anrufe auf diesem spezifischen Gateway und an diesem Standort zu ermitteln. Sie können die CCB-ID (in diesem Fall 10.201.198.21) oder den Standort (in diesem Beispiel CALO) überprüfen.

Schritt 9. Greifen Sie auf dem Berichtsserver auf die Informix-Datenbank zu.

Öffnen Sie eine CMD-Eingabeaufforderung, und geben Sie Folgendes ein: DBACK

Navigieren Sie zu Verbindung > Verbinden.

CVP-Instanz auswählen

Typ Benutzername cvp_dbadmin

Passwort eingeben

Datenbank callback@cvp auswählen

Beenden und zu den Abfragesprachen navigieren

Schritt 10: Führen Sie die Abfrage aus:

Wählen Sie count(*) aus callback_current, wobei location == "CALO";

Schritt 11. Wenn der Wert gleich oder größer als der im Gateway für die Standorte konfigurierte Trunk-Wert ist, schlägt die Validierung fehl, da die maximal zulässige Anzahl von Trunks in der Tabelle Callback_Current erreicht wurde.

Anmerkung:  Wie im CVP Reporting-Leitfaden beschrieben, ist die Rückruftabelle in zwei Tabellen unterteilt: Callback_Current und Callback_History. Die beiden Tabellen sind identisch. Alle 30 Minuten werden die Daten abgeschlossener Anrufe aus "Callback_Pending" abgerufen und in "Callback_Historical" verschoben.

Schritt 12. Wenn der Trunk-Wert pro Standort seine Grenzen in der Callback_Current-Tabelle erreicht hat und keine Callbacks in der Warteschlange vorhanden sind, weist dies darauf hin, dass ein Problem beim Verschieben der Callback-Datensätze von Callback_Current in die Callback_Historical-Tabelle besteht.

Schritt 13: Stellen Sie sicher, dass CVPCallbackArchive unter den Aufgaben planen (CVP Reporting Server) ausgeführt wird. Navigieren Sie zu Start -> Programme -> Zubehör -> Systemprogramme -> Geplanter Task.

.

Schritt 14. Wenn diese Aufgabe CVPCallbackArchive abgeschlossen ist, stellen Sie sicher, dass der Exitcode (0x0) lautet.

Schritt 15. Wenn die Schritte 13 und 14 in Ordnung sind, aber noch keine Daten in der Tabelle Callback_Historical enthalten sind, müssen Sie bestimmen, warum die Informationen nicht in der Datenbank hinzugefügt werden. Überprüfen Sie die Integrität der in der aktuellen und historischen Tabelle gespeicherten Informationen.  Führen Sie diese Abfrage im Fenster informix dbaccess CMD aus:

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

Schritt 16:  Wenn die Anzahl 1 oder höher ist, bedeutet dies, dass der Primärschlüssel der aktuellen Tabelle bereits in der Verlaufstabelle vorhanden ist und die Informationen nicht zur Datenbank hinzugefügt werden. In den meisten dieser Szenarien führt eine Race-Bedingung dazu, dass doppelte Datensätze in die callback_current-Tabelle eingegeben werden.

Die Zuordnung von GUID zu Surrogateid erfolgt in der Warteschlangentabelle. In Situationen, in denen sich der Anruf von einem Callback-Wait zu einem Callback-Queue-Skript bewegt, scheint es ein Fenster zu geben, in dem der Archivierungsauftrag die Datensätze aus dem aktuellen in den Verlauf verschiebt und die Anwendung einen neuen Datensatz in die aktuelle Tabelle mit derselben Surrogateid eingibt.  Dieses Problem hängt mit CDETS CSCuq86400 zusammen.

Lösung

Schritt 1: Zugriff auf die Informix-Datenbank Öffnen Sie eine CMD-Eingabeaufforderung, und geben Sie Folgendes ein: DBACK

Schritt 2: Navigieren Sie zu connection > connect select cvp instance. Geben Sie den Benutzernamen cvp_dbadmin ein, und geben Sie password ein.

Schritt 3: Wählen Sie callback@cvp database exit, und navigieren Sie zu Query Languages

Schritt 4: Führen Sie folgende Befehle aus:

aus callback_current löschen, wobei surrogateid eintritt (wählen Sie surrogateid aus callback_history aus);

Wenn ein temporärer Tabellenfehler vorliegt, gehen Sie folgendermaßen vor:

Drop-Tabelle t1;

Schritt 5. Führen Sie die sp-Prozedur aus, die die Informationen aus der aktuellen in die historische Rückruftabelle aus dem Fenster dbaccess der Abfragesprache verschiebt.

EXECUTE PROCEDURE sp_arch_callback();

Schritt 6: Stellen Sie sicher, dass die aktuelle Tabelle nicht so viele Datensätze enthält wie zuvor.

Wählen Sie count(*) aus callback_current, wobei location == "CALO";

Permanente Lösung

Schritt 1: Navigieren Sie zu Cisco\CVP\informix_frag, und öffnen Sie sp_arch_callback.sql in einem Texteditor.

Schritt 2. Entfernen Sie den Kommentar zu dieser Zeile am Anfang der Datei: —drop, Prozedur sp_arch_callback;   (entfernen - am Anfang der Zeile).

Schritt 3: Fügen Sie diese Zeile hinzu: aus callback_current löschen, wobei surrogiert in (wählen Sie surrogateid aus callback_history aus) ; nachher

create procedure sp_arch_callback() Zeile.

Schritt 4: Speichern Sie die Datei.

Schritt 5. Dies ist ein Beispiel dafür, wie der erste Teil der Datei aussehen sollte.

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

 

 

Test Finale Lösung

Schritt 1:  Öffnen Sie eine CMD-Eingabeaufforderung, und führen Sie den folgenden Befehl aus: dbschema 

dbschema -d callback -f sp_arch_callback

Hinweis: Wenn Sie beim Ausführen des dbschema-Befehls ein Autorisierungsproblem haben, melden Sie sich als cvp_dbadmin beim Reporting-Server an, und versuchen Sie es noch einmal.

Schritt 2: Stellen Sie in der Ausgabe sicher, dass der Befehl Delete from ausgeführt wird.