Fehlerbehebung: CVP Courtesy Callback (CCB) Gateway Capacity Validation Failure

Einführung

In diesem Dokument wird beschrieben, wie Sie ein CCB-Problem beim Customer Voice Portal (CVP) beheben können, wenn der Anrufer kein CCB-Angebot erhält, da die Trunk Gateway-Kapazität überschritten wurde.

Voraussetzungen

Anforderungen

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

• CVP
• Cisco CVP - Courtesy Callback

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:

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

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Bevor eine Fehlerbehebung für das Gateway-Kapazitätsproblem durchgeführt wird, ist es wichtig, den Trunk-Validierungsprozess im CCB zu verstehen. Im Prinzip bestimmt der Prozess zunächst die Anzahl der Aufrufe aus der Callback_current-Tabelle mit EventTypeID in (21,22,23); Pending, Inprogress, Tentative für bestimmte Gateways und Standorte.

Zweitens bestimmen Sie aus derselben Callback_current-Tabelle die Anzahl der Anrufe, die mit der verbundenen Ursache abgeschlossen wurden: EventTypeID = 24 (abgeschlossen) und CauseID = 27 (verbunden).

Schließlich fügt der Prozess diese beiden Werte hinzu und vergleicht sie mit der Anzahl der Trunks, die unter dem Service Survivability.tcl konfiguriert wurden.

Wenn das Ergebnis den konfigurierten Trunks-Grenzwert überschreitet, sendet der Prozess einen Fehler zurück (return 1), ansonsten sendet er ok (return 0) zurück.

Zusammenfassend lässt sich sagen, dass folgende Formel zur Validierung der für CCB verwendeten Trunks lautet:

CCB-Trunks < (Callback_current-Tabelle mit EventTypeID in (21,22,23); Pending, Inprogress, Tentative for specific Gateways) + Callback_current table of EventTypeID = 24 (Completed) und CauseID = 27 (Connected)

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

Symptome

Ein eingehender Anruf erhält kein CCB-Angebot. Der Anruf wird unabhängig von der geschätzten Wartezeit (EWT) direkt in die Warteschlange gestellt.

Fehlerbehebung

Schritt 1: Erfassen Sie Aktivitätsprotokolle von der CallbackEntry-Anwendung vom VXML-Server (Voice Extensible Markup Language).

Schritt 2: Suchen Sie in den Aktivitätsprotokollen nach Anrufen, bei denen keine Validierung erfolgt:

Validate_02,data,result,none

Das bedeutet, dass die Validierung nicht erfolgreich war. Rufen Sie die GUID für diesen Anruf ab.  Filtern Sie den Anruf nach der angerufenen Aktivität, und suchen Sie nach einem Anruf wie im folgenden Beispiel:

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

Schritt 3: Erfassen Sie CVP-Berichtsprotokolle für den Reporting-Server. Suchen Sie den gleichen Kalender in den CVP-Reporting-Protokollen.

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

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

Schritt 5: Suchen Sie in der Bitmaske des CVP-Reporting-Handbuchs nach CCB-Tabellen. Sie sollten sehen, dass die Validierung aufgrund von "EXCEED_CAPACITY_GW" fehlschlägt.

Schritt 6: Schränken Sie das Problem auf eine bestimmte Warteschlange ein. Überprüfen Sie den CCB-Servelet vom CVP-Reporting-Server, um festzustellen, ob eine oder mehrere Warteschlangen vorhanden sind, für die kein CCB angeboten wird. Öffnen Sie einen Webbrowser, und geben Sie ein.

http://{Reporting Server IP Address}: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 (Survivability application parameters).

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 Aufrufe für dieses spezielle Gateway und diesen Standort zu bestimmen. Sie können die CCB-ID (in diesem Fall 10.201.198.21) oder den Speicherort (in diesem Beispiel CALO) überprüfen.

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

Öffnen Sie eine CMD-Aufforderung, und geben Sie Folgendes ein: Zugbänder

Navigieren Sie zu Verbindung > Verbindung

CVP-Instanz auswählen

Geben Sie den Benutzernamen cvp_dbadmin ein.

Kennwort eingeben

callback@cvp Datenbank auswählen

Beenden und Navigieren zu Abfragesprachen

Schritt 10: Führen Sie die Abfrage aus:

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

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

Hinweis: Wie im CVP-Reporting-Handbuch erwähnt, ist die Rückruftabelle eine Ansicht von zwei Tabellen: Callback_Current und Callback_Historical. Die beiden Tabellen sind identisch. Alle 30 Minuten werden Daten für abgeschlossene Anrufe aus Callback_Pending abgerufen und in Callback_Historical verschoben.

Schritt 12: Wenn der Trunk-Wert pro Standort seine Grenzen in der Tabelle "Callback_Current" erreicht hat und keine Rückrufe in der Warteschlange vorhanden sind, weist dies darauf hin, dass beim Verschieben der Rückrufdatensätze von "Callback_Current" in die Tabelle "Callback_Historical" ein Problem aufgetreten ist.

Schritt 13: Stellen Sie sicher, dass CVPCallbackArchive unter Schedule Tasks (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 der Datenbank hinzugefügt werden. Überprüfen Sie die Integrität der in der aktuellen und der Verlaufstabelle gespeicherten Informationen.  Führen Sie diese Abfrage im Informationsmix dbaccess CMD-Fenster aus:

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

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

Die GUID für die Surrogateid-Zuordnung erfolgt in der Warteschlangentabelle. In Situationen, in denen der Anruf von einem Callback-Wartewarteschlangen-Skript zum Callback-Warteschlangenskript wechselt, scheint es ein Fenster zu geben, in dem der Archivauftrag die Datensätze vom aktuellen zum Verlauf verschiebt und die Anwendung einen neuen Datensatz in die aktuelle Tabelle mit derselben Surrogateid eingibt.  Dieses Problem betrifft dieses CDETS CSCuq86400

Lösung

Schritt 1: Zugriff auf die Informix-Datenbank. Öffnen Sie eine CMD-Aufforderung, und geben Sie Folgendes ein: Zugbänder

Schritt 2: Navigieren Sie zu connection > connect und wählen Sie cvp instance aus. Geben Sie den Benutzernamen cvp_dbadmin ein, und geben Sie das Kennwort ein.

Schritt 3: Wählen Sie callback@cvp aus, und navigieren Sie zu Abfragesprachen.

Schritt 4: Führen Sie folgende Befehle aus:

Löschen von callback_current, wobei Surrogateid in (wählen Sie Surrogateid aus callback_history aus);

Wenn ein temporärer Tabellenfehler auftritt, tun Sie Folgendes:

Drop-Tabelle t1;

Schritt 5: Führen Sie die sp-Prozedur aus, mit der die Informationen aus dem Fenster dbaccess der Abfragesprache von Current in die Verlaufstabelle verschoben werden.

EXECUTE PROCEDURE sp_arch_callback();

Schritt 6: Stellen Sie sicher, dass in der aktuellen Tabelle nicht so viele Datensätze vorhanden sind wie zuvor.

Wählen Sie count(*) von callback_current aus, 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: Heben Sie diese Zeile am Anfang der Datei auf: —Drop procedure sp_arch_callback; (remove — at start of the line).

Schritt 3: Fügen Sie diesen Posten hinzu: von callback_current, wo Surrogateid in Surrogateid ist (wählen Sie Surrogateid aus callback_history aus) zu löschen; nach

Erstellen Sie die Zeile sp_arch_callback().

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

 

 

Finale Testlö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 bei der Ausführung des dbschema-Befehls ein Autorisierungsproblem vorliegt, melden Sie sich als cvp_dbadmin beim Berichtsserver an, und versuchen Sie es noch einmal.

Schritt 2: Stellen Sie in der Ausgabe sicher, dass der Befehl Löschen aus ausgeführt wird.