Calls failing at Send to VRU Node

Unanswered Question
May 18th, 2010

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

We discussed this recently. Did you read that series of posts? There was nothing conclusive there and the discussion trailed off. I'm happy to discuss it again.

It would have been better if the title of this thread was "aborts at Send to VRU". Failure (coming out the X port) is almost always due to incorrect configuration. Aborts are weird.

Regards,

Geoff

ranjan-98 Tue, 05/18/2010 - 08:53

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.

Gergely Szabo Tue, 05/18/2010 - 09:04

Just another set of silly questions:

- what does the VRU script do?

- did you check the Timeout value in the Network VRU Script explorer setting for that particular VRU script?

G.

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.

Regards,

Geoff

ranjan-98 Tue, 05/18/2010 - 10:45

Geoff,

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?

Thanks,

Charles

Abu Hadee Wed, 05/19/2010 - 02:07

Hi Charles,

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.

Hope this helps

Actions

This Discussion