Dépannez les baisses d'appel sur un déploiement de rappel de courtoisie CVP

Introduction 

Ce document décrit comment dépanner des baisses d'appel tandis que l'appelant est sur la file d'attente dans un déploiement de rappel de courtoisie du Customer Voice Portal (CVP).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Serveur d'appel CVP
• Serveur du langage XML de Voix CVP (VXML)
• Applications de studio d'appel CVP
• Passerelles VXML

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :

• CVP 10.5(1)
• Studio d'appel CVP 10.5(1)

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle commande.

Problème

Dans un déploiement de rappel de courtoisie CVP, après que l'appelant d'origine s'appelle de retour et tandis que l'appelant attend dans la file d'attente un agent les baisses d'appel.

Dépanner

Étape 1. Collectez ActivityLogs des applications de CallbackWait et de CallbackQueue sur le serveur CVP VXML. Vous pouvez trouver ces logins les répertoires :

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

Étape 2. Trouvez le mauvais appel dans le CallbackQueue ActivityLogs. Vous pouvez rechercher l'erreur ou le warnig pour trouver le mauvais appel pour l'horodateur spécifique. 

Extrait 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

Étape 3. Comme vous pouvez voir dans l'ActivityLogs, un message d'avertissement est trouvé, qui indique que la session a le délai d'attente. Ceci est signalé dans les logs de passerelle VXML comme erreur de badfetch.

Étape 4. Collectez les logs de Tomcat du serveur VXML. Vous pouvez trouver Tomcat ouvre une session 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 voyez dans les journaux du serveur de Tomcat, il y a des exceptions de pointeur null à NIO (entrée/sortie non groupant).

Note: Le NIO est une collection de l'interface de programmation d'application Java (API) utilisée pour des exécutions intensives de l'entrée/sortie (E/S).

Étape 5. Vérifiez la connexion réseau entre le serveur CVP VXML et la passerelle CVP VXML. Dans la plupart des scénarios, quand cette erreur de Tomcat est signalée la passerelle VXML et le serveur CVP VXML sont dans les différents sous-réseaux.

Solution

Étape 1. Assurez-vous que le fetchtimeout est configuré au minimum 60 secondes. Suivez ces étapes si vous n'avez pas configuré le fetchtimeout.  

• Ajoutez le fetchtimeout de propriété de VoiceXML au document de racine.
• Dans le studio unifié d'appel, cliquez avec le bouton droit sur le projet désiré et choisissez Properties.
• Sélectionnez sur le studio d'appel - Enracinez les configurations de documentation.
• Sous la propriété de VoiceXML écrivez le fetchtimeout, et sous la valeur écrivez le délai d'attente désiré. Par exemple pendant 60 secondes écrivez 60s

Étape 2. Modifiez le fichier de Tomcat server.xml pour inclure l'useSendfile= " faux ».  Vous pouvez trouver ce fichier dans le répertoire de 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 -->

Note: C'est question de Tomcat et non attribué à un produit CVP. Référez-vous CSCus07896 pour plus de détails.

Étape 3. Pour adresser les retards de paquet quand des différents sous-réseaux sont utilisés, il y ont une recommandation de changer la clé de registre de fenêtres, TcpAckFrequency à 1.

Note: Cette recommandation est d'aborder des problèmes de réseau (le cas échéant) pour la solution CVP qui utilise le différent sous-réseau. Référez-vous à CSCuq07550 pour plus de détails.