Solved: Re: CVP and configuration migration

bilalghayad · ‎02-28-2011

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

geoff · ‎02-28-2011

It takes about 5 minutes to add a Call Server to the Device Map. That's how I do it. I'm not even sure there is a migration of the Device Map when the IP addresses are changing. You can get really messed up with the Device Map if the IP addresses are changing - not worth the hassle.

5 minutes per server.

Nothing on the VXML server - your ICM script uses a keyword, correct? The voice gateway resolves the keyword, correct? Change where it points and teh new one is activated.

For the Call Servers, your SIP Proxy switches in the new ones.

This is about the easiest thing to do in UCCE/CVP.

Regards,

Geoff

View solution in original post

geoff · ‎03-01-2011

The Operation Consol is installed with the Call Server and H323 browser at the same machine.

What is this? An "all-in-one" in your lab? Or do you mean "Operations Console" is installed on 1 machine and "Call Server and H323 service (a.k.a. Voice Browser) on another machine? Where is the VXML server? Why don't you have two Call Server machines?

1) Adding Call Server: and this will require the CVP PG to be up?

Of course not. Just add it to the Device Map. It won't come fully operational if it cannot talk to the PIM, but you can add it.

If I have to add the CVP PG ....

What sort of PG is the CUCM PG? If it's a PG Generic you can also add the VRU PIMs for the CVPs.

lso, why not to run the icm setup again to set it via setup?

If your Routers are in production, you would not want to do it that way, but this is not the case for you. eh?

u told me not to run the setup to increase the number of PGs, and this to be done from the Registry (and u mentioned that there are two Registry Keys to increase the number of PGs). Really all what I see is one Registry Key to make the number of PGs to be 2 instead of 1, as u see in this picture. Is there any Registry key? Or this is the only one?

I said there are two keys - and there are. You need to look under RouterA\DMP\CurrentVersion\Devices and you will see them all. You need to change DeviceDisabled from 0 to 1 to match the enabled value you already found for each PG.

2) The VXML Server will not be reachable if the Call Server is not up?

Not so. If the VXML Server is running correctly, the Ops Console will say it is up. These are independent.

4) CVP Call Server does not register on the GK, correct? In other words, it communicate with the Gatekeeper in direct mode (no need for registeration)?

The H.323 service (Voice Browser) registers with the gatekeeper and the Call Server talks to the Voice Browser.

5) About the trunks that need to be established at the CUCM, just I need to understand what is the difference between adding Gateway and Gatekeeper and adding the trunk? In other words, when I am going to add a voice gateway, then why to add a trunk for that gateway?

To create a signaling path.

Regards,

Geoff

View solution in original post

geoff · ‎03-01-2011

I will have two call server machines, but this is the first machine. VXML Server on separated machine (and I will have two VXML Servers). But at this machine, when I installed the CVP Call Server, I selected Operations Consol, so they are installed on the same machine with the H323 browser.

This is not desirable. You should have 1 ops console and two combo boxes (running the Call Server and H.323 service, and the VXML server). You should not have 1 OpsConsole/Call Server, 1 Call Server, 2 VXML Servers. Ops Console runs another Tomcat and uses memory. Cisco don't like it on the Call Server.

Why did you do that?

As far as the VXML Server not being reachable ... is it running? Go onto the box and look at the log files in Cisco\CVP\VXMLServer\Tomcat\logs. Try to start the service manually using the services applet. Will it run? If it does run and the log file in Cisco\CVP\VXMLServer\logs\GlobalAdminLogger shows it started OK, then maybe your Device Map is not accurate. Check the logs in the ORM. Is it talking to the Ops Console OK.

Also I was mean the VXML Browser Gateway (which can be the same ingress gateway device), same thing as the Voice Browser?

Ah, please don't make up terms - you will confuse me.

Yes, there is the "Ingress Gateway" and the "VXML Gateway" and they can be colocated - and will be in a branch office deployment.

There is a "Voice Browser" running on the gateway - it renders the VXML it gets from the Call Server and VXML Server.

Prior to SIP, when it was all H.323, I often called this the "IOS Voice Browser" to differentiate it from the CVP Voice Browser - which was a real Voice Browser in the original ISN.

Clarity in expression, my friend.

Regards,

Geoff

View solution in original post

geoff · ‎03-02-2011

By the way: I did not give a license for the VXML Server, so maybe this effect? Because really I was not knowing that there is a Cisco License for the VXML Server.

Is this CVP 7.0(2)? You get a permanent 2 port licence by default until you put your real licence file in place - it will work out of the box. If it's CVP 8.0 you get a 30 port licence that lasts 30 days.

As I know that some customers does not have Operation Consol, how they work?

Not that I know of.

So, the configuration that we do it on the Operation Consol, it will be deployed on the corresponding servers (Call Server and VXML Server)? Where it can be found?

Look on the Call Server in the conf directory. Those files are pushed by the Operations Console. It's easy to see - make a change on the Ops Console and deploy again. Look at the date stamps - you will see a file that's just been pushed with your new values. Some changes require a restart of the Call Server, but the Ops Console will tell you if that's required.

Regards,

Geoff

View solution in original post

geoff · ‎03-02-2011

It is 7.0 and I have a batch fo reach 7.0(2). But with 7.0, I do not see any license file in the license directory. Shall I apply the batch?

You won't see one. That's how it is - 2 ports without a licence file. It's called evaluation mode. Look at the Tomcat log file - it tells you all this. I must say, you don't seem to investigate much. Show more initiative.

Patch away.

When I applied the license I have for the Call Server, the status now is partial. What does parital means?

Typically it means the ICM service is not up - from the other side, the PIM is not active. Is that so?

But how can I know the number of queuing and the number of self service I have? It is not menion.

There is NO difference between a queuing port and a self-service port when using a microapp. Be careful how you think of them.

To see how many CVP VXML ports you have, run status.bat from CVP\VXMLServer\admin.

Do I need also a license for media server?

What is a Media Server? Is it a web server that delivers WAV files over HTTP? There's your answer.

By the way, when I am going to upgrade the current Call Server, VXML Server, and Media Server: will I need new license or I can use the current license files for the old version?

Patching from CVP 7.0 to CVP 7.0(2) requires no relicencing.

Regards,

Geoff

View solution in original post

geoff · ‎03-03-2011

You will need a new licence file. If you have paid for support on CVP 3.x continuously since installing CVP 3.x (this was before UCSS) then you can get a new licence. You will have to open a TAC case to get this done, but it will work.

The number of Call Server ports can be seen through the Ops Console or through the diagnostic applet at http://:7000/cvp/diag

Regards,

Geoff

View solution in original post

geoff · ‎03-03-2011

Sorry - the diagnostic applet is on port 8000.

I get these numbers confused - VXML in CVP 3.x used to be on 8000 and they changed that to 7000 for CVP 4.x.

Regards,

Geoff

View solution in original post

Amer rajai Sha'er · ‎03-16-2011

Mar7aba Bilal,

Listen,

First of all change the zone prefix to forward to the H.323 ID not IP.

Can you please upload the showall output from the VBAdmin.

Amer

View solution in original post

geoff · ‎03-16-2011

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

View solution in original post

geoff · ‎03-19-2011

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

View solution in original post

geoff · ‎03-19-2011

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

View solution in original post

geoff · ‎03-19-2011


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

View solution in original post

geoff · ‎03-19-2011

Maybe, the Send to VRU does not return success unless the call reach to the Voice Gateway (IOS browser) and come back successfully to the CVP Call Server to resume the script?

The first Send To VRU must be succeeding. Otherwise it could not have resumed the script to enter the second Send To VRU node, which is returning 8111111111xxxxx to the Call Server which sends it to the gateway.

The script is being paused and resumed twice. At the first Send To VRU, then again at the second Send To VRU. The Router trace will show this. I think the first is succeeding and the second is failing. Can you show me a screen shot of the script in monitor mode?

Regards,

Geoff

View solution in original post

geoff · ‎02-28-2011

It takes about 5 minutes to add a Call Server to the Device Map. That's how I do it. I'm not even sure there is a migration of the Device Map when the IP addresses are changing. You can get really messed up with the Device Map if the IP addresses are changing - not worth the hassle.

5 minutes per server.

Nothing on the VXML server - your ICM script uses a keyword, correct? The voice gateway resolves the keyword, correct? Change where it points and teh new one is activated.

For the Call Servers, your SIP Proxy switches in the new ones.

This is about the easiest thing to do in UCCE/CVP.

Regards,

Geoff

bilalghayad · ‎03-01-2011

OK Geoff; Fully thanks.

The Operation Consol is installed with the Call Server and H323 browser at the same machine.

Is the below sequantial is correct:

1) Adding Call Server: and this will require the CVP PG to be up?

If I have to add the CVP PG, then I have to go for the RGR and increase the total PG to be 2 instead of the currently is 1. But as u remember before, u told me not to run the setup to increase the number of PGs, and this to be done from the Registry (and u mentioned that there are two Registry Keys to increase the number of PGs). Really all what I see is one Registry Key to make the number of PGs to be 2 instead of 1, as u see in this picture. Is there any Registry key? Or this is the only one? Also, why not to run the icm setup again to set it via setup?

2) The VXML Server will not be reachable if the Call Server is not up? Because currently is giving me that the VXML Server is un reachable, although I installed the VXML Server. Any thing need to be done on the VXML or it is required that Call Server to be up?

3) I do not see in the Operations Consol any thing related to the VXML browser, well: how CVP Call server will communicate with the VXML Voice Gateway?

4) CVP Call Server does not register on the GK, correct? In other words, it communicate with the Gatekeeper in direct mode (no need for registeration)?

5) About the trunks that need to be established at the CUCM, just I need to understand what is the difference between adding Gateway and Gatekeeper and adding the trunk? In other words, when I am going to add a voice gateway, then why to add a trunk for that gateway?

Example:

For the CVP Call Sever, we add it at the CUCM as a gateway but we do not add a trunk for it, but for the Gatekeeper: we add it as a gatekeeper in the CUCM and we add it as trunk, why?

Appreciate the kindly advise.

Regards

Bilal

geoff · ‎03-01-2011