Something that might be of interest for anyone wanting to queue callbacks from a CVP session.
Usual custom element caveats apply.
I've added the exported Studio app. Very basic callback request wrapped in a few prompts to simply fire off the request and follow-up with status retrieval.
Paul - I tried compiling AgentRequestAPI.java, looks like I require jersey-client.jar. when I downloaded from jersey, the compilation didn't get through. Can you pass on the Jersey client that you had used for developing this custom element, so that I could move on with the testing?
can can you provide info on how the actual call was placed out to the customer when the agent became available? what originated the call? Agent phone? this the piece I am missing.
Yes, the call is automatically set up from the agent phone at the request of the agent PG. So, from the perspective of the call, the agent experience is similar to direct preview mode. However, in this case the data flow is more like it is for an incoming call, just with the call the other way around.
I've dropped a ppt in the Box location that shows some variants on the basic callback scenario.
Can you suggest where to look to troubleshoot the outbound call. I am getting the API request into the ICM script. However, when the agent goes ready, nothing happens on finesse and the call is discarded with a routing error in SocialMiner.
Have you added your callback routing client to your Agent Targeting Rule, assuming you're using that method?
I'd start by getting some traces on the Router, MR PIM and Agent OPC / UCM PIM.
Thanks for the help Paul.
Can you point to a doc or link around the CVP sip refer? We are attempting to use CVP to playback the callers name (to the agent) and then do a sip refer to the customer number as you outlined in the ppt. The sip refer is not working and are not seeing it really try. No debug on the vxml gateway, nothing gets to CUCM. Also seeing different syntax on the proper label for the sip refer.
Any help would be appreciated.
There's 3 ways to invoke the SIP REFER.
In the Box doc I used the third option which includes the destination IP address explicitly and bypasses CVP SIP number resolution. The first two ways use CVPs configured dial plan handling as normal to map dest DN to IP address.
The second aspect you need to address is configuring UCM to handle the incoming REFER. Add a SIP Route Pattern to map destination IP address/host to the right SIP trunk.
First debug steps are to look in the CVP Call Server log and get a Wireshark trace on the CVP server to see what the SIP REFER message looks like, assuming it gets that far.
Ok, missing the SIP route pattern on CUCM.
In your PPT, is the RHS of the label the gateway IP or CUCM's IP? It think this is the last piece of the puzzle.
The RHS is your intended transfer destination IP address or hostname; so in this example it's the egress gateway address. Whatever you set the label to will populate the SIP REFER message Refer-To header and will be the IP destination the UCM SIP Route Pattern will have to resolve.