Einleitung
In diesem Dokument wird die Fehlerbehebung bei abgebrochenen Anrufen beschrieben, während sich der Anrufer in der Warteschlange eines Customer Voice Portal (CVP) befindet. Rückruf ist möglich.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen 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 folgenden Software-Versionen:
- CVP 10.5(1)
- CVP Call Studio 10.5(1)
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 Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Problem
In einer CVP-gestützten Callback-Bereitstellung wird der Anruf beendet, nachdem der ursprüngliche Anrufer zurückgerufen wurde und der Anrufer in der Warteschlange auf einen Agenten wartet.
Fehlerbehebung
Schritt 1: Erfassen Sie ActivityLogs von CallbackWait- und CallbackQueue-Anwendungen auf dem CVP VXML-Server. Sie finden diese Protokolle in den Verzeichnissen:
C:\Cisco\CVP\VXMLServer\applications\CallBackWait\logs\ActivityLog\ und C:\Cisco\CVP\VXMLServer\applications\CallBackQueue\logs\ActivityLog\.
Schritt 2: Suchen Sie den fehlerhaften Anruf in den CallbackQueue ActivityLogs. Sie können nach Fehlern oder Warnungen suchen, um den fehlerhaften Anruf für den jeweiligen Zeitstempel zu finden.
Snippet CallbackQueue ActivityLogs:
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 können, wird eine Warnmeldung angezeigt, die angibt, dass die Sitzung ein Timeout aufweist. Dies wird in den VXML-Gateway-Protokollen als Badfetch-Fehler gemeldet.
Schritt 4: Tomcat-Protokolle vom VXML-Server sammeln. Sie finden die Tomcat-Logs 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), die für intensive E/A-Operationen (Input/Output) verwendet wird.
Schritt 5: Überprüfen der Netzwerkverbindung zwischen dem CVP VXML-Server und dem CVP VXML-Gateway Wenn dieser Tomcat-Fehler gemeldet wird, befinden sich das VXML-Gateway und der CVP VXML-Server in den meisten Szenarien in unterschiedlichen Subnetzen.
Lösung
Schritt 1: Stellen Sie sicher, dass fetchtimeout auf mindestens 60 Sekunden konfiguriert ist. Führen Sie die folgenden Schritte aus, wenn Sie fetchtimeout nicht konfiguriert haben.
- Fügen Sie dem Stammdokument die VoiceXML-Eigenschaft fetchtimeout 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 in Call Studio - Root Doc Settings aus.
- Geben Sie unter VoiceXML Property fetchtimeout und unter Value das gewünschte Timeout ein. Geben Sie beispielsweise für 60 Sekunden 60 s 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\.
Zum 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 ein Tomcat-Problem, das nicht einem CVP-Produkt zugeordnet wird. Weitere Informationen finden Sie unter CSCus07896.
Schritt 3: Um die Paketverzögerungen bei der Verwendung verschiedener Subnetze zu beheben, wird empfohlen, den Windows-Registrierungsschlüssel "TcpAckFrequency" in "1" zu ändern.
Hinweis: Diese Empfehlung behandelt Netzwerkprobleme (sofern vorhanden) bei der CVP-Lösung, die ein anderes Subnetz verwendet. Weitere Informationen finden Sie unter CSCuq0750.
Feedback