on 01-25-2014 10:32 AM
Bill Westby:Finally have Studio and ICM apps working after figuring out a nice nugget where our cvp_dbuser on the reporting server had a "must change password at next login" and that was causng the servlet call to the reporting server to fail. I'm using bone stock Studio samples from the ops console examples. Call goes into CallbackEntry, and at the first Validate_01 throws an element error in the error log: 10.31.250.14.1361578511894.9.CallbackEntry,02/22/2013 18:15:12.315,A VoiceXML error occurred of type "error.com.cisco.callhandoff.failure". I am not able to program the gateway (single ingress and vxml combined), I'm having to rely on someone else to do that due to security (ugh). So does this error seem to indicate that it failed to retrieve what it needs from the gateway or possibly the gateway is not programmed correctly? Also one more question for now is this, the documentation says The <strong><strong>Callback_Enter_Queue </strong></strong>element is responsible for adding a new caller to queue. This element must be executedfor all callers even if the caller may not be offered a callback. And I'm wondering why? If a call isn't going to do callback why can't I just use normal treatment on it, I have to use Studio apps now for my queue treatments and messages ? Since my Callback Entry fails I see the call makes it to CallbackQueue app and just sits there playing their default MOH configured in the app. Obviously we do lots of custom messages for callers who stay in queue, do I "have" to use a Studio VXML app to keep the call in queue once I go down this road of using CCB? Thanks, Bill.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: