Outbound Agent-based campaigns don't work for SIP Dialer

[bankspb]

Transfer to IVR campaigns is working fine

Outbound Agent-based campaigns don't work for SIP Dialer (error translation route)

We need: If agents are available, SIP Dialer call to the client and plays welcome prompt and connecting to queue to the skill group.

If using Transfer to IVR campaigns, progressive dialing isn't working correctly: dialer calls to 8 clients (the total number of IVR ports allocated for the specific skill group in the campaign), but ignoring information of available agents in skill-group (lines per agent=1.5) and SkillGroup.TEST_Campaign_8099.SG.OutboundPercent in admin script.

[Omar Deen]

---

We need: If agents are available, SIP Dialer call to the client and plays welcome prompt and connecting to queue to the skill group.

---

You can't do that with agent based campaign. When it comes to agent based, the VRU is not in the picture at all. When the call comes in, send in to a Select node for LAA and then go to the Skill Group node. Also, you should not be using Translation Routes, that was mainly to get the dialer to work with IP IVR

[bill.king1]

I agree with @Omar Deen re: the no messaging for agent-based campaigns, if you want to play something to the customer, you're going to be using a variation of a Transfer to IVR campaign to play that to the customer before transferring to an agent. You can still use the percentage outbound and lines per agent to help control the flow of calls to the agents so they aren't overwhelmed.

Omar, I do disagree (unless things have changed) re: the Translation Route piece though. You need to have the translation route with CVP in UCCE deployments (but not PCCE), at least in my experience still.

[Omar Deen]

@bill.king1I wouldn't say things necessarily changed, rather, it's a CVP/IP IVR thing. Translation routes are for transferring the call from the Dialer to IP IVR. The Dialer is the source routing client and IP IVR is the peripheral that will receive the call, which is sitting on the gateway channel. When the Dialer is sending the TR label to the gateway, the gateway will request CUSP for the route, so a dial peer will need to be created on the gateway to handle the TR label. Nor would you need a Service and a Route that would also be included an in IP IVR environment. This has all been simplified with CVP. You create a label, MR PG with PIM, setup the Logger, setup the Dialer, setup CUSP with a listener port, add your dial peers  (100rel stuff) and CPA info if needed on the GWs, setup the CUCM SIP trunk and SIP normalization script.

A few years ago, I helped a large financial company in MSP upgrade to UCCE 11.6, and part of the upgrade was to remove all the translation routes. Now, all their IVR campaigns go through a Send to VRU node with no issues.

[bill.king1]

Did you do something unique as far as the Network VRU though? It is still documented in the guide that if you're using a Type 2 VRU (i.e. dialer), that you have to do a Translation route?

"For a solution that uses Type 2 IVR (such as IPIVR) or any other solution that requires a translation route to IVR, configure a translation route before you start this procedure. See the Cisco Unified Contact Center Enterprise Installation and Upgrade Guide for instructions."

[Omar Deen]

With CVP, it'll be type 10 which will go with your outbound label

[bill.king1 · Accepted solution]

I wish I had a UCCE sandbox to check this. If the dialer is created as a Type 2 one based on the outbound guide instructions though, aren't you going to run into the note above? In other words, CVP is Type 10 but dialer is type 2?

[Omar Deen]

Bill, I'm not sure what the confusion is here...

IP IVR = Type 2

CVP = Type 10

The history of this is that IP IVR came before CVP and needed translation routes for the outbound option to work. When CVP was introduced, you could use a type 10 NVRU, but could still keep type 2 as many environments did to simplify their upgrades. You can use Type 2 in a CVP environment, but why would you? Creating the Dialer is entirely independent of the Label and the NVRU. It only comes into play when you apply it to your MR PG and create a dial peer for said Label. If the current MR PG for the Dialer has a Type 2 NVRU selected, you simply change it to the new Type 10 from the drop down selection, make the changes to your gateway dial peers, and update your routing script to remove the TranstoVRU nodes with SendtoVRU node.

Hope that helps

[bankspb]

"When the call comes in, send into a Select node for LAA and then go to the Skill Group node"  - LAA doesn't work with CVP, the call fails. If using Queue to Skill Group - working fine.

Also, if I using Transfer to IVR campaigns, CVP VXML scripts working fine without Translation Route and the welcome prompt and menu are working fine too, what reason for using  Translation Route???

I can't be using Transfer to IVR campaigns, progressive dialing isn't working correctly. To find a solution, I tried using  Agent-based campaigns and Route Points for Transferring to an IVR - When no agents are available to another DN associated  ICM script with Queue to Skill Group, but in dialer reports, I see the following CallRsult: "Customer has been abandoned to an IVR", which ultimately does not allow you to track the call correctly, although it was actually answered by the operator.

You can give an example of the correct setting Translation Route  with ICM scripts for my scenario:

If agents are available (need reservation agents for outbound calls without direct preview), SIP Dialer calls the client 1:2 (lines per agent=2) and plays welcome prompt, and connecting to queue to the skill group.