Índice

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Problema

Troubleshooting

Solução

Introdução

Este original descreve como pesquisar defeitos gotas do atendimento quando o chamador estiver na fila em um desenvolvimento portal da rechamada da cortesia da Voz de cliente (CVP).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Server do atendimento CVP

- Server do linguagem de marcação extensível da Voz CVP (VXML)

- Aplicativos do estúdio do atendimento CVP

- Gateways VXML

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

- CVP 10.5(1)

- O CVP chama o estúdio 10.5(1)

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se sua rede está viva, assegure-se de que você compreenda o impacto potencial do comando any.

Problema

Em um desenvolvimento da rechamada da cortesia CVP, depois que o chamador original está chamado para trás e quando o chamador esperar na fila por um agente as gotas do atendimento.

Troubleshooting

Etapa 1. Recolha ActivityLogs dos aplicativos de CallbackWait e de CallbackQueue no server CVP VXML. Você pode encontrar que estes entram os diretórios:

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

Etapa 2. Encontre o atendimento ruim no CallbackQueue ActivityLogs. Você pode procurar pelo erro ou pelo warnig para encontrar o atendimento ruim para o timestamp específico.

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

Etapa 3. Como você pode ver no ActivityLogs, um mensagem de advertência é encontrado, que indique que a sessão tem o intervalo. Isto é relatado nos logs do gateway VXML como um erro do badfetch.

Etapa 4. Recolha logs de Tomcat do server VXML. Você pode encontrar que Tomcat entra o diretório 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 você vê nos log de servidor de Tomcat, há umas exceções do ponteiro nulo no NIO (queobstrui o entrada/saída).

Note: O NIO é uma coleção da interface de programação do aplicativo de java (API) usada para o entrada/saída intensivo (I/O) operações.

Etapa 5. Verifique a conectividade de rede entre o server CVP VXML e o gateway CVP VXML. Na maioria de encenações, quando este erro de Tomcat são relatados o gateway VXML e o server CVP VXML está em sub-redes diferentes.

Solução

Etapa 1. Assegure-se de que o fetchtimeout esteja configurado ao mínimo 60 segundos. Siga estas etapas se você não configurou o fetchtimeout.

- Adicionar o fetchtimeout da propriedade do VoiceXML ao original da raiz.

- No estúdio unificado do atendimento, clicar com o botão direito no projeto desejado e escolha propriedades.

- Selecione no estúdio do atendimento - Enraíze ajustes Doc.

- Sob a propriedade do VoiceXML incorpore o fetchtimeout, e sob o valor incorpore o intervalo desejado. Por exemplo por 60 segundos incorpore 60s

Etapa 2. Altere o arquivo de Tomcat server.xml para incluir o useSendfile= " falso”.  Você pode encontrar este arquivo no diretório de C:\Cisco\CVP\VXMLServer\Tomcat\conf\.

Por exemplo:

<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: Esta é edição de Tomcat e não atribuído a um produto CVP. Consulte CSCus07896 para mais detalhes.

Etapa 3. Para endereçar os retardos do pacote quando as sub-redes diferentes estiverem usadas, hão uma recomendação mudar a chave do registro de Windows, TcpAckFrequency a 1.

Note: Esta recomendação é endereçar questões de rede (eventualmente) para a solução CVP que usa a sub-rede diferente. Refira CSCuq07550 para mais detalhes.