Introduzione
In questo documento viene descritto come risolvere i problemi relativi alle interruzioni di chiamata quando il chiamante è in coda in una distribuzione di callback per cortesia CVP (Customer Voice Portal).
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- CVP Call Server
- Server CVP Voice Extensible Markup Language (VXML)
- Applicazioni CVP Call Studio
- Gateway VXML
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software:
- CVP 10.5(1)
- CVP Call Studio 10.5(1)
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Problema
In una distribuzione di CVP Courtesy Callback, dopo che il chiamante originale è stato richiamato e mentre il chiamante attende in coda per un agente la chiamata viene interrotta.
Risoluzione dei problemi
Passaggio 1. Raccogliere ActivityLogs dalle applicazioni CallbackWait e CallbackQueue sul server VXML CVP. Questi registri sono disponibili nelle directory:
C:\Cisco\CVP\VXMLServer\applications\CallBackWait\logs\ActivityLog\e C:\Cisco\CVP\VXMLServer\applications\CallBackQueue\logs\ActivityLog\.
Passaggio 2. Trovare la chiamata non valida in CallbackQueue ActivityLogs. È possibile cercare error o warning per trovare la chiamata errata per il timestamp specifico.
Log attività callbackcoda frammento:
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
Passaggio 3. Come è possibile vedere in ActivityLogs, viene trovato un messaggio di avviso che indica che la sessione ha un timeout. Nei log di VXML Gateway questa condizione viene segnalata come errore di recupero.
Passaggio 4. Raccogliere i log Tomcat dal server VXML. I log di Tomcat si trovano nella directory 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)
Come si vede nei log del server Tomcat, esistono eccezioni del puntatore nulle a NIO (Input/Output non bloccante).
Nota: NIO è un insieme di API (Application Programming Interface) JAVA utilizzate per operazioni di I/O (Input/Output) intensive.
Passaggio 5. Verificare la connettività di rete tra il server VXML CVP e il gateway VXML CVP. Nella maggior parte degli scenari, quando questo errore Tomcat viene segnalato, il gateway VXML e il server VXML CVP si trovano in subnet diverse.
Soluzione
Passaggio 1. Verificare che fetchtimeout sia configurato su un minimo di 60 secondi. Se non è stato configurato il timeout del fetching, attenersi alla procedura seguente.
- Aggiungere la proprietà VoiceXML fetchtimeout al documento radice.
- In Unified Call Studio, fare clic con il pulsante destro del mouse sul progetto desiderato e scegliere Proprietà.
- Selezionare Call Studio - Root Doc Settings.
- In Proprietà VoiceXML immettere fetchtimeout e in Valore immettere il timeout desiderato. Ad esempio, per 60 secondi immettere 60s
Passaggio 2. Modificare il file server.xml di Tomcat per includere useSendfile="false". Il file si trova nella directory C:\Cisco\CVP\VXMLServer\Tomcat\conf\.
Ad esempio:
<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: si tratta di un problema di Tomcat e non è attribuito a un prodotto CVP. Per ulteriori informazioni, fare riferimento a CSCus07896.
Passaggio 3. Per risolvere i ritardi dei pacchetti quando vengono utilizzate subnet diverse, si consiglia di modificare la chiave del Registro di sistema di Windows, TcpAckFrequency, impostandola su 1.
Nota:si consiglia di risolvere gli eventuali problemi di rete della soluzione CVP che utilizza una subnet diversa. Per ulteriori informazioni, fare riferimento a CSCuq07550.
Feedback