Studio Callback sample error "no Gateway Address defined"

[Quigath]

I have been going through tutorials to set up the Cisco sample callback application. So far my ICM script is working and I can get it to hit the CallbackEntry script. However, it is failing at the Validate_01 element, here is the activity log:

10.10.90.9.1529430041672.92.CallbackEntry,06/19/2018 10:40:46.501,Validate_01,element,warning,"Error: no Gateway Address defined" returned from sending Callback_Validate request to CallbackServlet

Looking at the code in Validate.java on line 444, this error is sent due to httpClient.getXMLReturnStatus(); not returning "success" as the http result. The httpClient status code looks to still be 200 at this point so I think the url it has is correct.

Wondering if there's some server config or routing that I missed in order to get the correct gateway address. I'm not actually sure what the value is or what it's supposed to be.

For reference, the _ccbServlet parameter is:

10.10.90.9.1529430041672.92.CallbackEntry,06/19/2018 10:40:41.672,,start,parameter,_ccbServlet=http://10.10.90.9:8000/cvp/CallbackServlet

Can anyone help with this?

[Quigath]

Make sure you call in from an external line so it hits the CUBE and not UCM.

Recheck your setup of CCB - https://community.cisco.com/legacyfs/online/legacy/2/2/8/86822-Courtesy Callback quick configuration steps 1.1.pdf
This must have something to do with my CUBE. After I reboot it, my CCB script works perfectly.

[carlos.trivino]

Hi there,

I'm having this issue too. And that happens when in Configuration Manager I defined a new Network VRU Script because the initially defined had a short time out (600 seconds only). The new one aligns with the CCB configuration steps provided by Cisco:

The old one is this:

If I use the CVP_VXMLSEVER one with Courtesy Call Back the validation passes:

172.31.14.53.1742833301735.95.CallbackEntryIVRCustom,03/24/2025 12:21:41.751,VALIDATE_QUEUE1,custom,Callback_Validate,ELEMENT_ENTRY

172.31.14.53.1742833301735.95.CallbackEntryIVRCustom,03/24/2025 12:21:41.751,VALIDATE_QUEUE1,custom,probe outcome,id:<Proper IP is Returned here>;loc:GDC;trunks:20

 But if I use the new one VXML_Server_Interruptable, I'm getting this error:

172.31.14.53.1742832426119.90.CallbackEntry,03/24/2025 12:07:17.853,CB_VALIDATE_1,custom,Callback_Validate,ELEMENT_ENTRY

172.31.14.53.1742832426119.90.CallbackEntry,03/24/2025 12:07:17.853,CB_VALIDATE_1,custom,probe outcome,

172.31.14.53.1742832426119.90.CallbackEntry,03/24/2025 12:07:17.869,CB_VALIDATE_1,element,warning,"Error: no Gateway Address defined" returned from sending Callback_Validate request to CallbackServlet

So I wonder if there is some configuration in the CUBE that makes direct reference to the Network VRU Script being used by the 'Run External Script' node in the ICM script that invokes the CallbackEntry CVP script and that's the reason for the failure.

Any help is appreciated.

[bill.king1]

A couple questions:

* Did you make any changes to the ECC variables when you did your new Network VRU script?
* Are you using VVB or VXML gateway?
* Can you share your CUBE config?
* Is it the same inbound number you're dialing to test with (i.e. 2125551234 goes to working script, but if you reroute 2125551234 to go to new script, it doesn't work)? 

[carlos.trivino]

Thanks for your reply Bill.
* Did you make any changes to the ECC variables when you did your new Network VRU script?
R: No, not changes were made to the ECC variables.

* Are you using VVB or VXML gateway?
R: I'm using VVB.

* Can you share your CUBE config?
R: I do not have access to the CUBE config.

* Is it the same inbound number you're dialing to test with (i.e. 2125551234 goes to working script, but if you reroute 2125551234 to go to new script, it doesn't work)?
R: No, the DID I'm testing with is different. And that is the issue. I pointed the DID that works to my new script that uses the new Network VRU I added in Config Manager and now it works!!! So it means that there is some configuration required somewhere (in the CUBE maybe ?? ) that allows DIDs to be used for CCB. I'm not a CUBE expert but I remember from the days where the initial CCB configuration was done that we had this same problem.

Thanks for pointing this out Bill, it truly helps me to determine what the issue was.

Many thanks!!

Regards,

Carlos Trivino

[bill.king1]

Yes, the dial peers contain the probe information/survivability that is used, there's some documentation about it here. Some number A that works has it, and number B didn't, which is why you got that error.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/cvp_12_6/ConfigurationGuideCVP12_6/guide/ccvp_b_1261-configuration-guide-for-cisco-unified-customer-voice-portal/ccvp_m_1252-system-configuration.ht...
Please rate helpful posts/mark as solution when appropriate. 

[Elliot Dierksen · Accepted solution]

The gateway based TCL scripts for CCB must be invoked when the inbound call hits the CUBE. It changes the caller ID when it does this, so that confuses people if the script is invoked for calls that are not delivered to CCE. Where I have done it, there was an E164 pattern map in the CUBE for numbers that go to CCE so the TCL script is only invoked for calls where it is required. I think that @bill.king1 is correct when pointing you towards the CUBE as the source of the issue.

[carlos.trivino]

Thanks Elliot, yes, the DID that was failing is now configured to use the ‘cvp-survivability’ service on the CUBE and now my calls are working as expected. Problem solved!!!

Many thanks for all the help.