04-05-2011 10:30 AM - edited 03-14-2019 07:42 AM
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:172.16.1.2;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.
Matt
04-05-2011 06:36 PM
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.
Regards,
Geoff
01-11-2017 07:25 PM
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
sip
header-passing
04-11-2011 01:04 PM
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.
04-12-2011 01:07 PM
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,
Matt
05-03-2011 05:02 PM
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.
10.1.78.9.1304459741935.8.CallbackEntry,05/03/2011 17:55:42.388,Validate_01,enter,
10.1.78.9.1304459741935.8.CallbackEntry,05/03/2011 17:55:42.404,Validate_01,custom,Callback_Validate,ELEMENT_ENTRY
10.1.78.9.1304459741935.8.CallbackEntry,05/03/2011 17:55:42.451,Validate_01,custom,Callback_Validate,ELEMENT_ENTRY
10.1.78.9.1304459741935.8.CallbackEntry,05/03/2011 17:55:42.451,Validate_01,element,warning,addXmlBody - Error returned from probe
10.1.78.9.1304459741935.8.CallbackEntry,05/03/2011 17:55:42.451,Validate_01,exit,error
07-15-2011 03:39 AM
Did you find the solution?
02-02-2012 01:55 AM
Hi,
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.
regards,
Sandeep
02-20-2015 12:28 AM
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
Regards,
Muhammad Fahad Raza
10-05-2011 01:29 PM
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.
10-05-2011 01:32 PM
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.
11-26-2011 08:52 PM
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?
Thanks!
Chad
11-26-2011 09:22 PM
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.
11-27-2011 10:59 AM
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!
Cheers,
Chad
11-27-2011 01:31 PM
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.
Cheers,
Chad
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide