Bill,
First CCB is a difficult endeavor even more so in complex environments as your familiar with mine. But it sounds like your voice guy did not enable "signal forward unconditional" either on the CVP dial-peer or globally on your ingress VGA.

I have a lengthy write up on CCB I can share with you if you would like just shoot me an e-mail.

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.

Yes, put all your MOH and treatment into either the CallbackQueue app or the BillingQueue app. And if you have different treatment for different queues, then you'll probably want to modify the ICM script. Right now the ICM scrip uses SetVariable node to assign into the ToExtVxml array "qname=billing" - you'll want to change billing to your queue name. That way the CCB 'shadow' queues will more closely resemble your real queues. TheStudio app BillingQueue can check the Session data named 'qname' and play different MOH.

Hi Mark, long time no talk, good to see you here!! Finally got it working
tonight with standard PRIs which one group uses, other uses IB SIP which
I'm told is "acting like a CUBE" whatever the heck that means, time soon
will tell...IP originated doesn't work yet as well but tomorrow is a new
day of testing.

I've ventured deeper into the Studio apps and finally figured out what they
are doing and thank you, your advice and guidance worked well. Hate having
to use Studio to handle the queue treatment from now on, reminds me of IP
IVR days. Oh well, more work for me since nobody here knows Studio besides
me!

One question I'm hoping I can get answered is trunk reservation.... If we
"reserve" trunks with the "param ..." in the dial-peer, does IOS reserve
trunks for CCB purposes? Like if I reserve an entire PRI which is likely
the case given the call volume, does that essentially lock up a PRI for OB
usage? We reserve PRIs for inbound so that's not an issue, but for OB it
is. Worse case I can throw another PRI or two at CCB and reserve those for
CCB usage, just not sure how the trunk reservation works in IOS.

If you or anyone else has any thoughts I'd appreciate it. Cool feature how
they accomplished it I'll admit, but my CCB solution I wrote on 7.5 was a
whole lot easier using the OB dialer to hold the caller's place in queue
haha, didn't care about trunk type at all.

Thanks,
- Bill Westby

On Mon, Feb 25, 2013 at 12:42 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Mark Pareja has created a new message in the forum "General Discussion -
> All Versions":
> -------------------------------------------------------------- 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
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12365034or simply reply to this email.

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. 

Cisco CCB = Time Delayed CallBack not Virtual Hold 
Bucher and Suter have a real Virtual Hold solution that actually holds your place in line. Moving to evaluate thier offerings. 

Thanks Mark. Let me check.
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.

Great info, thank you Mark!

-Bill.

On Tue, Feb 26, 2013 at 7:57 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> 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/12395530or simply reply to this email.

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.

Hemal,
In the CallbackEntry app, after the element executes that determines if
the phone number is allowed to be called back or not, it's the app that
is branching and telling the caller that this is not a valid number to
callback. It's not the gateway blocking the call.

Now that we have CCB working with stock apps and PRIs only for now (thanks
to everyone who helped with that), I'm moving all the ICM queue treatments
into Call Studio since that is where the call has to be held.

I've hit a snag, an example is how do you test if reps are still logged
in? The ReqICMLabel element only provides PV values that I can tell,
anyone have thoughts on how I could query ICM skill group data from my app,
guess I could write a SQL query element against the DB directly and read
the agent and skill group real time tables?

Also we have global "Emergency" variables that are checked every queue loop
in case of evacuation so need to be able to check those as well..I guess
for that I could set those variables using a CVP app which writes the
current data to a local resource file and returns it to ICM as well.

Lastly, the RONA handling in the sample ICM script just disconnects the
call. So I enabled requery on the queue node and send it back to
CallbackQueue with the ECC CCB var set to "N" for the remainder of the
call, seems to work but just if anyone thinks that is not right, or not how
you did it, I'd like to hear about it.

Thanks again,

Bill Westby.


>
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12390220or simply reply to this email.

Yes, what Janine said... ;-)
I'm a big fan of the ReqICMLabel element, though using it in this fashion is not necessarily how it is designed to be used, according to Cisco on some other threads, BUT it does work.
Just remember the rules are the same, even though it might seem backwards. This is CVP sending a request to ICM (reverse of the norm), but the information from CVP to ICM is still passed in the FromExtVXML variable array, and information from ICM returned to CVP in the response is still in the ToExtVXML variable array. The cool thing, though, is that you can also get Call Variable information directly, and a "result" Element data with the ICM Label.
I've <ahem> "modified" the ReqICMLabel element to de-couple it somewhat from its intended use, so that I can set the request data specifically (DN, ANI, etc.), but I'd love to see this done more officially...
Hey Cisco, if you're listening - think of ReqICMLabel in CVP Comprehensive deployment like "Get Reporting Statistic" step in UCCX. Maybe create a new element with this in mind, or release the source code for this element so we can modify ourselves?

Janine and Bill,

Thanks for the replies. After much googling I found an old thread with
both of you involved in this exact topic :-) There was lots of talk about
only working with CVP Standalone until 8.5 but I have no reference any
longer as we are on 8.5

So I followed that thread and tried to get ReqICMLabel working but it was
failing to find a script for the DN which in my case turned out to be
SIGDIG + what I think was the correlation ID. So I found in that thread
that if I override _dnis in the ToVXML I could specifiy what DN I wanted to
invoke and execute my routing script to population PV1-10 and return to
CVP. Woohoo it worked.

For anyone who wants to give it a try I agree with Bill, I'm now a big fan
of the element, and here's what I did:

1) If needed override _dnis in ToVXML passed into CVP. You'll know if you
need to by first trying the element in one of your CVP applications then
check the Router Log Viewer in ICM when the ReqICMLabel fails to find out
what DN is being passed. Or you can check your activity log and see what
_dnis is being passed into your app by CVP.
2) Configure the DN (_dnis value) in ICM, need one for each CVP routing
client you have configured.
3) Create a call type for the DN and associate with the DN
4) Create a routing script that populates PV1-10 as needed, you can also as
mentioned populate the FromExtVXML and caller_input vars, keep in mind the
PV vars are two way, you can pass data to your routing script and use that
to determine what to do. So you could use the same DN for multiple
applications and pass for example in PV1=<ID> and then in your routing
script test If PV1=<ID> do this else do that...
5) Associate the call type in call type manager with the routing script.
6) Very important, the last node in your ICM script should be a label/ I
used a dynamic one and just returned "BACKFROMICM" since I don't really
care what the label is.
7) Use ReqICMLabel in your Studio app, populate call vars 1-10 and when
your routing script starts in ICM you can test the values and make further
"if" routing decisions, then populate call vars 1-10 and return them to
CVP. Note that you have to hard code the element data in ReqICMLabel on
the return, why they don't make it available in the drop down boxes is odd,
but it works if you follow the examples in the Element Specification Guide
for CVP 8.5.

THANKS!!!

Bill Westby.

On Fri, Mar 8, 2013 at 11:21 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Janine Graves has created a new message in the forum "General Discussion -
> All Versions":
> -------------------------------------------------------------- Be careful
> with ReqIcmLabel element - it will affect your ICM reports
> because this element causes a request to ICM that looks like another
> 'NewCall' for the original dialed number.
>
> And that's where I think Cisco should enhance this element - decouple it
> from the original DNIS. Then it would be very useful!
>
> FYI - ReqIcmLabel element can configure the Settings to populate the 10
> PVs and the FromExtVxml and the caller_input veriables (that's a lot of
> data you can send from VxmlServer to ICM).
>
> And ICM can modify the PVs (assign a new value) and they will become
> element data for the ReqIcmLabel element (called callvarReturn1, 2, 3,
> etc).
>
> ICM can also populate the ToExtVxml array with semi-colon separated
> name=value pairs, these will become Session data with those names/values.
>
> ICM ends with Label node, and that value also becomes element data
> called 'result' for the ReqIcmLabel element.
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12799975or simply reply to this email.

Allow me to give proper credit, here is the thread :
http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/5400484

Paul Tindall discovered that nugget. Now everyone "ssshhh" so they don't
take it away LOL :-)

Bill.

On Mon, Mar 11, 2013 at 8:54 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Janine Graves has created a new message in the forum "General Discussion -
> All Versions":
> -------------------------------------------------------------- Thanks for
> posting a complete overview of how you made it work!
> And I did NOT know that you could override the _dnis and get a different
> ICM script to kick off! That's great news and I will definitely pass it
> along to my students. Now, ReqICMLabel is a VERY useful element!
>
> Hooray for the forum allowing us to pool all these fragments of knowledge
> into a very useful body of knowledge!
>
>
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12879416or simply reply to this email.

Paul,That would be great! Wish you could help with more of the things I don't know - like does the vxml gateway hold the 'disconnect' event until it gets the next vxml page from the vxml server? Janine -- Janine Graves

Janine,
What are the other things you don't know?

Discovered some interesting stuff testing the ReqICMLabel and overriding
_dnis in the ToVXML:

If I do not override _dnis in ToVXML parameters, my _dnis is passed as my
test toll free number as expected. When I execute ReqICMLabel it uses
SIGDIG+correlationID as the DNIS which is impossible to program. Of course
I wouldn't really want t to use my toll free number since that would fire
off the routing script I originally came in on, but just thought that was
interesting, I wish ReqICMLabel would allow a DN value as an input param.

If I do override _dnis in the ToVXML parameters then ReqICMLabel uses that
_dnis to execute the routing script.

I'm not sure if overriding _dnis will impact courtesy callback or not, I
set the dnis in the queue defaults element so hopefully not, still testing
that part.

Bill W.

On Thu, Mar 7, 2013 at 5:13 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> >
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12390220orsimply 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/12772475or simply reply to this email.

Maybe I'm already beginning to regret asking.  Let me start with an easy one; they're not all going to get answers tonight.

3. With the ICM "PM" microapp, the gateway blocks on audio (plays it to
completion) - is there any way from the Studio application to accomplish
this (other than to play the Audio from another invoked Subdialog
application?)


Answer
The PM microapp VoiceXML includes an <object> element after the audio part that points to something that doesn't exist.  It's just there as a dummy to cause the document to block until the audio has completed.  In an earlier CVP release you may have been aware of a different method to achieve the same effect; instead of using an <object> element there used to be a dummy <transfer> element specifying 987654 as the destination.   This transfer was intended to always fail but the sub-optimal choice of the dummy destination (beginning with 9) meant that configured intended to fail. 
On Studio, out the box, there's no way to play blocking audio using the Audio Element; you have to use a different element that includes an audio group but will block, such as transfer, caller input, etc.  The more elegant way is to build a custom element or extend the standard Audio Element to include a boolean setting to wait for audio completion or not and include the dummy <object> if blocking is selected.

Hope that helps as a starting point.

Paul

That helps. I can teach my Java students to extend the Audio element to contain the object tag. I didn't realize that's how ICM accomplished it even though I've looked at the playmedia template file before. Thanks! Â -- To respond to this post, please click the following link: http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/12943310 or simply reply to this email. -- Janine Graves

Yes, PlayMediaIOS is the one. The other one was for the internal voice browser in the old Version 1.0 H.323 model which didn't use the IOS VoiceXML capability.

Bill, Did you try passing _dnis in the URL string (the same way ICM
passes it?) - it'll show in the Activity Log, and it'll be copied into
CallData dnis and Session Data _dnis. You could also pass the _ani this
way if you needed to.

URL: /CVP/Server?application=SomeApp&_dnis=1234

And in the Subdialog app do NOT enter _dnis in the SubdialogStart element.

Yeah, that fixed it, thanks Janine! Ah, that makes life so much easier.

Very cool.

Bill Westby.

On Mon, Mar 18, 2013 at 11:17 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Janine Graves has created a new message in the forum "General Discussion -
> All Versions":
> -------------------------------------------------------------- Bill, Did
> you try passing _dnis in the URL string (the same way ICM
> passes it?) - it'll show in the Activity Log, and it'll be copied into
> CallData dnis and Session Data _dnis. You could also pass the _ani this
> way if you needed to.
>
> URL: /CVP/Server?application=SomeApp&_dnis=1234
>
> And in the Subdialog app do NOT enter _dnis in the SubdialogStart element.
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/1320972r simply reply to this email.

I wonder the same thing! The ONLY reason to use CVP_Subdialog_Return is
if this app is sometimes called directly from ICM.
I bet it's left over from when they were testing/developing the CCB
code. Perhaps they were calling it from ICM Microapps.

Here's one thing you could do if you're squeamish about replacing the
CVP_Subdialog_Return. In this element, just return data without
name=value pairs. For example:
Caller Input: success
FromExtVXML0: janine
FromExtVXML1: graves

And in the CallbackEntry and CallbackQueue apps, if you want receive the
data back, then set the ReturnValue settings to
Parameter: caller_input
Parameter: FromExtVXML0
Parameter: FromExtVXML1

(these have to be spelled the way they are returned from the
CVP_Subd_Return element)

Thanks Janine, I'll give it a try, appreciate your help.

I have another question for you and the group...

For anyone using Survivability, do you run every ingress call through
the survivability TCL script or just specific numbers in the dial-peers.
We use CUSP and 99% of our calls arrive on the same 800 number we route all
8T to CUSP. So we would have to have survivability on that dial-peer by
default to offer CCB later on. Just curious if anyone has any experience
if this puts any addiitional load on the gateway or caused you other issues
like with voicemail, dtmf, etc. I'm working to find a resource at Cisco via
our VAR but figured I'd ask here first :-)

Thanks, Bill.

On Tue, Mar 19, 2013 at 10:31 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Janine Graves has created a new message in the forum "General Discussion -
> All Versions":
> -------------------------------------------------------------- Oops, typo:
> The second part should've said: And in the CallbackEntry and CallbackQueue
> apps, if you want to receive the data back, then set the ReturnValue
> settings to Return Value: caller_input Return Value: FromExtVXML0 Return
> Value: FromExtVXML1 (Careful to get the upper/lower case correct!)
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/13257133or simply reply to this email.

Bill, If you run the CCB diagnostic console when that call enters the studio app, does it also show ewt=0? http://IPreportingserver:8000/cvp/CallbackServlet?method=Diag

Hi Janine,

No it does not, it updates ICM EWT with whatever you pass to it with the
current call, constantly updating it.

I'm doing more testing to see if the callback actual wait time is having an
issue. I modified the CVP "math" element provided with the CVP
CallbackEntry sample app to calculate ewt in minutes to look at the session
ewt instead of the Callback_enter_queue element data which fixes the ewt
playback wait time to caller issue.

But once in my testing I passed in a 4 minute ewt and before I could even
hangup the scheduled callback session it was already calling me back which
concerned me and started me down this path where I found this ewt,0 value
was always being returned after Callback_Enter_Queue where before it was
passing back the ewt.

I guess whether this impacts callback times is still inconclusive like I
said, still testing. I am curious if anyone else has these ES's installed
on their reporting servers and had any issues.

Thanks!!!

Bill.



On Tue, Mar 26, 2013 at 12:28 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Janine Graves has created a new message in the forum "General Discussion -
> All Versions":
> -------------------------------------------------------------- Bill, If you
> run the CCB diagnostic console when that call enters the studio app, does
> it also show ewt=0?
> http://IPreportingserver:8000/cvp/CallbackServlet?method=Diag<http://ipreportingserver:8000/cvp/CallbackServlet?method=Diag>
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/cvp/forums/-/message_boards/view_message/13534052or simply reply to this email.

Janine,

1) I agree, overriding the DNIS seems an inelegant way to pass data to ICM. Using SubdialogInvoke to send the data to a single-purpose CVP app which then sends the data to ICM is a little roundabout, but it's also simpler to troubleshoot because of the compartmentalization, and easier to re-use.
2) Reporting on Hangup events sounds important to me... though if the call initiates in ICM, you'll have an "abandon" count within the call type report for any calls which ICM isn't performing the hangup on anyway. The Hangup error is more useful for recording what happened in the call, not that the caller hung up. I would think of the Hangup error as a way purely to send the data back to ICM which it would have otherwise gotten had the caller stayed on the line long enough.
3) If I can do something directly within the Call Studio visual workspace (instead of End of Call Java), it's much easier for the next person to understand my code. Also, I wouldn't make a habit of manually insert/updating anything to UCCE standard databases.

-Jameson