CVP and configuration migration

[bilalghayad]

Hello All;

With Refresh Technology, the CVP configuration (that will be done using the Ops Console): It can be migrated from the production to the new environment or should be done manual?

VXML Server configuration to be done from the Ops Consol, or any thing also need to be done at the VXML Server it self?

Thanks in advance for all who is going to help.

Regards

Bilal

[bilalghayad]

Dear Amer;

Where do u c the tech prefix to be #2 in the CVP? I checked what I sent for u and it is 2# !

2- did you configure a MRGL on the trunk and is MTP selected with the MRGL.

* You r talking about the CUCM trunk for the gateway? Really did not understand why this?

By the way: I am originating the call from the IP Communicator Softphone that is registered on the CUCM (as an IP Phone).

Regards

Bilal

[geoff]

ERROR: IP Transfer - Destination endpoint at IP address 10.180.22.101 refused connection for phone number 4519910019 with reason code Unreachable Destination : GUID

Put debug on your dial peers - when the call comes back in on the VRU transfer number dial peer you would see it, but I think it's not arriving. It's not being rejected - it's not getting there.

Are you using setTransferLabel as we discussed ? If you had this set in VBAdmin to 4519910019, then when it sees that label (plus the correlation ID) it sends it right back to the ingress gateway. If you have a combined gateway, it will come in and catch that dial peer.

Type 10 has lots of advantages. You should move up. You'll find out when you get to warm transfers.

Regards,

Geoff

[bilalghayad]

Dear Geoff;

Are you using setTransferLabel as we discussed ? If you had this set in VBAdmin to 4519910019, then when it sees that label (plus the correlation ID) it sends it right back to the ingress gateway. If you have a combined gateway, it will come in and catch that dial peer.

* Actually as i see in the output of the showall:

Transfer label is not currectly set.

But to set it correctly, I have to do this for each lable?

By the way, the label was configured on the ICM to be 4519, so maybe the 4519910019 is the label + correlation ID, correct?

How to set this transfer label?

As I see that the CVP Call Server is consulting with the gatekeeper and the gatekeeper is returning the IP address of the gateway, so why not to route for this gateway?

Type 10 has lots of advantages. You should move up. You'll find out when you get to warm transfers.

* Do u mean if I used the Type 10, then no need for above?

Appreciate your help Geoff.

Regards

Bilal

[bilalghayad]

Dear Geoff;

setTransferLabel this to be used if I am using the ingress gateway and the IOS browser on the same device.

Well, I am originating the call from Cisco IP Communicator Software registered on the CUCM (so like dialing from the IP Phone). From this Cisco IP Communication, I am dialing 44444 which is assigned to a gatekeeper trunk, the gatekeeper replied by the CVP Call server IP address which route the call to the ICM script that is trigerred.

But, when need to run the VXML script, then it should be run at the VXML IOS Browser and not to be returned for the CUCM.

In my scenario, the originating point different than the IOS VXML browser.

Do I need to setTransferLabel?

By the way, I set now the VRU type to be 10 for both (that for the Call Server CVP and that for the VXML IOS Gateway), and I noticed now that the returned label is 45199 and this is the configured label at the Configuratoin Manager. So now the returned value from the ICM script differs than when it was the type 5  for the CVP Call Server and 7 for the VXML IOS Gateway.

I am still stuck, why it is not sending for the IOS VXML Gateway?

Regards

Bilal

[geoff · Accepted solution]

Correct. setTransferLabel and the correspondng exclusions of the subscriber addresses are for PSTN calls into your combined gateway.

But let me ask you this - why are you starting with CVP calls by using an IP phone. That's much harder than for a call into the gateway. Almost everyone starts with that one, gets that working, and then goes onto warm transfer and CUCM-originated calls.

Can't you call into the gateway?

By the way, I set now the VRU type to be 10 for both (that for the Call Server CVP and that for the VXML IOS Gateway), 

What do you mean "both"? There should only be one NVRU - it should have a label for all CVP routing clients and a label for the CUCM RC. Why have you chosen the numbers you have chosen. Why not use what Cisco suggest? Does 8111111111 clash in your dial plan.

Here are my STRONG recommendations.

1. Use one Type 10 NVRU.

2. Set the label for the IVR transfer on the CVP PIMs to be 8111111111 (that's 8 and 9 ones for = total of 10 digits)

3. Ensure that the DNIS length in CVP is set to 10. Now it can easily find the correlation ID.

4. Set the label on the CUCM to be something different - I have traditionally used 8222222222 (again - a total of 10 digits)

5. Set up ICM System Config pages so that the correlation ID starts at 10000 and finishes at 99999. Now it will always be easy to find as it will always be 5 digits. If you let the defaults play, then it starts at 1 and goes to something (can't recall) and it's of length 1, then 2, then 3 and so on. Best to always make it 5 digits by fixing this. It won't solve your problem - but it will be easier to debug.

6. Now the dialpeer on the voice gateway to run the bootstrap would  be looking for 8T

(If these numbers will not work for you, think of another number that is outside your dialplan but has a strong pattern that's easy to find).

You have the CUCM generated calls a bit messed up. The best way is:

1. 44444 is a CUCM route point under the control of JTAPI, which sends a route request to ICM. Dialed number, call type scheduled script.

2. This two Send to VRU nodes. The first one will return the label (using my numbers above) plus correlation ID 8222222222xxxxx

3. This is a route pattern (with a wild card for the correlation ID) in CUCM that runs through the gatekeeper trunk and the gatekeeper sends that to a Call Server.

3. When the Call Server sends up a "new call" request, the system recognizes the correlation ID (and we have set it up so it's easy to find) and then ICM finds the script it paused at the Send to VRU, and starts it up again.

4. Now it hits the SECOND SendToVRU. It returns the label on the CVP routing client plus correlation ID 8111111111xxxxx to CVP. CVP asks the gatekeeper and the gatekeeper replies with the gateway.

5. The call goes to the gateway, hits the dialpeer 8T and starts the bootstrap.

Regards,

Geoff

[bilalghayad]

Dear Geoff;

We are closing to fix it

Why I am not originating from the Voice Gateway, because we did not get until now the E1s.

Also, I did not do any settings for the setTransferLabel and the correspondng exclusions.

I did almost as u mentioned (but I used my DNs and Lables .. but same logic, so the call originated from the Extension and routed to the ICM via the CTI route point).

Using the "debug voip dialpeer all" at the voice gateway, I am getting an "HTTPC-6-CONNECT_FAILED" as follwing (so, what could I be missing?, in the ICM script, I set the IP address of the VXML Server and the port 7000, also I am trying to run the HelloWorld which come by default and I was able to run it from the web browser using the http and then i hangup also using the http), but I am getting the below error at the voice gateway:

000204: *Dec 22 00:56:16.443: %HTTPC-6-CONNECT_FAILED: The connection to server 0.0.0.0 failed
000205: *Dec 22 00:56:16.443: %HTTPC-6-REQUEST_FAILED: request URI http://isn-vxml:8000/servlet/isn?MSG_TYPE=CALL_NEW&CALL_DNIS=DNIS=4519910080&CALL_ANI=2009&ERROR_CODE=0&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=CALLID=009A3257EDFC31D80A005602C0A86A95 failed
000206: *Dec 22 00:56:16.447: %HTTPC-6-CONNECT_FAILED: The connection to server 0.0.0.0 failed
000207: *Dec 22 00:56:16.447: %HTTPC-6-REQUEST_FAILED: request URI http://isn-vxml:8000/servlet/isn?MSG_TYPE=CALL_NEW&CALL_DNIS=DNIS=4519910080&CALL_ANI=2009&ERROR_CODE=0&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=CALLID=009A3257EDFC31D80A005602C0A86A95 failed
000208: *Dec 22 00:56:16.447: %HTTPC-6-CONNECT_FAILED: The connection to server 0.0.0.0 failed
000209: *Dec 22 00:56:16.447: %HTTPC-6-REQUEST_FAILED: request URI http://isn-vxml:8000/servlet/isn?MSG_TYPE=CALL_NEW&CALL_DNIS=DNIS=4519910080&CALL_ANI=2009&ERROR_CODE=0&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=CALLID=009A3257EDFC31D80A005602C0A86A95 failed

The below snap shot giving also what I see at the VBrowser:

By the way: currently I am hearing the error voice message that is generated from the CVP Call Server (actually this is shown in the attached picture of the VBrowser).

Below is the details of the debug of the dialpeer at the voice gateway for more details if needed:

VIVADRVG1#
VIVADRVG1#
000172: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Calling Number=2009, Called Number=4519910080, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
000173: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Match Rule=DP_MATCH_INCOMING_DNIS; Called Number=4519910080
000174: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:
   Is Incoming=TRUE, Number Expansion=FALSE
000175: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchCore:
   Dial String=4519910080, Expanded String=4519910080, Calling Number=
   Timeout=TRUE, Is Incoming=TRUE, Peer Info Type=DIALPEER_INFO_SPEECH
000176: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/MatchNextPeer:
   Result=Success(0); Incoming Dial-peer=45199 Is Matched
000177: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:exit@5489
000178: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=45199
000179: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerSPI:exit@6038
000180: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Calling Number=2009, Called Number=4519910080, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
000181: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Match Rule=DP_MATCH_INCOMING_DNIS; Called Number=4519910080
000182: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:
   Is Incoming=TRUE, Number Expansion=FALSE
000183: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchCore:
   Dial String=4519910080, Expanded String=4519910080, Calling Number=
   Timeout=TRUE, Is Incoming=TRUE, Peer Info Type=DIALPEER_INFO_SPEECH
000184: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/MatchNextPeer:
   Result=Success(0); Incoming Dial-peer=45199 Is Matched
000185: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:exit@5489
000186: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=45199
000187: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerSPI:exit@6038
000188: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Calling Number=2009, Called Number=4519910080, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
000189: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Match Rule=DP_MATCH_INCOMING_DNIS; Called Number=4519910080
000190: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:
   Is Incoming=TRUE, Number Expansion=FALSE
000191: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchCore:
   Dial String=4519910080, Expanded String=4519910080, Calling Number=
   Timeout=TRUE, Is Incoming=TRUE, Peer Info Type=DIALPEER_INFO_SPEECH
000192: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/MatchNextPeer:
   Result=Success(0); Incoming Dial-peer=45199 Is Matched
000193: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:exit@5489
000194: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=45199
000195: *Dec 22 00:56:15.431: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerSPI:exit@6038
000196: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Calling Number=2009, Called Number=4519910080, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
000197: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Match Rule=DP_MATCH_INCOMING_DNIS; Called Number=4519910080
000198: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:
   Is Incoming=TRUE, Number Expansion=FALSE
000199: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchCore:
   Dial String=4519910080, Expanded String=4519910080, Calling Number=
   Timeout=TRUE, Is Incoming=TRUE, Peer Info Type=DIALPEER_INFO_SPEECH
000200: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/MatchNextPeer:

VIVADRVG1#Result=Success(0); Incoming Dial-peer=45199 Is Matched
000201: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpMatchPeertype:exit@5489
000202: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=45199
000203: *Dec 22 00:56:15.435: //-1/009A3257-EDFC-31D8-0A00-5602C0A86A95/DPM/dpAssociateIncomingPeerSPI:exit@6038
000204: *Dec 22 00:56:16.443: %HTTPC-6-CONNECT_FAILED: The connection to server 0.0.0.0 failed
000205: *Dec 22 00:56:16.443: %HTTPC-6-REQUEST_FAILED: request URI http://isn-vxml:8000/servlet/isn?MSG_TYPE=CALL_NEW&CALL_DNIS=DNIS=4519910080&CALL_ANI=2009&ERROR_CODE=0&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=CALLID=009A3257EDFC31D80A005602C0A86A95 failed
000206: *Dec 22 00:56:16.447: %HTTPC-6-CONNECT_FAILED: The connection to server 0.0.0.0 failed
000207: *Dec 22 00:56:16.447: %HTTPC-6-REQUEST_FAILED: request URI http://isn-vxml:8000/servlet/isn?MSG_TYPE=CALL_NEW&CALL_DNIS=DNIS=4519910080&CALL_ANI=2009&ERROR_CODE=0&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=CALLID=009A3257EDFC31D80A005602C0A86A95 failed
000208: *Dec 22 00:56:16.447: %HTTPC-6-CONNECT_FAILED: The connection to server 0.0.0.0 failed
000209: *Dec 22 00:56:16.447: %HTTPC-6-REQUEST_FAILED: request URI http://isn-vxml:8000/servlet/isn?MSG_TYPE=CALL_NEW&CALL_DNIS=DNIS=4519910080&CALL_ANI=2009&ERROR_CODE=0&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=CALLID=009A3257EDFC31D80A005602C0A86A95 failed

Regards

Bilal

[bilalghayad]

I need to declare some points that might help to troubleshoot the problem:

The call steps now as following:

I am calling 44444 which is the CTI route point that is associated with the JTAPI link, the ICM is triggered and return the lable 40000 + Correlation ID, the CUCM consult with the gatekeeper and gatekeeper returns the IP address of the CVP Call Server, the Call transferred to the CVP Call Server and it come back to the ICM script which returns the lable 45199 + Correlation ID to the CVP Call Server, the CVP Call Server consult the gatekeeper and the gatekeeper returns the IP address of the Voice Gateway, the Call is sent to the voice gateway and it triggers the dialpeer 4519T and here the error is happening.

A the ICM script, still I do not see it pass the Send to VRU node (it fails), but I see the call touches the dialpeer as I mentioned.

Below is my dial-peer configuration and the vru-leg configuration:

dial-peer voice 45199 voip
description *** VRU Leg ***
translation-profile incoming block
service vru-leg
voice-class codec 1
incoming called-number 4519T
dtmf-relay rtp-nte h245-signal h245-alphanumeric
no vad

service vru-leg flash:bootstrap.tcl
  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en
service vru-leg

Also, I checked at the flash and I saw he bootstap.tcl is existed.

Please, if possible to help.

Thanks in advance.

Regards

Bilal

[Amer rajai Sha'er]

Hello Bilal,

I can see in the http request that you are using name , not ip , did you configure the host on the gateway .

It should be like this :

ip host isn-vxml X.X.X.X

Also did you make the configuration for the caching on the vxml gateway,

There is another thing you need to worry about is the time , the vxml gateway should have the same time as the vxml server (10 seconds difference maximum).

Amer

[geoff · Accepted solution]

did you configure the host on the gateway .
It should be like this :
ip host isn-vxml X.X.X.X

Agreed - this should point to the Call Server.

But something is a bit strange here. In the early days of CVP 3.x (and prior to that with ISN), it was a requirement to have a mapping in the IP host table for isn-vxml. This had to be there to allow the H.323 call, sent back to the gateway after the switch leg was established to the CVP Voice Browser, to find the Call Server to start the VXML leg. The thinking was in those days that the Voice Browser and the Call Server could be on different machines.

But Cisco changed the way it worked in CVP 4.x, because they knew that most implementations had the Voice Browser and the Call Server running on the same machine, and they wanted the VRU leg to go back to the same box.

So they made the call coming back to the gateway to start the VRU leg tell the gateway where the Call Server was. No longer did you have to define

ip host isn-vxml a.b.c.d

and in fact, you did not want to do that because, if you have more than one Voice Browser, you would be sending the VXML requests to a different machine than that which started the switch leg.

You can see this in the comments at the top of bootstrap.tcl

# 23 Sep 2006 : Extract originating IP address from an incoming H323 call and use

# that as the call server to which the IVR leg will be sent.  This makes

# the H323 method consistent with the SIP method.  cvpserverhost now

# no longer needs to be specified for an H323 call.

#

It makes me wonder what versions are being used here. I guess I'll have to look at the thread again - but this looks like CVP 3.x - but that can't be with all the talk about Ops Console.

Maybe the CVP Voice Browser is not configured correctly. Does it have the config for the Call Server (AppServer)?

Regards,

Geoff

[bilalghayad]

Dear Geoff;

The CVP Call Server version is 7 no doubt in this.

Maybe ur question that, why I need to add the ip host isn-vxml 10.180.22.137 if the CVP Call Server is 7 and I am using VRU type 10, correct?

Well, I start beleive that there is something wrong in the Send to VRU and the dialplan that should be used in the Gatekeepr.

Let us agree on the following:

1) In the ICM script that I attached it, there is one Send to VRU node, and one Run Extern Script node. So maybe I have to have two  Send to VRU nodes? Because the first Send to VRU node will return the Label to the CUCM which will transfer the call to the CVP Call Server and then the second Send to VRU node will return a Label to the CVP Call Server which will cause the transfer to the Voice Gateway (that has the IOS VXML Browser), in that case, the call already came from the CVP Call Server via the second Send to VRU node, so it should be like this?

2) Or, I have to initiate the call from the Extension (which is IP Communicator register to the CUCM), and instead of routing via the CTI route point, let us do it via the Gatekeeper trunk which will send the call to the CVP Call Server, the CVP Call Server will send to the ICM script to trigger the script. Here, the Send to VRU node will return a Label to the Call Server which will cause a transfer for the Gateway (VXML IOS browser), and no need for second Send to VRU node at the ICM script, what do u think?

Or what could be a suggested solution?

Also, I am looking forward to be sure that my cach configuration and my time is correct?

Thanks in advance.

Regards

Bilal

[geoff · Accepted solution]

1) In the ICM script that I attached it, there is one Send to VRU node, and one Run Extern Script node. So maybe I have to have two  Send to VRU nodes? Because the first Send to VRU node will return the Label to the CUCM which will transfer the call to the CVP Call Server and then the second Send to VRU node will return a Label to the CVP Call Server which will cause the transfer to the Voice Gateway (that has the IOS VXML Browser), in that case, the call already came from the CVP Call Server via the second Send to VRU node, so it should be like this?

You should have two Send To VRU nodes to make it perfectly clear where the failure is, but it will still work without the second Send To VRU if your config was correct. The reason for this is as follows: ICM will do an implicit Send To VRU on the first Run External Script or Queue to Skill Group it encounters in the script if the call is not at the VRU.

I always put in explicit Send To VRU nodes. I'm sure we have had this conversation before.

If you don't have the second Send To VRU, your script will fail at the first Run Ext Script. But it will also fail at a Run Ext Script if the WAV file is missing or for come other reason - wrong format etc. You want an explicit Send To VRU so you can see if it passes that node. If it does not, it means one thing only - your set up is wrong.

So put the second Send To VRU in your script - the call will fail there because your setup is broken. You need to go over the configuration again. You made mistake in the Voice Browser config - you should not have to define the ip host entry. But now you need to look at the right place for the failure.

Dial peer traces are useless now - it's catching the right dial peer. Stop posting it.

Now I think you should be examining the Call Server trace. If the bootstrap VXML is coming to the Call Server (NEW CALL) but correlation ID parsing is wrong, it cannot proceed. Look at that trace.

2) Or, I have to initiate the call from the Extension (which is IP Communicator register to the CUCM), and instead of routing via the CTI route point, let us do it via the Gatekeeper trunk which will send the call to the CVP Call Server, the CVP Call Server will send to the ICM script to trigger the script. Here, the Send to VRU node will return a Label to the Call Server which will cause a transfer for the Gateway (VXML IOS browser), and no need for second Send to VRU node at the ICM script, what do u think?

It will make no difference. You will have the same error. The right way is to have the call appear first in ICM - that's why we use a route point to kick off the script. If you send it directly to the CVP Call Server you miss out on that.

But that's not your problem.

Regards,

Geoff

[bilalghayad]

Dear Geoff;

Two Send To VRU node and it hfails from the first one, but it also trigger the dialpeer at the voice gateway from the first Send to VRU node (actually the returned label from the first Send to VRU is going to be consulted with the Gatekeeper which will return the IP address of the Voice Gateway, and the dialpeer will be triggered ... but something abnormal is happening in the vru-leg which cause the fail).

At th CVP Call Server logs, the error is (DialogFailure StatusCode: 15 HTTP req) as following:

1682: 10.180.22.137: Mar 19 2011 20:52:30.694 +0300: %CVP_7_0_IVR-3-CALL_ERROR: Removing CALLGUID: 00E244E0BDED41D809006902C0A86A0B DNIS=4000010113 due to exception in CallNewHandler. (Client: 10.180.22.137) Received ICM DialogFailure response for new call request. DialogFailure StatusCode: 15 HTTP req: { CALL_ANI=2009, MSG_TYPE=CALL_NEW, ERROR_CODE=NONE(0), CLIENT_TYPE=ISN, CALL_ID=00E244E0BDED41D809006902C0A86A0B, CALL_DNIS=4000010113 } [id:3023]

About DNIS, I configured the maximum length to be 5, what else I have to do? To add the DNIS's it self? The Correlation ID is coming correct, and it is within the range of 10000 to 99999.

What I could be missing for the VBrowser to cause this error?

About Routing Clients, Labels, VRU Type: I do not think it has any problem as the Call is reaching to the CVP Call Server.

One more thing: Where I have to give the IP address of the media server that contains the wave files?

Appreciate the kindly help, if I am missing any config at the VBrowser and the Media Server.

Regards

Bilal

[geoff]

Two Send To VRU node and it hfails from the first one, 

The first one? Are you totally certain?

1. The first Send To VRU will return the label configured on the NVRU for the routing client - which is CUCM. This has nothing to do with the voice gateway, nothing to do with the Call Server yet, so how can it possibly go there? You must have something totally messed up in your system.

2. Please set up both of your labels to have a length of 10, as configured in the ICM tab of the Call Server. Make these labels quite different so you can clearly see where they go. Tell me what those labels are. I have on several occasions suggested that you use the Cisco recommendation of 8111111111 for the label on the CVP routing clients and 8222222222 for the label on the CUCM routing client.

3. The label on the CUCM routing client is returned to Call Manager. Call Manager has to do something with it. What can it do?

4. It should have a route pattern on 8222222222! to find the Call Server. None of this goes near a voice gateway yet.

Do you understand this part? When you call the route point from your IP Communicator and it returns the label to CUCM, you will see that number appear briefly on your IP Communicator. It will have the correlation ID appended. Do you see that?

ICM now pauses the script.  When the call comes back in through the Call Server, it will use the correlation ID to ask the Router to find the paused script and continue it. Now it will go onto the second Send To VRU and this is the one that will find the gateway.

 but it also trigger the dialpeer at the voice gateway from the first Send to VRU node (actually the returned label from the first Send to VRU is going to be consulted with the Gatekeeper which will return the IP address of the Voice Gateway, and the dialpeer will be triggered ... but something abnormal is happening in the vru-leg which cause the fail).

How is that possible? The returned label goes to Call Manager. It does not need to ask the gatekeeper. It has a route pattern to send it to the Call Server. It cannot do what you say.

What is this DNIS of 40000?

You need to get the NVRU transfer labels to be NOTHING like a real number in the system so it cannot be confused. That's one of the reasons Cisco suggested a number like 8111111111. There are no toll free numbers like 81T.

Don't confuse yourself by making the transfer labels look like numbers - not like extensions, not like route points, and not like PSTN numbers.

What is the number of the CUCM route point you are calling from your phone?

Regards,

Geoff

[geoff · Accepted solution]

I am calling 44444 which is the CTI route point that is associated with the JTAPI link, the ICM is triggered and return the lable 40000 + Correlation ID, the CUCM consult with the gatekeeper and gatekeeper returns the IP address of the CVP Call Server, the Call transferred to the CVP Call Server and it come back to the ICM script which returns the lable 45199 + Correlation ID to the CVP Call Server, the CVP Call Server consult the gatekeeper and the gatekeeper returns the IP address of the Voice Gateway, the Call is sent to the voice gateway and it triggers the dialpeer 4519T and here the error is happening.
A the ICM script, still I do not see it pass the Send to VRU node (it fails), but I see the call touches the dialpeer as I mentioned.

Ok I looked back at what you had written before. This is how I think it should all work.

1. On the ICM tab of the Call Server, the max DNIS length should be set to 10. That is the default. Have you changed this to 5?

2. The NVRU label on CUCM RC should be 8222222222

3. The NVRU label on all CVP RCs should be 8111111111

4. The route point 44444 is associated with JTAPI and is a dialed number in ICM mapped to a call type with a scheduled script

5. The script has two Send To VRU nodes. The first one has a Release off the X port, the second has an End off the X port.

6. The success port of the first Send to VRU leads to the second one, and the success port of the second leads to the CVP VXML setup for a microapp or for CVP VXML - Audium. I suggest a simple microapp to get started.

7. Call Manager has a route pattern for 8222222222! that sends the call to a Call Server. That's how I do it with SIP, and with H.323 it may be slightly different. Doesn't matter. You have to get the call to the Call Server.

8. The call 8222222222xxxxx arrives at the Call Server. It thinks it may be a new call, but when it checks for digits passed the 10th digit (configured as the max length of the DNIS) it finds extra numbers. What does this mean to the Call Server? It means there is a correlation ID, so it sends this up to the Router and the Router finds the paused script and resumes it.

When we see this DIALOG FAILURE event in the Call Server logs as you have shown, we know that the Router cannot deal correctly with the Dialog that was started at the first Send To VRU and it cannot find the script that was paused. This is almost certainly because of the correlation ID.

9. Now the script restarts. It encounters the second Send To VRU node. Now teh routing client is not CUCM, it is CVP so it returns a different label - it returns 8111111111+corr ID to CVP.

10. CVP consults the gatekeeper and the gatekeeper says to send it to the gateway.

11. The dial peer on the gateway is configured to catch 8111111111T and start the bootstrap and the VXML conversation.

Regards,

Geoff

[bilalghayad]

Dear Geoff;

Same as u said, the only difference in the Label. I am now changing them .. but same logic.

Call Manager has a route pattern for 8222222222! that sends the call to a Call Server. That's how I do it with SIP, and with H.323 it may be slightly different. Doesn't matter. You have to get the call to the Call Server.

* I am assigning the route pattern (which is in my case is 40000! to the GK Trunk instead of sending it direct to the CVP Call Server), could be the reason?

Regards

Bilal