Courtesy Callback Probe Troubleshooting

[SEAN NILSEN]

Hi Everyone,

Is there a specific debug or logging level that enables lower-level troubleshooting of the "Validate" step that is in the CallbackEntry application prior to being offered CCB?

More specifically, we're facing an issue where "something changed" and we're not sure exactly where the problem lies after having been over the previously working config several times we're left in a state where the Validate step will ONLY return a value of NONE and there are no associated errors otherwise.

1. Is there a debug that can be run on the gateway to see the problem request/response?

2. Is there a logging level from the VXML side that will show this specific interaction?

3. Does anyone happen to know which JAR file the CCB elements live in?

Thanks in advance!

[SEAN NILSEN]

The answer to #3 is: cvp-vxml.jar

[janinegraves]

This happened to another student/customer - here's what they shared with me about how they had it resolved  (I'll try to get you more info):

"I opened Cisco TAC case: it turned out some defect in which records were not moving from current table to historical table. TAC ran some stored procedures to manually delete duplicate records and restarted reporting servers and it started working. Cisco does not know why it would have happened."

This is what they'd seen in their CallbackEntry activity logs:

1. 18:07:40.790,Validate_01,custom,Callback_Validate,ELEMENT_ENTRY
2. 18:07:40.790,Validate_01,element,warning,addXmlBody - Error returned from probe
3. 18:07:40.806,Validate_01,exit,error

[SEAN NILSEN]

Thanks Janine!

I didn't see that particular error, just getting the very helpful response of "none" from that Validate step.

TLDR; The logging around CCB is misleading and not well documented.

I know it's not supported for production but I've started down the path of extending that Validate element for dev/test to allow for some useful logging messages so that one might understand WHY a particular response is happening. As it stands, it's just not logging enough to be useful to troubleshooting when going off to the black hole of "the probe" and "the reporting server servlet."

The CVP reporting server logs were spitting back a status of 18, which translates to "ICM Not Allowed" according to TAC, I still can't find a published document with that noted anywhere. After a long circuit trying to find where in ICM this was happening, that status actually points to the Callback_Set_Queue_Defaults node in CCB, which has Time of Day settings, and those were outside of the current system time.

[sadswami]

Even I am facing same issue. I am using 2 different CUBE for 2 locations. For one location its working fine with same config on non working CUBE.I have set Callback_Set_Queue_Defaults value to allow callback 24 hours as below.

Sunday=0:0:0 - 23:59:59
Monday=0:0:0 - 23:59:59
Tuesday=0:0:0 - 23:59:59
Wednesday=0:0:0 - 23:59:59
Thursday=0:0:0 - 23:59:59
Friday=0:0:0 - 23:59:59
Saturday=0:0:0 - 23:59:59

Still every time I am getting validation status as none.