Solved: Re: VXML Gateway error-not able to play file

sandeep pokhriyal · ‎04-26-2009

ICM-7.5

CVP-7

VXML- AS5350XM with AS5X-FC

attached is the configuration on VXML gateway.

The "Debug http client all" is showing this error.

in debug attachment.

geoff · ‎04-26-2009

Using H.323, I see.

I would say that your problem is with the implicit "Send To VRU" that the "Run External Script" calls in order to start the VRU leg.

Isolate the problem by inserting an explicit "Send To VRU" node as the first node.

Send the failure port to an "End" node so that survivability kicks in. The success port of the "Send To VRU" leads to your existing "Run External Script" node.

Speaking of survivability - I don't see you loading the survivability.tcl file as an application - typically called "cvp-survivability". This should be applied to the incoming POTS dial peer. I don't see an incoming POTS dial peer. You should be explicit and have that dial peer.

The setting for "ip host isn-vxml" is from CVP 3.0, and if I recall correctly, is not used anymore. I am mainly doing SIP these days, and haven't used H.323 since CVP 3.0 days, but I think I am correct.

In your bootstrap application (vru-leg), you don't need "param cvpserverhost" as it will automatically send to the app-server that started the switch leg - which is what you have. That setting is there if you want to go to a different app server from where the CVP Voice Browser runs (H.323 Service), but that's unlikely.

These will not solve your problem, but will give clarity.

The ICM script will fail at the "Send to VRU" node, and will go to the "End" node, and survivability will act. You should see that.

Now you need to figure out why. The VRU transfer label (configured for the CVP routing client on the NVRU) looks like "7001234567" from your router config. Make sure you are using a Type 10 NVRU for CVP 7.0.

7001234567 is of length 10 - make sure you have that configured on your CVP. Otherwise, CVP cannot locate the correlation ID.

Use rttrace to increase the trace on the Call Router and watch what happens. The Router wants to pause the script at the "Send To VRU" node and resume it when it gets back the correlation ID - it needs to have that to find the script it paused. Make sure this is working correctly.

How is the VRU transfer label getting back to the gateway? Are you using "Set Transfer Label" in your H.323 Voice Browser so the VRU leg goes back to the ingress gateway? Or do you have configuration in your gatekeeper to send "7001234567*" to the voice gateway?

Look at the CVP trace. What does it say?

Regards,

Geoff

View solution in original post

geoff · ‎04-26-2009

Using H.323, I see.

I would say that your problem is with the implicit "Send To VRU" that the "Run External Script" calls in order to start the VRU leg.

Isolate the problem by inserting an explicit "Send To VRU" node as the first node.

Send the failure port to an "End" node so that survivability kicks in. The success port of the "Send To VRU" leads to your existing "Run External Script" node.

Speaking of survivability - I don't see you loading the survivability.tcl file as an application - typically called "cvp-survivability". This should be applied to the incoming POTS dial peer. I don't see an incoming POTS dial peer. You should be explicit and have that dial peer.

The setting for "ip host isn-vxml" is from CVP 3.0, and if I recall correctly, is not used anymore. I am mainly doing SIP these days, and haven't used H.323 since CVP 3.0 days, but I think I am correct.

In your bootstrap application (vru-leg), you don't need "param cvpserverhost" as it will automatically send to the app-server that started the switch leg - which is what you have. That setting is there if you want to go to a different app server from where the CVP Voice Browser runs (H.323 Service), but that's unlikely.

These will not solve your problem, but will give clarity.

The ICM script will fail at the "Send to VRU" node, and will go to the "End" node, and survivability will act. You should see that.

Now you need to figure out why. The VRU transfer label (configured for the CVP routing client on the NVRU) looks like "7001234567" from your router config. Make sure you are using a Type 10 NVRU for CVP 7.0.

7001234567 is of length 10 - make sure you have that configured on your CVP. Otherwise, CVP cannot locate the correlation ID.

Use rttrace to increase the trace on the Call Router and watch what happens. The Router wants to pause the script at the "Send To VRU" node and resume it when it gets back the correlation ID - it needs to have that to find the script it paused. Make sure this is working correctly.

How is the VRU transfer label getting back to the gateway? Are you using "Set Transfer Label" in your H.323 Voice Browser so the VRU leg goes back to the ingress gateway? Or do you have configuration in your gatekeeper to send "7001234567*" to the voice gateway?

Look at the CVP trace. What does it say?

Regards,

Geoff

sandeep pokhriyal · ‎04-26-2009

Hi Geoff thxx for your elaborate suggestions.

I am calling from a phone registered to call manager. so i haven't configured POTS dial-peer.

The maximum length of DNIS is set to 10 in ICM configuration tab in CVP.

I am not using "Set Transfer Label".

I have configuration for the gatekeeper to send the call back to VXML gateway.

Here is the logs that come on CVP voice browser.

New call: From IP address=10.20.22.12 ANI=345 To DNIS=8888, stackID=14215534 : DNIS = 8888 : CID = 009EA44D1526519F0A000A03C0A86401

IP transfer in progress to 10.20.20.60 : DNIS = 8888 : CID = 009EA44D1526519F0A000A03C0A86401

Call successfully established (slow start) : DNIS = 8888 : CID = 009EA44D1526519F0A000A03C0A86401

Initiating IP transfer to 700123456710 : DNIS = 8888 : CID = 009EA44D1526519F0A000A03C0A86401

IP transfer in progress to 10.20.61.100 : DNIS = 700123456710 : GUID = BBFD378A3AF7001F1AD0C9CEEFFC85DB : CID = 009EA44D1526519F0A000A03C0A86401

IP transfer successfully established (slow start) : DNIS = 700123456710 : GUID = BBFD378A3AF7001F1AD0C9CEEFFC85DB : CID = 009EA44D1526519F0A000A03C0A86401

IP transfer - Agent hung up : DNIS = 700123456710 : GUID = BBFD378A3AF7001F1AD0C9CEEFFC85DB : CID = 009EA44D1526519F0A000A03C0A86401

Call ended : DNIS = 700123456710 : GUID = BBFD378A3AF7001F1AD0C9CEEFFC85DB : CID = 009EA44D1526519F0A000A03C0A86401

Call ended : DNIS = 8888 : CID = 009EA44D1526519F0A000A03C0A86401

geoff · ‎04-26-2009

This is the second CVP thread today that has caught me out - why didn't you say in your initial post that you are trying to make UCM-originated calls? Obviously my comments about "Set Transfer Label" are misleading for UCM-originated calls.

This is much harder to get right. Why not call in from the PSTN and get that working correctly?

Regards,

Geoff

sandeep pokhriyal · ‎04-27-2009

Hi Geoff,

i am calling through UCM because the E1 is still not available. It will take some more time but i wanted to finish all basic things.

anyways, the problem was with

"ip host isn-vxml"

i have changed it to "ip host cvpserver"

and it works.

thanks went through configuration guide again.

thanks for your other suggestions also i am implementing them as well.