cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4679
Views
10
Helpful
26
Replies

Cisco CVP Standalone Outbound

Muhammed Ashiq
Level 1
Level 1

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.

26 Replies 26

That's correct Muhammed, just multiple applications plus whatever polling number you want each of them to use.

Muhammed Ashiq
Level 1
Level 1

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 ?

 

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?

We are using custom application and elements.

What will be impact if :

  •  we decrease the fetchtimeout under the VoiceXML Property of application
  • we decrease http client response timeout in VVB

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)

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

Muhammed Ashiq
Level 1
Level 1

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.

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.

Muhammed Ashiq
Level 1
Level 1

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.

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.

Muhammed Ashiq
Level 1
Level 1

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 ?

@ptindall 

Regards,

Ashiq Mattil

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.