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 Callback_Enter_Queue 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.

Control is passed temporarily from VoiceXML to a TCL application on the VoiceXML gateway.  The handoff failure is because the the TCL applications haven't been configured on that gateway.   Set them up as shown in the config guide and that error should be sorted.

Thank you Matthew, so for each queue that I use CCB with, I'll have to move
my queue "treatments" (messages, MOH, etc) into Studio apps is that how I'm
understanding this ? Has to stay in the Studio app to be tracked by the
CCB system....

Bill.

On Mon, Feb 25, 2013 at 8:30 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Matthew Reiter has created a new message in the forum "General Discussion
> - All Versions":
> -------------------------------------------------------------- The reason
> CCB requires that all calls go through Callback_Enter_Queue is that it
> needs to know about every call in CCB-enabled queues in order to accurately
> estimate queue times. If there are any calls that it doesn't know about,
> the estimated wait time will be lower than expected and so callers will be
> called back too soon.
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12353903or simply reply to this email.

Bill,       
           In CallbackEntry you can use the "qname" session var to read in what you set the value too in ICM.  So if you have two Routing scripts say one for "Sales" and one for "Billing". You would set the "qname" in ICM to "Sales" and in CallbackEntry you can interogate tha value of "qname" and route to the corisponding "QueueDefaults" element. thus having multiple QueueDefaults elements but only one being used at a time based on the "qname"   
See attached CCB CallbackEntry App Spec   

Attachments:

Bill,
From what I can tell the system does not Reserve the outbound trunks, that perameter only serves as a Max Limit as to how many calls the system will make at any one time. You should set this based on the AVG number of Idel ports you have available for making CCB's. One other thing you may want to take into consideration, I noticed from the posts above that you have a few files in your Queue Loop, make sure the Keepalive Interval is set for longer than the total duration of your wav files in the application being used for the QueueApp. 
Good Luck,
kristian
 

Is there a way to specifically block some nos and dnis patterns that prevent them from being offered CCB. I can definitely do it a scripting level. However wanted to see if it could be done before that.
Also how do you check the no of ccb calls queued in the system in ICM. I would like to check this vs the no of regular calls queued in the system.
Hemal


From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, February 26, 2013 9:58 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Mark Pareja in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: Re: New Message from Mark Pareja in Customer Voice Portal (CVP) - Gener

Mark Pareja has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Bill,
The Trunk Param is used by survivability to determin how to throtle the CCB calls as to not consume too many trunks. In my architecture I'm actually sending the CCB leg out a different egress Voice gateway with ded PSTN-LD trunks and a ded IP-LD (CUBE) trunks. As you know we ingess voice across 6 different PSTN VG's and each are built to support CCB. We do not use the built in mechanisim to throtle CCB calls so we have set the trunks param to 200, in theory that would equal a total CCB concurrent request capacity of 1200 (200x6). But our throtle mechanism is our WFM team, they insure that outbound teams have been transitioned to Inbound to help bring down the queue, and CCB has subsequently been activated.
One other thing to note we route 40-60k calls a day, when we activate CCB during high queue times we get an adoption rate of 40-50%. Plan ahead, instute reporting for the CallBack application, and provide customer education prior to releasing CCB into the wild.
In other words the trunks are not reserved, if the CCB call fails to route, CVP will count it as a failed attempt and dispose of it as "no trunks avaliable" if i remember correctly. CCB Keeps track of all the requests for a specified VG and insures that the # of concurrent Callback Requests do not exceed the Trunks param value. You can see how this could get very complicated very fast.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12395530 or simply reply to this email.

Hemal,  Use a translation rule on the ingress VG and set the action to block on the dialpeer. This will generate a Network rejection to your upstream carrier for the numbers supplied.    http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml#con11   There are some canned CVP reports for CCB that can be loaded into CUIC, you can always load up infomix db sdk and create a dsn and query the Reporting server DB yourself.  CVP Reporting Guide http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/cvp9_0/configuration/guide/CCVP_BK_RB4BC4B7_00_reporting-guide-cisco-unified-cvp.pdf

Mark,
Wouldn’t this reject the no period ? I want the no to come but just not be considered eligible for CCB, however can stay in queue and be connected to agent after waiting. I want to see if this could be done at VG level.
Hemal

From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Tuesday, February 26, 2013 11:37 AM
To: cdicuser@developer.cisco.com
Subject: New Message from Mark Pareja in Customer Voice Portal (CVP) - General Discussion - All Versions: RE: Re: New Message from Mark Pareja in Customer Voice Portal (CVP) - Gener

Mark Pareja has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Hemal,
Use a translation rule on the ingress VG and set the action to block on the dialpeer. This will generate a Network rejection to your upstream carrier for the numbers supplied.

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml#con11
--
To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12399811 or simply reply to this email.

Hemal,
In the ops console, you can set up which CCB phone numbers to allow and
which ones to disallow.
Just add it in there under System > Courtesy Callback.

To do that programmatically, you'd have to figure out where this info is
being stored.

All I know is that in the CallbackEntry app, the element named CallbackValid executes a ccb_servlet and comes back with element data specifying if the number is allowed to be called back. On 2/26/2013 12:09 PM, Cisco Developer Community Forums wrote: Hemal Mehta has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Cool.. I know there was something that could be set outside the script. This should be good. Do you know if internally this gets blocked at the CVP level ? Thanks, Hemal From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com] Sent: Tuesday, February 26, 2013 12:55 PM To: cdicuser@developer.cisco.com Subject: New Message from Janine Graves in Customer Voice Portal (CVP) - General Discussion - All Versions: Re: New Message from Hemal Mehta in Customer Voice Portal (CVP) - General D Janine Graves has created a new message in the forum "General Discussion - All Versions": -------------------------------------------------------------- Hemal, In the ops console, you can set up which CCB phone numbers to allow and which ones to disallow. Just add it in there under System > Courtesy Callback. To do that programmatically, you'd have to figure out where this info is being stored. -- To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12404792 or simply reply to this email. -- To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12405235 or simply reply to this email. -- Janine Graves