When there are number of calls hit the script in question, I am seeing there are few call aborts happen at "Send to VRU Node" and also agents getting either busy signals or beeps and find no customer on line. Can anyone assist me to figure out this issue? I have number of other similar scripts, but I didn't encounter any issues in the past
At the beginning of the deployment, I also had a front end annoucement "Network VRU Scipt" right after the Send to VRU Node. When I had that Run External Script piece, I had too many calls failed or gotten fast busy signals. I decided to narrow down the issue and removed the front end announcement. The problem seemed better for few hours. Now again the similar calls are aborting at the Send to VRU Node. I definitely need to resolve these issues. The business is emphasizing the "front end annoucement piece back in the script". It makes me worry a lot.
I don't think it matters what follows the "Send To VRU" node.
If it aborts there, it doesn't activate the other two types of nodes that result in a VXML exchange between Call Server and Voice Gateway - the Run External Script node and the Queue to Skill Group (or Agent) node.
Let's go through the steps to understand the possibilities.
1. Call arrives on the gateway and signals the Call Server (establishing the switch leg) and passes up the Dialed Number
2. PG send it up to the Call Router and based on Dialed Number - Call Type - Scheduled Script, starts the script and hits the Send To VRU node
3. VRU label comes back and the signalling goes to the gateway, hits the VRU leg dial peer and starts the bootstrap service (TCL)
4. This calls the bootstrap VXML which sends an application level "ping" to the Call Server to verify its alive/online.
5. Call Server responds using VXML and asks the gateway to contact it again with data
6. The gateway sends the second VXML request (with data) for the root document, and the Call Server replies with a fairly large VXML data transfer.
7. Now the VRU leg is established and, from the Call Router's point of view, the call exits the check port and moves on to (say) the Run External Script node for the first application message.
It is timing issues between 3 and 7 that cause aborts in the "Send To VRU". Since the request for the root document (step 6) results in one of the larger data transfers in the call process, it is here were the problem most likely occurs.
Your response makes sense. However, we have many similar scripts in our entity and almost everything working fine without any significant issues. We are following the same logic with other scripts to this one. Only this perticular one is failing. Where exactly I can start trouble shooting to nail down the problem? Can I see any logs in any servers?
What percentage of aborts do you see? At one customer I have, who has a lot of CVP branch offices in different countries, I see this abort vary from 0.2% to 5.5% and I have no explanation. All the scripts are the same.
There are few reasons, the "Send to VRU" node may fail
1. ICM Router fails to generate VRU label
2. CVP doesn't have route to send call to VXML GW
3. VXML GW isn't matching dial-peer with vru script
4. VXML GW can't establish HTTP Connection CVP
5. CVP Call Server wrongly interpretting vru label and corid
All of these I've seen while working with different customers.
I understand you are saying, all other script works fine. But in this particular script, are the calls coming via same routing client? Could there be some other routing client call may hit this script but couldn't get VRU label? (Router log viewer may help)
If it is small percentage of call not working, then I would rule out 2 and 3. But still one thing to check if you have "send to originator" check on CVP SIP Subsystem. In that case, Call from CUCM or other Voice GW that doesn't have tcl script will fail.
We've seen some issue http on vxml gw where it couldn't initiate http session. But that would affect any call after certain period of time
I would check the TCD/RCD to find the call that went via the failure branch. Check for the routing client, what label returned and go from there.
All misconfigurations as mentioned above will cause the Send To VRU node to fail. The script will show the call exiting the X port of the Send To VRU node. We are NOT talking about those conditions. We are talking about aborts in the Send To VRU node.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...