CVP Comprehensive with SIP Proxy
Voice Gateway + VXML Gateway Cisco 2821 Version 12.4
The test is done from an IP Phone.
The call hit the Gateway, remains connected but nothing is played because the Media Server Ip Address is empty on the URL, despite the fact that we put it in the ICM script as a variable, before the "Send to Vru" Node...
Please find attached a screen shot of the ICM script, as well as of the Gateway!!
*Apr 8 06:52:19.572: %HTTPC-6-REQUEST_FAILED: request URI http://:8000/cvp/VBServlet?MSG_TYPE=PING&CALL_DNIS=8111111111136&CALL_ANI=9701&ERROR_CODE=0&RECOVERY_
*Apr 8 06:52:19.580: %HTTPC-6-CONNECT_FAILED: The connection to server 0.0.0.0 failed
Thanks for your help,
I will check the obvious with you, but I would recommend engaging eventually TAC on similar issues.
Since you are running 4.0.2, please confirm that you have copied the latest files into GW flash from following folder:
and reloaded the application.
Please confirm IP Connectivity between the GW and the Media server works fine, ping and so on.
Confirm you do not see any CPU spike or excessive memory usage that would cause the VRU leg to fail.
Confirm that the CVP Voice Browser is defined as a gateway in Call Manager.
In Call Manager CCMAdmin, go to Device->Gateway and make sure there is a
gateway that contains the IP address for the CVP Voice Browser.
If none of this fails, you would need to collect at least the latest set of VB and Application Server logs and the GW logs with the following debugs:
debug CCSIP all -
debug voip application script -
debug voip application vxml all
And raise a TAC SR with them.
Riccardo is correct to make sure to download the latest files from C:\Cisco\CVP\OPSConsoleServer\GWDownloads\_CVP_4_0_2_0_0_0_40 .
I ran into a problem where I downloaded an early posting of 4.0.2 which had the 4.0.1 versions of these scripts. You can check the version by looking at bootstrap.tcl. The version should be 4.0.2.
The 4.0.1 version of the script caused the problem you described.
Riccardo and Kevin,
Your advice is incorrect.
When the 4.0(2) service release is applied to CVP 4.0(1), the bootstrap.tcl and bootstrap.vxml files are updated in the correct directory - C:\Cisco\CVP\OPSConsoleServer\GWDownloads.
What is copied into the sub directory under that are the old versions of those files. That's how the service release can be rolled out. They all work the same way. Otherwise, how would an uninstall work?
It's easy to check of course - just open bootstrap.tcl in each directory and check right at the top.
It should say:
# Script last modified by glgerhar
# Script Version: 4.0.2
The old one will say:
# Script last modified by jbyron
# Script Version: 4.0.1
THANKS to the 3 of you for your reply!!
I checked it and you were right for the 2 files, and it wasn't my issue.
HOWEVER, checking it fixed my issue :))
We realized that while looking inside the "bootstrap.tcl" file, there was a parameter in the bootstrap service that we didn't setup (and btw it was not in my CVP book or CVP Lab guide!!):
param cvpserverhost callserver1
So we just added it, as well as:
ip host callserver1 10.122.12.36
It makes sense obviously, and it's all working fine now :))
happy it got fixed in your media kit, there was a bug as per the newer files were not copied when the system was upgraded from 4.0.1 to 4.0.2 and those files had to be copied over.
Looks like the new mediakits are addressing this, I have no clue when this was fixed hence our suggestion to Dimitri, I was hit twice by this...
OK Riccardo - I did not know of the bug.
But I had made a mistake in the past with upgrading an existing system and not putting up the right bootstrap files on the gateway. So I am sensitive to that area.
The real way to be sure is to look at them on the gateway with "more flash:bootstrap.tcl".
But I am a little surprised here. Dimitri, that parameter is not required. It was at one stage, but now extracted from the call and given to bootstrap.vxml. You can see that in the comments at the top of the TCL file.
You do NOT need to specify the location of the Call Server for the VXML leg. It will automatically go to the same Call Server that started the switch leg.
In the older 3.x product, the TCL script looked for isn-vxml and that had to be in your ip host table. That's gone now. So I'm wondering if something else is amiss.