Introducción
Este documento describe cómo resolver problemas de caídas de llamadas mientras la persona que llama está en cola en una implementación de Devolución de llamada de cortesía del portal de voz del cliente (CVP).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Servidor de llamadas CVP
- Servidor CVP Voice Extensible Markup Language (VXML)
- Aplicaciones de CVP Call Studio
- Gateways VXML
Componentes Utilizados
La información que contiene este documento se basa en estas versiones de software:
- CVP 10.5(1)
- CVP Call Studio 10.5(1)
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Problema
En una implementación de devolución de llamada de cortesía de CVP, después de que se devuelva la llamada a la persona que llama original y mientras la persona que llama espera en cola a un agente, la llamada se interrumpe.
Troubleshoot
Paso 1. Recopile los registros de actividad de las aplicaciones CallbackWait y CallbackQueue en el servidor CVP VXML. Puede encontrar estos registros en los directorios:
C:\Cisco\CVP\VXMLServer\applications\CallBackWait\logs\ActivityLog\y C:\Cisco\CVP\VXMLServer\applications\CallBackQueue\logs\ActivityLog\.
Paso 2. Busque la llamada incorrecta en CallbackQueue ActivityLogs. Puede buscar error o advertencia para encontrar la llamada incorrecta para la marca de tiempo específica.
Registros de actividad de CallbackQueue de fragmentos:
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
Paso 3. Como puede ver en los ActivityLogs, se encuentra un mensaje de advertencia, que indica que la sesión tiene tiempo de espera. Esto se informa en los registros de la gateway VXML como un error de recuperación incorrecta.
Paso 4. Recopile los registros de Tomcat del servidor VXML. Puede encontrar los registros de Tomcat en el directorio 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)
Como puede ver en los registros del servidor Tomcat, hay excepciones de puntero nulo en NIO (Entrada/Salida sin bloqueo).
Nota: NIO es una recopilación de la interfaz de programación de aplicaciones (API) de JAVA que se utiliza para operaciones de entrada/salida (E/S) intensivas.
Paso 5. Compruebe la conectividad de red entre el servidor CVP VXML y la puerta de enlace CVP VXML. En la mayoría de los escenarios, cuando se informa este error de Tomcat, la gateway VXML y el servidor VXML de CVP se encuentran en subredes diferentes.
Solución
Paso 1. Asegúrese de que fetchtimeout esté configurado como mínimo 60 segundos. Siga estos pasos si no ha configurado fetchtimeout.
- Agregue la propiedad VoiceXML fetchtimeout al documento raíz.
- En Unified Call Studio, haga clic con el botón derecho del ratón en el proyecto deseado y seleccione Properties.
- Seleccione On Call Studio - Root Doc Settings.
- En VoiceXML Property ingrese fetchtimeout, y en Value ingrese el tiempo de espera deseado. Por ejemplo, durante 60 segundos, introduzca 60s
Paso 2. Modifique el archivo Server.xml de Tomcat para incluir useSendfile="false". Puede encontrar este archivo en el directorio C:\Cisco\CVP\VXMLServer\Tomcat\conf\.
Por ejemplo:
<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 -->
Nota: Este es un problema de Tomcat y no se atribuye a un producto CVP. Consulte CSCus07896 para obtener más detalles.
Paso 3. Para solucionar los retrasos de paquetes cuando se utilizan diferentes subredes, se recomienda cambiar la clave del Registro de Windows, TcpAckFrequency, a 1.
Nota: Esta recomendación es para solucionar problemas de red (si los hay) para la solución CVP que utiliza una subred diferente. Consulte CSCuq07550 para obtener más detalles.
Comentarios