05-12-2020 07:31 AM
Dears,
We are trying to implement Cisco CVP Standalone Outbound as described by Engineer Mr.Paul Tindal.
https://twitter.com/tindallpaul/status/919638559702822912
Below are the setup we are using,
Cisco PCCE 12.0
Cisco CVP 12.0
Cisco VVB 12.0
Voice Gateway 29XX
Did anyone implemented this setup.Need help in VVB Configuartion.
12-24-2021 03:37 AM
That's correct Muhammed, just multiple applications plus whatever polling number you want each of them to use.
01-31-2022 12:30 AM
Hi Mr. Paul,
We are running this setup for 1 month successfully.
Last week there was a slowness in application while picking the records from the database.
From the analysis we could see below errors.
VXML Application Error Logs :
10.76.109.206.1643210665592.503027.OutAOLBeneActSA,01/26/2022 18:25:41.936,A VoiceXML error occurred of type "error.badfetch": request (http://10.76.109.206:7000/CVP/Server) was timed out after 60000 milliseconds.
10.76.109.206.1643210665592.503027.OutAOLBeneActSA,01/26/2022 18:25:41.936,An error has occurred.
10.76.109.206.1643210665592.503027.OutAOLBeneActSA,01/26/2022 18:25:41.998,A VoiceXML error occurred of type "error.badfetch.http": Audio Prompt URL null failed
10.76.109.206.1643210665592.503027.OutAOLBeneActSA,01/26/2022 18:25:41.998,An error has occurred.
10.76.109.206.1643210620717.502995.OutAOLBeneActSA,01/26/2022 18:25:41.998, The error was: Another thread is currently working on this session. This means the original thread took too long to complete what it was doing. To prevent abnormal behaviour the original thread will exit immediately. The call should not be affected.
com.audium.server.MultipleThreadException: Another thread is currently working on this session. This means the original thread took too long to complete what it was doing. To prevent abnormal behaviour the original thread will exit immediately. The call should not be affected.
at com.audium.server.session.ControllerData.isCurrentThreadOwner(ControllerData.java:5310)
at com.audium.server.voiceElement.DecisionElementBase.service(DecisionElementBase.java:395)
at com.audium.server.controller.Controller.goToDecision(Controller.java:4319)
at com.audium.server.controller.Controller.goToElement(Controller.java:4069)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4161)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.doPost(Controller.java:1167)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
And we could see that for the New Call request from VVB, VXML Subsystem is processing this new call after 10 seconds and there by the delay.
How can we resolve this ?
01-31-2022 02:13 AM
Muhammed, this looks like an application issue rather than a problem with the outbound mechanism so very hard to say without seeing the application and logs. Is it using a custom element at point it fails?
01-31-2022 05:27 AM
We are using custom application and elements.
What will be impact if :
01-31-2022 08:56 AM
If your problem is with the backend not responding, decreasing timers just means the client side in the VVB will fail sooner if it doesn't get the next document. It won't prevent the server-side problem. Unless you know why this is happening, I'd be a bit concerned about the server-side processing that's giving rise to the many iterations through these methods when processing a single HTTP request from the VVB.
at com.audium.server.controller.Controller.continueCall(Controller.java:3753)
at com.audium.server.controller.Controller.goToElement(Controller.java:4169)
02-01-2022 03:03 AM
We will look into the application side as well in this case.
When the issue occurred, From the VXML Logs (C/Cisco/CVP/Logs/VXML) we could see for a new call request from VVB (10.76.117.210) it took 10 seconds to start the application.
In normal cases we are seeing this in same seconds.
10.76.109.206: Jan 26 2022 20:27:40.816 +0300: %CVP_11_6_VXML_SERVER-7-CALL: {Thrd=http-processor49} Controller:newCall: CALLGUID=976DC65A0A4C75D2003CD0BC1000017E - [NEW_CALL] - appname=OutAOLBeneActSA, RemoteHost=10.76.117.210, RemoteAddr=10.76.117.210, cookie=null DNIS=7788001 ANI=sip:10.106.1.23
4256841: 10.76.109.206: Jan 26 2022 20:27:40.816 +0300: %CVP_11_6_VXML_SERVER-7-CALL: {Thrd=http-processor49} LicenseManagerSessionObject:valueBound: CALLGUID=976DC65A0A4C75D2003CD0BC1000017E - License obtained; JSessionID=14F1A8A5A86CCBEFA95418598E2E672F SessionID=10.76.109.206.1643218060816.506395.OutAOLBeneActSA Licenses in Use=45
After 10 second only Application Started
12130515: 10.76.109.206: Jan 26 2022 20:27:50.284 +0300: %CVP_11_6_VXML-7-CALL: {Thrd=Thread-22} DatafeedMgr:handleStartEvent: VXML subsystem is processing a new call, callGuid=976DC65A0A4C75D2003CD0BC1000017E, appName=OutAOLBeneActSA
02-13-2022 12:24 AM
Hi,
We have one more issue with VVB as it gives below error ,
170496989: Feb 13 00:02:02.115 AST %MIVR-SS_SIP-7-UNK:[CALLID=91C7B3FC-8B7D11EC-9C73F3FA-B524E91B]CCB : Timeout, args:[CALLID=91C7B3FC-8B7D11EC-9C73F3FA-B524E91B]
170496990: Feb 13 00:02:02.116 AST %MIVR-SS_SIP-7-UNK:[CALLID=91C7B3FC-8B7D11EC-9C73F3FA-B524E91B]survivability_timeout_expired.
170496993: Feb 13 00:02:02.116 AST %MIVR-SS_SIP-7-UNK:[CALLID=91C7B3FC-8B7D11EC-9C73F3FA-B524E91B] CCB: ENG waiting thread woke up
170496997: Feb 13 00:02:02.116 AST %MIVR-SS_SIP-7-UNK:[CALLID=91C7B3FC-8B7D11EC-9C73F3FA-B524E91B] CCB: hasTimerFired: Timer fired.
170496998: Feb 13 00:02:02.116 AST %MIVR-SS_SIP-7-UNK:[CALLID=91C7B3FC-8B7D11EC-9C73F3FA-B524E91B] CCB: processVxmlCmd: returning:error
What will be the cause of this due this timeout No new polling was made.
02-14-2022 05:02 AM
It is most likely the Makecall dialing request sent to the cvp_outbound TCL app at the ingress gateway over SIP INFO didn't return a call outcome before the VVB timed out the request. I think that timeout is 120secs. When the SIP INFO is received, cvp_outbound hands-off the call to cvp_dialer so if no subsequent polling happened, it suggests the SIP INFO was never processed. Hard to say more without additional tracing.
07-20-2022 01:54 AM
Hi @ptindall ,
Good day,
We have a problem in this setup as Sometimes VVB stop sending NEW call to CVP. Upon restarting the VVB only it will work.
We checked the logs and found the last new call never reached the CVP and hence it is kind of stuck in VVB. How we can avoid this. We are having two CVPs in the setup.
07-21-2022 09:06 AM
Suggests there a generic problem in the VVB. You should try to gather some additional diagnostics and raise a TAC case if it's stopped processing all calls.
10-19-2022 03:18 AM
Hi Mr. Paul,
We have Multiple Application running on gateway, Wanted to know , how the TCL script is impacting the resources ?
Is this setup consuming PVDM recourses/CPU/Memory etc ?
And also is this setup can be implemented using Virtual cube ?
Regards,
Ashiq Mattil
10-19-2022 04:26 AM
The TCL app doesn't use PVDM resources but the calls you setup could do, depending on the configuration. Normal DSP rules apply as for any other calls transiting the gateway.
The outbound TCL app is not a heavyweight application. It should have a smaller footprint than the standard survivability TCL app for handling incoming calls to CVP. However, you should of course monitor resources and manage the outbound call load as its impact on the gateway will depend on how many calls you're making concurrently and whether they are made at high rate in a large block back-to-back.
Yes, TCL apps do work on vCUBE.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide