09-16-2010 01:01 AM - edited 03-14-2019 06:30 AM
Hi, all.
Currently we are using CVP 7.0(2) integrated with ICM 7.5(9), Just want to check if the following is feasible:
1. Caller calls the hotline being routed to a queue.
2. An agent picks up the call.
3. Agent does a consult transfer to another ICM routing script configured with another Dialed Number. It is a post call survey.
4. The post call survey takes over the call when the agent complete the call transfer
5. The caller's no (CLID) and AgentID are passed over to the ICM Routing script of this post call survey.
Can we achieve the above mentioned scenario particularly on item 5? Would appreciate any help and advice.
Thanks & Regards,
Eric
09-16-2010 06:05 AM
09-16-2010 07:37 AM
Hi, David.
Just another question, even if we customize the CTIOS Softphone to capture the CLID and AgentID, how do we pass these piece of info over to the ICM and CVP when the call transfer is taking place?
Thanks & regards,
Eric
09-16-2010 07:46 AM
If you have done the transfer correctly, call attached data (set at the CTIOS Agent Softphone) will be carried with the call. It can be extracted by the ICM script that calls the post-call survey VXML app and passed to it. CVP is in control of the call through the switch leg.
REgards,
Geoff
09-16-2010 08:33 AM
Hi, Geoff.
Thanks for your reply and precious. are you refering to call transfer initiated by the ICM script or the agent himself? I was looking for a solution for the agent-initiated call transfer.
Thanks & Regards,
Eric
09-16-2010 08:41 AM
Eric,
Are you trying to make an transfer to an outside party? Or is this transfer internal to your UCCE environment?
david
09-17-2010 04:02 AM
Hi, David.
I am actually exploring the agent-initiated call transfer to internal dialed number, which is tied to another ICM script.
Regards,
Eric
09-17-2010 07:44 AM
I am actually exploring the agent-initiated call transfer to internal dialed number, which is tied to another ICM script.
This is called a "CVP warm transfer". When the agent does this from CAD, I use a "dialed number plan" entry to start the second script. If someone does it from an IP phone (typically a non-agent) you need a CUCM route point to start the script. I make these numbers the same.
Either way, the coding in the second script and the configuration of ICM for CVP warm transfers is a little complex, but I have posted step-by-step details of this in the past. If you don't do it correctly, you will not see the call attached data present on the transferred call. This is a sure sign that CVP thinks it is a new call and you have it wrong.
When you do it right, the data will be there.
If you have any difficulties getting this to work, search for my post(s) with the 20 or so steps - look for "CVP warm transfer". Post back if you have questions.
Regards,
Geoff
09-20-2010 10:15 PM
Hi, Geoff.
Thanks for your reply. I have copied and pasted here a list of steps which you have posted previously about the CVP Warm Transfer.
1. PG Explorer - CUCM PIM Routing Client - Network Transfer Preferred not checked
2. PG Explorer - CVP PIM Routing Client - Network Transfer Preferred not checked
3. PG Explorer - CUCM PIM Advanced - Network VRU - NONE
4. PG Explorer - CVP PIM Advanced - Network VRU - Type 10
5. NVRU Explorer - Type 10 Network VRU, label for the CUCM routing client associated with the customer instance. Let's say this is 8222222222.
6. NVRU Explorer - Type 10 Network VRU, label for the CVP routing client associated with the customer instance. Let's say this is 8111111111.
7. Dialed Number List - dialed number for the incoming call associated with the customer instance. This dialed number is on the CVP PIM Routing Client. This DN is associated with a call type which is then mapped to the initial script.
8. Dialed Number List - transfer dialed number associated with the customer instance. This dialed number is on the CUCM PIM Routing Client. The transfer dialed number 3151 is associated with a call type which is mapped to the transfer script.
9. DNP. The number transferred to from CAD is 3141 which is a pattern in the DNP that maps to the Dialed Number 3151 with a post route to CUCM PIM Routing Client. The DNP Type is "PBX" - and PBX is set up in the Agent Desk Settings
10. Agent Desk Settings - All but "Operator" are checked
11. When the second call is placed for the warm transfer, the label defined on the CUCM RC plus the correlation ID will be sent back via EAPIM/JGW to CUCM (for example, if the label is 8222222222, with a correlation ID it could be 822222222212345) since the call originated from the CUCM RC and since the NetworkTransferPreferred check box is not checked.
12. A route pattern 8222222222! in CUCM sends the call down a SIP trunk to CUPS.
13. CUPS has a static route on 8222222222* to send the call to the CVP Call Server.
14. CUPS has a static route on 8111111111* to get the IP call to the gateway. Note that in a branch office deployment, TDM calls into the gateway use "Send to Originator" pattern in the Call Server to force the transfer label back to the voice gateway; so this pattern in CUPS is ONLY used by VoIP calls.
15. In all preliminary scripts that get the customer to the agent, set the variable Call.NetworkTransferEnabled to the value 1. This is set before the transfer is called.
18. For the device targets, you need a label on the CVP RC, but you do not need one on the CUCM RC, so do not add one.
I did try the above mentioned steps in my system, the transfer works alright. The only difference is that I did not set the variable Call.NetworkTransferEnabled to the value 1. To the ICM, is is considered as Internal Out Transfer or External Out? Another thing I have noticed is that when the call transfer takes place, the IP phone would display the Route Pattern of the CM Label + correlation ID configured, e.g. 822222222212345. this is rather confusing for the agents when they see this long string of number as it does not make sense to them. Is there any way to display some other meaningful line display or number (E.g. Transfer to mainline or 2900) while maintaining the CM label pattern 8222222222!?
Thanks in advanced.
Regards,
Eric
09-21-2010 05:54 AM
I did try the above mentioned steps in my system, the transfer works alright. The only difference is that I did not set the variable Call.NetworkTransferEnabled to the value 1.
Is there a reason you don't want to add this SET node? It is recommended in the CVP Guide in a number of places.
Another thing I have noticed is that when the call transfer takes place, the IP phone would display the Route Pattern of the CM Label + correlation ID configured, e.g. 822222222212345. this is rather confusing for the agents when they see this long string of number as it does not make sense to them. Is there any way to display some other meaningful line display or number (E.g. Transfer to mainline or 2900) while maintaining the CM label pattern 8222222222!?
I hear you on that. I don't think you can do much about it. There was one post recently on masking this by changing something on the phone but it affected something else. My customers have asked also, but backed off after a while. I think you'll have to live with it.
Regards,
Geoff
10-19-2010 01:47 AM
Hi, Geoff.
You were saying that it is recommended to set the "NetworkTransferEnabled" to 1 in the ICM routing scripts right? Which CVP guide mentions about this? Must we set this variable in all the ICM routing scripts? If yes, then do we set it right after the "Start" node? I just want to find out more details about this "NetworkTransferEnabled".
Another doubt i have is that do we need to uncheck "Network transfer preferred" checkbox under the CM PG Routing Client in the PG Explorer? I was reading the Configuration and Administration Guide for Cisco Unified Customer Voice Portal, Release 7.0(2) and it mentions that this option must be cleared. I have unchecked it last Fri and it seems that even the agent-to-agent phone call transfer is also considered as "External Out" in the Webview Agent Historical report.
Would appreciate your professional advice and recommendation for this case.
Thanks & Regards,
Eric
10-19-2010 10:33 AM
Hey Eric,
Using network transfers or not really is a design choice. The idea being that with Network Transfers configured, a transfer initiated by an agent will actually be routed by CVP rather than CUCM, i.e. the CVP Routing Client will get a new label even though the CUCM Routing Client (agent) made the request.
In general, using Network Transfers is a good idea for a couple of reasons :
1) Less configuration (to go wrong) / complexity on CUCM, i.e. there is no need to have patterns pointing back to CVP for the transfer label;
2) Less resource utilization on CUCM, i.e. CUCM doesn't stay in the call, which is/was especially relevant on older software releases where you need to always have MTPs into the callflow when transfering calls from CUCM to CVP due to H.245 re-negotiations and some software defects getting your calls to drop etc.;
3) In set-ups with multiple sites you really need a good design to be able to d proper bandwidth accounting.
The major drawback of using network transfers is that (to the best of my knowledge), CVP currently doesn't support consult network transfers, i.e. you can't do warm transfers (or conferences) between agents / IVR through CVP. Also I believe there's no clean way to allow the agent to dial a DN from his phone to do the transfer without getting an annoying busy tone, it's desktop controlled only.
To start using network transfers you need to both of these, or it will just use local CUCM transfers :
- Set NetworkTransferEnabled = 1 somehwere in the original Script flow, i.e. before the call reaches an agent, a best practice could be to put it somewhere around your Send To VRU node, you don't need it on the actual transfer script
- Tick 'Network Transfer Preferred'
Just to confirm : the local CUCM transfer just means that the 1st CVP leg will continue to stay connected to CUCM, CUCM may then route the call back out to CVP, i.e. creating a 2nd CVP leg. Whereas with a network transfer scenario, your CUCM would not be involved at all anymore at the time of your post-call survey.
Just to confirm that to Geoff as well, the steps you suggested set the system up for local CUCM type transfers, setting the variable really doesn't change anything.
12-21-2010 04:24 AM
Kris,
what if the CVP temp transfer for get digit and then reroute the call to same agent ,subesquently sending validation code on agent ,
let me know if you need more explanation i will explain ali_ahamed@yahoo.com
09-16-2010 10:23 AM
are you refering to call transfer initiated by the ICM script or the agent himself? I was looking for a solution for the agent-initiated call transfer.
Agent. It will work. Call context will be maintained - it would not be much of a solution if this were not the case.
Regards,
Geoff
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: