Introduction
Ce document décrit comment dépanner les appels abandonnés alors que l'appelant est en file d'attente dans un déploiement de rappel de courtoisie Customer Voice Portal (CVP).
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Serveur d'appels CVP
- Serveur CVP Voice Extensible Markup Language (VXML)
- Applications CVP Call Studio
- Passerelles VXML
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
- CVP 10.5(1)
- CVP Call Studio 10.5(1)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Problème
Dans un déploiement de rappel de courtoisie CVP, après le rappel de l'appelant d'origine et pendant que l'appelant attend un agent dans la file d'attente, l'appel est abandonné.
Dépannage
Étape 1. Collecter les ActivityLogs à partir des applications CallbackWait et CallbackQueue sur le serveur VXML CVP Vous pouvez trouver ces journaux dans les répertoires :
C:\Cisco\CVP\VXMLServer\applications\CallBackWait\logs\ActivityLog\et C:\Cisco\CVP\VXMLServer\applications\CallBackQueue\logs\ActivityLog\.
Étape 2. Trouvez l'appel incorrect dans les journaux d'activité de CallbackQueue. Vous pouvez rechercher l'erreur ou l'avertissement pour trouver l'appel incorrect pour l'horodatage spécifique.
Journaux d'activité RappelFileAttente :
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
Étape 3. Comme vous pouvez le voir dans les Journaux d’activité, un message d’avertissement s’affiche, indiquant que la session a expiré. Ceci est signalé dans les journaux de passerelle VXML comme une erreur de récupération erronée.
Étape 4 : collecte des journaux Tomcat à partir du serveur VXML Vous trouverez les journaux Tomcat dans le répertoire 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)
Comme vous le voyez dans les journaux du serveur Tomcat, il y a des exceptions de pointeur NULL au NIO (Non-blocking Input/Output).
Remarque : NIO est un ensemble d'API JAVA (Application Programming Interface) utilisé pour les opérations d'entrée/sortie (E/S) intensives.
Étape 5 : vérification de la connectivité réseau entre le serveur VXML CVP et la passerelle VXML CVP Dans la plupart des scénarios, lorsque cette erreur Tomcat est signalée, la passerelle VXML et le serveur VXML CVP se trouvent dans des sous-réseaux différents.
Solution
Étape 1. Assurez-vous que fetchtimeout est configuré sur un minimum de 60 secondes. Suivez ces étapes si vous n'avez pas configuré fetchtimeout.
- Ajoutez la propriété VoiceXML fetchtimeout au document racine.
- Dans Unified Call Studio, cliquez avec le bouton droit sur le projet souhaité et choisissez Propriétés.
- Sélectionnez Call Studio - Root Doc Settings.
- Sous VoiceXML Property, entrez fetchtimeout et sous Value, entrez le délai d'attente souhaité. Par exemple, pendant 60 secondes, entrez 60s
Étape 2. Modifiez le fichier server.xml Tomcat pour inclure useSendfile="false". Vous pouvez trouver ce fichier dans le répertoire C:\Cisco\CVP\VXMLServer\Tomcat\conf\.
Par exemple :
<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 -->
Remarque : Il s'agit d'un problème Tomcat et non attribué à un produit CVP. Référez-vous à CSCus07896 pour plus de détails.
Étape 3. Pour résoudre le problème des retards de paquets lorsque différents sous-réseaux sont utilisés, il est recommandé de remplacer la clé de Registre Windows, TcpAckFrequency, par 1.
Remarque : cette recommandation vise à résoudre les problèmes réseau (le cas échéant) de la solution CVP qui utilise un sous-réseau différent. Référez-vous à CSCuq07550 pour plus de détails.
Commentaires