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.
Well according to the documentation, CCB is not supported with CUBE. Which leads me to believe that it is not supported with Incoming SIP connections. Although I have not tried it, until the documentation says otherwise I wouldn't put anything like that into a production environment or at least having it cleared with the CCBU.
Actually as of 8.5 that restriction may have been removed. I only did it with 8.0 so far. Looks like the documentation says otherwise now. Don't have time to research it right now but it may be that it will now be supported in 8.5.
Just FYI. The CCBU confirmed at a conference I was at that CCB is now supported with CUBE as of CVP 8.5. The documentation will be updated.
I'm testing this out does the "billing" queue name need to match a real skill group name?
We get the infinite Queue Music , I'm sending in "billing" for queue name, and "BillingQueue" for the QueueApp to the CallBackEntry app.
The element that sets the defaults is set to "billing" as well for the Queue name.
The logs for the application indicate the SetQueueDefaults_01 is failing, which puts us in hold forever.
10.1.4.11.1350504600120.22.CallbackEntry,10/17/2012 16:10:00.354,SetQueueDefaults_01,element,warning,doDecision- Error while validating inputs for SetQueueDefaults. maxpct=100 maxcnt=50 maxewt=0 refresh=1 keepalive=180 reconnect_time=-1 SLA_time=60 rna=30
That is great that you are having success with CCB. In terms of polished, are you including accurate EWT in low and high call volumes? For me accurate EWT in different call flow scenarios is the Holy Grail of CCB working. It would be awesome if you would share your formula for calculation EWT.
What I have found with EWT and the last 13 years of ICM expirence is there is no 100% accurate of calculating EWT. So I set my customer expectation manually, meaning I take the standard EWT and round up . If I receive 3.2 min EWT I play 5 min to the customer, if the EWT is <30 sec I play 1 min. This sets the customer expectation and allows me to always over deliver . Now I'm fortunate to be in a position that my contact never has a greater than 5 min actual wait time.
When we implemented CCB I use the same EWT algorithm only because I can guarantee service within the customers expectations.
Always under commit and over deliver !
Thanks for the quick reply on that. I like yourself have been working with ICM for over 10 years and have the same opinion of setting the customers expectation on EWT. I guess I was hoping, with the response you gave on being polished, that EWT had finally grown up in ICM. We are able to get EWT much tighter on other ACD platforms, but it seems to keep eluding us on ICM. On s a side, we have also had similiar succes in getting CCB working (as adevertised) in CUBE and other SIP based CVP 8.5 projects (filed and worked around a few bugs myself).
CCIE 6487 (ISP-Dial)
I tested the feature with Simulated SIP Trunk ( Asterisk Server ) and it is working ...
just add the survivabilitiy service under the incoming voip dial-peer .
i have done testing with FXO and it is working , but i am having a strange problem that only happens in TDM FXO .. when the system offers a call back and the customer answers the call ... the CVP just gives silence .. i pressed 1 and i got the IVR " Hello , this is a call back for .... " and it is working .. kinda strange ..
the other thing ... after the Hold Music inside the CVP is finished .. i recieve an Error inside the VXML Application of Queuing ... i guess there is a missing parameter ( " qtime " ) which is required but not set inside the ICM Script ...
looking for a little assistance with this. I'm hoping that someone has run into this problem before.
This is an internal CCB setup using CUSP and a CUBE/VXML
Here's a very high level overview of the current call flow and the issue we are seeing
Internal Caller -> CUCM -> CUSP -> CUBE/VXML -> CUSP -> CVP
Caller name recorded and number grabbed (all working as designed)
CVP -> CUSP -> CUBE -> CUSP -> UCM -> Internal Caller
Caller confirms identity and requests to speak with an agent (working as designed)
After this is where I'm running into a problem.
If an agent is in a ready state, Agent gets reserved and Call Leg to Agent is connected (working properly)
If an agent is in a not-ready state, Initial Caller is queued to SG. When the agent goes ready, the CVP Instructs the CUBE/VXML to activate the Ringback service.
The ringback service times out after 5 seconds on the CVP and CVP reports a SIP 488 error.
Initial caller is disconnected.
Has anyone seen this before?
CUBE may not have a Dial-Peer for your Agent Extension Range and the CUBE is being asked to swich legs to an unknown destination.
Can you post your CUBE/VXML "sh config", and CUSP Route Table ?