Agent transfer to post survey CVP in ICM

Answered Question
Jul 14th, 2010
User Badges:

Hi


I have the following situation. The call comes in to CVP the customer then has the possibility to connect to an agent. The agent then transfers the call back to CVP.


Call -> CVP -> agent -> CVP


I'm having the followong problem. The call context is not being maintained whent the agent transfers the call back into CVP i get a new call id. I need to maintain the original call id.


Any help appreciated


rhobab

I posted this once before. See if this helps.


Regards,

Geoff




For CUCM originated calls, either a call instigated from an IP phone to a number that is a true CUCM route point, or from CTIOS/CAD to a DNP entry that "dummies" a route request that runs an ICM script, and whether this is in the context of a SIP warm transfer or a stand-alone call, there are a number of items I consider as a check list to make this work.


See if this makes sense to you and check that you have all of this set up correctly. Substitute your own NVRU labels and so on.


I have this working from CAD using a DNP, and from an IP phone using a CUCM route point. Both work correctly. This is not an easy thing to configure, and there are a number of things that can go wrong. Here is a check list that may help you get this working.


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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.

What CVP, UCCE? SIP or H.323?


How are you doing this transfer? The method required is similar to the way you would do a warm transfer where the agent doing the transfer has the ability to drop the call in the queue instead of waiting for agent 2 to answer. Call context can be preserved.


With the older CVP and ICM, you need a explicit translation route. With the newer CVP and a Type 10 NVRU, the trans route will be done implicitly.


Since the agent is doing the transfer, you don't need a true route point in CUCM - you can use the DNP (Dialed Number Plan). The DNP is attached to a DN which will run a script (normal DN - Call Type - Scheduled Script) with two Send to VRUs.


The first S2VRU uses the label on the CUCM routing client returning a label to CUCM. This is defined as a route pattern in CUCM to send the call up the trunk to your proxy server (assuming SIP) which finds your CVP. The correlation ID finds the script the Call Router paused, and continues.


Now it hits the second Send To VRU and the label on the CVP Routing Client finds a gateway through the SIP Proxy.


When this comes back to CVP, the correlation ID method is used again by the Router to find the paused script and continue - now you can run your VXML app.


The correlation IDs are doing a form of trans route - enabling the system to maintain call context. You can search here for how to do SIP warm transfers for more explicit details. I have posted the steps before. Ask again if you need more.


Regards,

Geoff

rhobab Wed, 07/14/2010 - 08:45
User Badges:

I'm using CVP 8.0(1) , UCCE 8.0 and SIP.


The agent receives the call and is using the ctios desktop o transfer the call using single step.


Can you be more explicit on the steps please


thanks


rhobab

Ah, you are way ahead of me, playing with CVP 8.0. All the above applies to CVP 4.x and 7.x


In 8.0, Cisco added support for post-call surveys, so that when the agent drops, the call is transferred to a pre-configured "Survey Dialed Number".


So have you configured your system as on pages 449 to 452 of the CVP 8.0(1) Config and Admin Guide, and do you have the "Survey Dialed Number" mapped to a call type and a scheduled script?


Regards,

Geoff

rhobab Thu, 07/15/2010 - 01:47
User Badges:

I'm not actually doing post survey. What I'm doing is something like agent to agent transfer but instead o the call being queued to a skillgroup and in the event of no agent being available being handed to CVP for queuing, the call will be handed directly to CVP.


Could you tell me the details of this type of transfer. I'm sure I'm missing a step some where or getting that step wrong.


All help appreciated


Thanks


Victor

Correct Answer

I posted this once before. See if this helps.


Regards,

Geoff




For CUCM originated calls, either a call instigated from an IP phone to a number that is a true CUCM route point, or from CTIOS/CAD to a DNP entry that "dummies" a route request that runs an ICM script, and whether this is in the context of a SIP warm transfer or a stand-alone call, there are a number of items I consider as a check list to make this work.


See if this makes sense to you and check that you have all of this set up correctly. Substitute your own NVRU labels and so on.


I have this working from CAD using a DNP, and from an IP phone using a CUCM route point. Both work correctly. This is not an easy thing to configure, and there are a number of things that can go wrong. Here is a check list that may help you get this working.


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.

rhobab Thu, 07/15/2010 - 09:19
User Badges:

Hello


It works fine, I followed your steps one at a time. The only thing diferent was the CUCM that was pointing to the VXML Gateway and not the Call Server. Thanks for your help.


Victor

Actions

This Discussion