cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10151
Views
5
Helpful
78
Replies

CVP and configuration migration

bilalghayad
Level 1
Level 1

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

78 Replies 78

This pic declare that I am using the GWVBVRU to be a default network VRU.

GWVBVRU, so could this effect? Remember that these configuration came from the production system because we are doing migration.

That's certainly wrong. You are using a Type10 - so that should be the default NVRU. That's your problem.

The Type 10 combines the Type 5 and Type 7, so that's all you need. Delete the GWVBNRU.

Get rid of the "Network Transfer Preferred" check mark too.

Regards,

Geoff

Dear Geoff;

But the GWVBVRU is my default NVRU as I told u. And this NVRU is type 10 as shown below and this GWVBVRU is the used one (and we are using its label). Do u think I have to remove the other NVRU as they might cause conflict?

Get rid of the "Network Transfer Preferred" check mark too.

* Really I tried to do a calls while this is not selected, but same result .. it did not effect.

I am trying to think from another side:

Why I have to give the ip host isn-vxml at the voice gateway? Assume the call came from another CVP Call Server, so why to use a fixed IP address? I think here is a problem !! Why not the Gateway knows the isn-vxml IP address from it self without need to give it as ip host? Maybe if we investigate this point, we will resolve the communication between the CVP Call Server and the Voice Gateway which cause the fail.

Maybe we need to concentrate on the below messages in the picture (I determined it by the red rectangle):

cmHookRecv: IVR call leg had some abnormal failures ...
CH323CallStat::ReceivedOutRLC: Engress endpoint/gateway ...

What is meant by: ReceivedOutRLC?

I am trying to look for this problem from two sides:

* A connection between the Voice Browser and the Voice Gateway, which is causing that the voice gateway is not able to find the IP address of the isn-vxml, while really giving it statically will not work if I have more than CVP Call Server ... What do u think?

* A configuration on the voice gateway that is causing the vru leg not to work fine? What could be?

Very thanks Geoff for the participation and this big help, I am also getting experience from you because really you are expert and Golden

Regards

Bilal

But the GWVBVRU is my default NVRU as I told u. And this NVRU is type 10 as shown below and this GWVBVRU is the used one (and we are using its label).

OK, the name confused me. You did not show me that picture before. That looks fine.

Let me ask you this. When you set up the applications on the gateway, did you load them?

Regards,

Geoff

Dear Geoff;

The tread become too much long and very loaded.

Let us continue in new thread and we can write here the link to reach for the other thread, or u have any suggestion?

Regards

Bilal

I am going to correct the labels as u mentioned.

But will answer for below:

1) I am calling from the IP Communicator the number 44444 which is a CTI route point mapped to the JTAPI link. And at the ICM, I have a DN via a the CUCM routing client which is 44444 and it is triggering the ICM script, OK?

2) The ICM script will return a Label to the CUCM (as the Call came from the CUCM), this label is 40000+Correlation ID, so in other words I have a label under the NVRU which is 40000.STC_CCMPG1.

3) At the CUCM, I have a route pattern which is 40000! and it is associated with the GK Trunk, so it consult with the GK and the GK returns the IP address of the CVP Call Server.

4) Yes at the IP Communicator, I see the 40000+Correlation ID (and I see vivadrcvp which is the h323id of the CVP Call Server that is shown at the Gatekeeper). So it means, I reached for the CVP Call Server and I see this in the VBrowser.

But, I do not see a success for the Send to VRU node (the first Send to VRU). And yes I have two Send to VRU nodes now (the success of the first one is connected to the second Send to VRU node). But I am not passing even the first one.

In other words, I dial 44444 and then I see in the IP Communicator the 4000010125 and I see this in the Voice Browser at the CVP Call server, but I do not see a success pass for the Send to VRU node. Also, at the Voice Browser, I see the 4519910126 which is the returned Label for the CVP Call Server (and in this Label, the CVP Call Server is the routing client), even I am not see any success for the Send to VRU node.

Regards

Bilal

As a proof:

At the CUCM, I removed the route pattern 40000! and I dialed from the IP Communicator, but did not reach to the CVP Call Server and did not see the returned Label 40000xxxxx at the IP Communicator. So this is a proof that I am getting the Label returned to the CUCM (as the call originated from the CUCM via the CTI Route Point which is 44444), OK?

Also I tried to do the route pattern to the CVP Call Server directly and the same problem (same as if I tried the route pattern via the Gatekeeper trunk), I reach to the CVP Call Server but I come back to the same problem. And at the Send to VRU, no success.

Yes, I did as u mentioned same. Except I am using difference Label.

Again, I am going to correct the Labels as u suggested to be easier for trouble shooting.

What I am trying to say that I get the Label returned to CUCM and I reach to the CVP Call Server (and this shown on the IP Communicator), also I am getting another Label returned to the CVP Call Server and then it hits the Voice Gateway dialpeer and the problem it happens.

I am now correcting Labels.

Regards

Bilal

Why don't you point the the label directly to the VXML gateway , there is no need to ask the gatekeeper

unless you have multiple gatways you want to load balance , i am sure you already added the vxml gateway as a h.323 gateway on the call manager , make sure that it has CSS in the gateway config.

Amer

amer_alshaer wrote:

Why don't you point the the label directly to the VXML gateway , there is no need to ask the gatekeeper

What label? The 8222222222! ? That has to go to CVP, not to a voice gateway. Since there are always 2 or more Call Servers, you want to have fault tolerance so it goes to the GK,

Regards,

Geoff

what i mean is the retuned label from the ICM script (send to VRU) it should be pointed to the VXML gateway.

We have two "Send To VRU" nodes with two different labels. One label on the CUCM RC and one on the CVP RC. Call Manager handles the first and CVP handles the second. The second goes to a gateway, that is true - and it consults the gatekeeper to do that. But the first goes to CUCM.

Please be specific. The original poster will be confused otherwise.

Regards,

Geoff

Dear Geoff;

We have two "Send To VRU" nodes with two different labels.

* Can we assign the Label for the node? I can not see this. What I see that I drag and drop it in the script.

By the way, I removed the ip host isn-vxml 10.180.22.137 from the Voice Gateway configuration, and I am getting the original error which is related to the Http connection error !!

Could be something in the Voice Browser that effect? Or something on the Voice Gateway?

Regards

Bilal

The label is determined by the NVRU label. The rule is this: the label returned is specificied by the routing client and the customer set on the original dialed number that started the script. Based on these two, it checks the NVRU configuration and simply returns the appropriate label, with a correlation ID appended.

The error for that isn-vxml thing must be because you have not configured the entry in the Call Server list on the Voice Browser. Why did you not set that?

Let's look at what the Router is doing. As I said, the error you noted in the Call Server regarding DIALOG FAILURE is coming from the Call Router. It simply cannot tie the two parts of the dialog together.

What do you see in the Router trace?

Regards,

Geoff

The error for that isn-vxml thing must be because you have not configured the entry in the Call Server list on the Voice Browser. Why did you not set that?

Mmm, I looked at the config guide and it does not mention setting this anymore. One had to do that with CVP 3.x. I am  a bit rusty on H.323 as I haven't done it for a few years now.

Regards,

Geoff

Dear Geoff;

Actually I was setting the command wrong, so now I typed it correctly:

SetCallServerList 10.180.22.137:8000/cvp/VBServlet

OK, I came back to the same problem ....

And still in the voice gateway, I see error which is related to the HTTP connect that previously I mentioned it.

Could be License?

Regards

Bilal

Actually I was setting the command wrong, so now I typed it correctly:

SetCallServerList 10.180.22.137:8000/cvp/VBServlet

Do you see the voice browser connected OK to the Call Server? The default is localhost:8000/cvp/VBServlet and you really aren't doing anything different to that. See page 335 of the Config Guide.

Let's put that to one side then. Go back to the gateway and enable the isn-vxml setting in the ip host table.

Now watch the Call Router. You need to see what it is saying.

Regards,

Geoff