cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5250
Views
0
Helpful
8
Replies

Calls failing at Send to VRU Node

ranjan-98
Level 1
Level 1

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

8 Replies 8

geoff
Level 10
Level 10

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

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
VIP Alumni
VIP Alumni

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

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

Charles,

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.

Regards,

Geoff

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

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.

Do you have any reason for seeing these?

Regards,

Geoff

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: