I have a Comprehensive deployment model with a CVP 7.0.2 and wish to know how to disable the system function that put on hold state all request calls when all licensed ports have been taken.
I need that the all new calls that do not reach any licensed port are dropped. This is because we are experiencing an undesired behavior when the clients drop the call during the hold state, that is, the session remains connected and therefore new calls can not reach available agents.
So, instead to hear "We are currently experiencing heavy call volume. Please hold...", I need to drop the call.
Before trying to change some core functionality of the system I would look into why the callers are staying connected. How long are they staying connected after they hang up?
The time that the callers stay connected is variable, because some of them hangs after a couple of minutes, and some gets the busy tone after 5 seconds after hears the on-hold message.
The worst scenario I have seen in status.bat, is with 1000 calls on hold, 0 calls in queue (VXML application from the CVP), 150 calls in the welcome menu (VXML application from the CVP) and all agents idle and waiting for calls (30 agents). New calls gets busy tone.
With this conditions, the only way to recover the service was resetting the CVP server. But, by a contingency effect, the high volume of calls again provocó the ports overflow, with the same behavior having before the server reset.
Thanks for the help you could give me David. Regards.
The VXML session should be released when the customer drops in the "please hold" VXML application. This is clearly a bug.
One thing you may be able to do is to change the session timer so it doesn't take 30 mins to clean out those old sessions. Each application its own session timer, as you probably know. But I bet the overall session timer can be changed through Tomcat\web\CVP\WEB-INF\web.xml - but I sure don't know the configuration.
What does TAC say?
(PS - how many VXML ports? )
The TAC say that our design was bad sized and that we need to buy more CVP ports. They want we to replicate the scenario to make analysis over the fail, but this is a platform in production. So, we are planning to open a maintenance window and try to replicate the scenario but only with two licenced ports.
The TAC say that our design was bad sized and that we need to buy more CVP ports.
1. Can you let us know what inputs you used for the calculation to estimate the number of VXML ports required prior to the deployment?
(BHCA, average length of the time in the VXML application, average speed of answer, number of agents, after-call work time)
2. What number of ports did you come up with?
3. How many VXML applications do you have?
4. How many of these are Audium (Cisco VXML Studio) applications?
5. Do you do all queuing with microapps?
6. Have the numbers changed dramatically since the design?
7. What did A2Q say about your numbers?
Have you considered breaking out some menu structures and rebuilding them as microapps?
Although menus are very easy to build in Studio, they are actually quite simple in microapps and easier to maintain if the customer wants to alter the number of options. They are a poor use of valuable and expensive VXML ports which should be saved for the complex VXML applications that talk to back end systems (Database, Web Services etc). I no longer build menus in Studio.
Mixing microapp applications and CVP VXML applications would give you better use of your valuable ports.
We also faced this type of issue at one of our customer , there we faced VXML port hanged issue , so cisco recommended us to install ES31 on our CVPs CVP version was 7.0.2 after applying that patch issue was resolved .
Excellent advice. Can you post an extract from the ES release notes showing the resolved caveats? I have 25, 27, and 29; but not 31.
Here is the ES31 description
CSCsm27071 Cisco IOS Software Multiple Features IP Sockets Vulnerability The related info:
A vulnerability in the handling of IP sockets can cause devices to be vulnerable to a denial of service attack when any of several features of Cisco IOS Software are enabled.
A sequence of specially crafted
TCP/IP packets could cause any of the following results:
* The configured feature may stop accepting new connections or sessions.
* The memory of the device may be consumed.
* The device may experience prolonged high CPU utilization.
* The device may reload.
Cisco has released free software updates that address this vulnerability.
Workarounds that mitigate this vulnerability are available in the "workarounds"
section of the advisory.
The advisory is posted at