Showing results for 
Search instead for 
Did you mean: 

Courtesy Callback Configuration

HI All

Has any one successfully configured ccb for CVP 8.0? I have been following the admin guide but I hit an issue where you are meant to configure the survivability tcl script. When I try to enter the ccb param I get the following error each time:

HQ(config-app-param)#param ccb id:;loc:test;trunks:24
Warning: parameter ccb has not been registered under survivability namespace

When you do a show run I can see the configuration but I am concerned it is not doing anything. I have completed the rest of the configuration but when I make a call the call just gets hold music played. You do not get any offer for a call back just continuous MOH. 

I am using IOS version c2800nm-ipvoicek9-mz.151-3.T1.bin

Any advice greatly appreciated.



Not sure it's an error. For example, if you configure CVP stand-alone and change one of the params there for the name of the server (primary or backup), the port or the name of the app it will complain like that.

I have not tried Courtesy Callback - not yet.




I understand that this is a rather old thread, but I ran into this issue despite having the Survivability configured properly. 

I received the same error 

alidate_01,element,warning,addXmlBody - Error returned from probe

For those that have confirmed that your Survivability is configured properly and yet receive this error, check your sip configuration under voice service voip. 

The documentation clearly states that you will need to configure signalling forward to unconditional, but an unclear setting is "header-passing" which in hind sight is pretty obvious, but in my case, the sip service under voice service voip did not have header-passing enabled as shown below and resulted in the same error discussed here. 

Anyhow, for those running into this situation, hope this helps.... Cheers ! 

voice service voip

!!!!!! omitting parts that are irrelevant to the discussion !!!!! 

 signaling forward unconditional




As Geoff already hinted, this is not an error, don't worry about it, as long as you see the line in your config you should be ok.

Specifically for these ccb values, you could run a 'debug ccsip messages' or sniffer capture on your ingress gateway and check that the ccb parameters are sent on to the Call Server in the outgoing INVITE to make sure it's configured ok.

I do have Courtesy Callback running in the lab, the configuration is indeed quite elaborate, but once it's all up and running it seems to work fairly straight forward / reliably.


Hi Kris

Thanks for this and good to hear some one has it working. At the moment when a call is in queue it hits the VXML application but all I hear is queuing no other prompts. I think it is failing in the VXML apps as the queueing seems to be the default behavior. What is the best logs to check to debug the VXML apps? Ill check the logs you mentioned as well. Is there any issues that you faced when trying to get it working?

Thanks for your help,



Did you ever figure this out? I have experiencing the same issues. They call goes to queue but never gets flagged as eligible for call back treatment. I suspect something is going wrong in the Validate_1 element in the CallbackEntry app. I am seeing this error in the log and the element takes the error exit node.,05/03/2011 17:55:42.388,Validate_01,enter,,05/03/2011 17:55:42.404,Validate_01,custom,Callback_Validate,ELEMENT_ENTRY,05/03/2011 17:55:42.451,Validate_01,custom,Callback_Validate,ELEMENT_ENTRY,05/03/2011 17:55:42.451,Validate_01,element,warning,addXmlBody - Error returned from probe,05/03/2011 17:55:42.451,Validate_01,exit,error


Did you find the solution?



were you able to sort it out? we are also facing the same issue. as soon as we call it goes to the queue and plays the music. the call never gets eligibel for callback.




Hi Chuck,

I hope you are doing fine. I am getting the same behavior using CVP9.0. The call goes to queue but never prompts for call back treatment.

Did you figure this out.

Please help.


Thank you



Muhammad Fahad Raza


I'm getting that same line:

17:55:42.451,Validate_01,element,warning,addXmlBody - Error returned from probe

Did anyone ever figure out what is going on? The documentation doesn't help, there's nothing in the Bug Toolkit on it that I can see, and I can't search TAC cases.


My issue was I didn't have the survivability script enabled on my POTS dial-peer. If that script is not invoked at the beginning of the call the CC won't work.


I am trying to get this working and although I believes its configured properly the Validate steps always give a 'refresh' instead of going to preemptive.  I changed the SetDefaultQueue node... has anyone else experienced this and found a resolution?




Ensure that your call originates on a POTS line. Either an analog port or a T1/PRI port. This doesn't work with CUBE/SIP trunks or calls that originate from UCM. Also make sure that your gateway is invoking the survivability script on the DNIS your call originates on. Finally make sure that you didn't miss a step in the sample call flows. For instance the Expected Wait Time Calculation. Make sure that is making it to the VXML server.


Well thats crap then if it doesn't work on SIP trunks.   Why even release this feature set?

Cisco is this because CREATE CONNECTION in TCL doesn't work on VoIP to VoIP legs?  How about just fixing the limitation instead so I can release my On Call system and call back works on SIP Trunks...

This is like releasing a calculator that doesn't work with decimal places....

Thanks for taking the time to respond dzam!




FYI, I have traced out my problem to that the qname parameters passed into CallbackEntry and the Queue Name in Callback entry must match.  I have survivability running on an incoming SIP Peer just fine, and am able to successfully schedule a callback and record my name at this point.  Now I will begin troubleshooting the outbound portion.



Content for Community-Ad