In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
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.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:
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.
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.
Ein eingehender Anruf erhält kein CCB-Angebot. Der Anruf wird unabhängig von der geschätzten Wartezeit (EWT) direkt in die Warteschlange gestellt.
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.
Hinweis: ICM_NO_SHCEDULED_ALLOWED und das OK-Bit sind immer festgelegt
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
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";
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);
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.