Fehlerbehebung bei Rufverlusten bei einer CVP Courtesy Callback-Bereitstellung

Einführung 

In diesem Dokument wird beschrieben, wie Sie bei einem Anrufer, der sich in einer Warteschlange in einem Customer Voice Portal (CVP) befindet, eine Behebung für ein Problem mit einem möglichen Rückruf finden.

  

Voraussetzungen

Anforderungen

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

• CVP-Anrufserver
• CVP Voice Extensible Markup Language (VXML)-Server
• CVP Call Studio-Anwendungen
• VXML-Gateways

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:

• CVP 10,5(1)
• CVP Call Studio 10.5(1)

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.

Problem

In einer CVP Courtesy Callback-Bereitstellung wird der Anruf beendet, nachdem der ursprüngliche Anrufer zurückgerufen und der Anrufer in der Warteschlange auf einen Agenten wartet.

Fehlerbehebung

Schritt 1: Sammeln von ActivityLogs aus CallbackWait- und CallbackQueue-Anwendungen auf dem CVP VXML-Server. Sie finden diese Protokolle in den Verzeichnissen:

C:\Cisco\CVP\VXMLServer\applications\CallBackWait\logs\ActivityLog\and C:\Cisco\CVP\VXMLServer\applications\CallBackQueue\logs\ActivityLog\.

Schritt 2: Suchen Sie den ungültigen Anruf in den CallbackQueue ActivityLogs. Sie können nach Fehler suchen oder warnen, um den falschen Anruf für den bestimmten Zeitstempel zu finden. 

Snippet CallbackQueue-AktivitätProtokolle:

10.85.137.68.1469202885038.5788.CallbackQueue_custom,07/22/2016 11:59:24.656,Queue1,element,warning,A session has timed out after 3 minutes. This is most likely caused by a start of call class or action element at the top of the callflow not completing before the voice browser's fetch timeout occurred. To resolve it ensure this class executes in a timely manner or run it in the background. Session timeouts may also occur under high load or if there are issues with a load balancer or voice browser. 
10.85.137.68.1469202885038.5788.CallbackQueue_custom,07/22/2016 11:59:24.656,Queue1,custom,Callback_Leave_Queue,ELEMENT_ENTRY 
10.85.137.68.1469202885038.5788.CallbackQueue_custom,07/22/2016 11:59:24.656,Queue1,custom,Callback_Leave_Queue,ELEMENT_EXIT 
10.85.137.68.1469202885038.5788.CallbackQueue_custom,07/22/2016 11:59:24.656,,end,how,app_session_complete 
10.85.137.68.1469202885038.5788.CallbackQueue_custom,07/22/2016 11:59:24.656,,end,result,timeout

Schritt 3: Wie Sie in ActivityLogs sehen, wird eine Warnmeldung gefunden, die angibt, dass die Sitzung eine Zeitüberschreitung aufweist. Dies wird in den VXML-Gateway-Protokollen als Badfetch-Fehler gemeldet.

Schritt 4: Erfassen Sie Tomcat-Protokolle vom VXML-Server. Sie finden die Tomcat-Protokolle im Verzeichnis C:\Cisco\CVP\VXMLServer\Tomcat\logs

java.lang.NullPointerException
      at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:240)
      at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest(InternalNioOutputBuffer.java:128)
      at org.apache.coyote.http11.AbstractHttp11Processor.endRequest(AbstractHttp11Processor.java:1586)
      at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1022)
      at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
      at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600)

Wie Sie in den Tomcat-Serverprotokollen sehen, gibt es Nullzeigerausnahmen bei NIO (Non-Blocking Input/Output).

Hinweis: NIO ist eine Sammlung von JAVA Application Programming Interface (API) für intensive Eingabe-/Ausgabe (I/O)-Operationen.

Schritt 5: Überprüfen Sie die Netzwerkverbindung zwischen dem CVP VXML-Server und dem CVP VXML-Gateway. Wenn dieser Tomcat-Fehler gemeldet wird, befinden sich in den meisten Szenarien das VXML-Gateway und der CVP VXML-Server in unterschiedlichen Subnetzen.

Lösung

Schritt 1: Stellen Sie sicher, dass fetchtimeout auf mindestens 60 Sekunden konfiguriert ist. Folgen Sie diesen Schritten, wenn Sie fetchtimeout nicht konfiguriert haben.  

• Fügen Sie die VoiceXML-Eigenschaft fetchtimeout zum Stammdokument hinzu.
• Klicken Sie in Unified Call Studio mit der rechten Maustaste auf das gewünschte Projekt, und wählen Sie Eigenschaften aus.
• Wählen Sie unter Call Studio - Root Doc Settings aus.
• Geben Sie unter VoiceXML-Eigenschaft fetchtimeout und unter Value den gewünschten Timeout ein. Geben Sie beispielsweise für 60 Sekunden 60 ein.

Schritt 2: Ändern Sie die Datei Tomcat server.xml, um useSendfile="false" einzuschließen.  Sie finden diese Datei im Verzeichnis C:\Cisco\CVP\VXMLServer\Tomcat\conf\ .

Beispiel:

<Connector port="7000" useSendfile="false" redirectPort="7443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxHttpHeaderSize="8192" executor="tomcatThreadPool" acceptCount="1500"/>

<!-- A "Connector" using the shared thread pool-->


<!-- <Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> -->


<!-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation -->

Hinweis: Dies ist der Tomcat-Fehler, der nicht auf ein CVP-Produkt zurückzuführen ist. Weitere Informationen finden Sie unter CSCus07896.

Schritt 3: Um die Paketverzögerungen zu beheben, wenn verschiedene Subnetze verwendet werden, wird empfohlen, den Windows-Registrierungsschlüssel TcpAckFrequency in 1 zu ändern.

Hinweis:Diese Empfehlung zielt darauf ab, Netzwerkprobleme (falls vorhanden) für die CVP-Lösung zu beheben, die ein anderes Subnetz verwendet. Weitere Informationen finden Sie unter CSCuq07550.