My setup is as follows: CVP 4.0(2), ICM 7.2(2), CUPS 6.0(2) SIP Proxy, CM 6.0(1), CAD 7.2(1), and a second SIP IVR.
I've got a complete call flow happening, with calls being handled by CVP, being xfered to the second SIP IVR and back (with data), then being queued to agents and correctly delivery to the desktop (with data).
I've also got Agent Xfers working using the following config:
1. Create a new call type for internal transfers.
2. Create a new dialled number (eg 3999). This is NOT the number the agents call, but it is the one that invokes the script. Agents will call a different number, which will be translated via the DNP entry below.
3. Using the Dialled Number Plan Bulk Insert tool, do the following:
a) Wildcard Pattern: Add number agents will call (eg 3899).
b) Routing Client: CM
c) Post Route: Yes
d) Dialled Number: the Dialled number you created at Step 2.
e) Dialled Number Type Plan: PBX (must also be in the Agent Desk Settings).
4. Create a script with Send to VRU (to get the call to CVP) and then queuing to a Skill Group again.
All of this operates as expected, with call and data delivery working correctly - on the first xfer from an agent.
However, a problem arises if the second agent attempts a subsequent xfer/consult/conference using the same DNP number.
1. Customer talking to Agent A.
2. Agent A Xfer to DNP Xfer Number.
3. Customer is Xferred back to CVP, and receives treatment.
4. Agent B receives call.
5. Agent B tries to Xfer, and we're left in one of a few situations:
Result A: Nothing happens
a) Agent A is still talking to customer.
b) CAD Transfer a Call Window remains open, with the Dial/Transfer button greyed out (after clicking it).
c) Cancel button on Transfer a Call Window leaves agent talking to customer.
The trace below is form this result.
Result B: Error
a) Agent B hears CVP error message.
b) Disconnect from error message, leaves Customer Call apparently held.
c) Unholding the call results in Agent B hearing dead air, and the eventually fast busy tone.
d) Customer is left hearing dead air.
The routing script is being executed, which means the DNP is being correctly invoked, but the script fails out of the Send to VRU node. Result 2 is hearing error tone because the failure node of the Send to VRU script goes to an error label, but that doesn't explain why Result 1 doesn't hear anything when it seems to be failing out at the same place.
In either case, Router Log Viewer returns the following errors:
Label node had no label valid for routing client dev1_pg1a_cm_rc (ID 5002), dialed number dev1_pg1a_cm_rc.6390 (ID 5006).
No default label available for dialed number dev1_pg1a_cm_rc.6390 (ID 5006).
This is strange, since the first xfer occurs correctly.
All xfers are ICM Managed Xfers - I am not using SIP REFER xfer, so CVP remains in the call for each. What is odd is that if I use SIP Refer for the agent labels, the call gets to the agents correctly, but the DNP Xfer fails completely.
I've also tried setting up a CM CTI Route Point, with TR to VRU to get the call back to CVP, but the CVP docs (even the 4.1 Config guide) refer to using a Type 2 IVR and separate Call Server for this purpose, instead of an existing Type 10 Call Server / PG. I'm guessing (hoping) that this is a documentation update problem, rather than a product issue.
Late on Friday afternoon, just before shutting up shop for the week, I fixed the issue.
After chatting to Bruce J in Cisco AS in Sydney, I moved my trace examination from the PG OPC process to look more at the RTR Router process, using RTRTrace. This showed me some interesting, albeit strange routing results flowing around, with a mixture of routing clients showning up (to be expected in CVP).
I then needed to find a bit more info about how all of this worked in the Type 10 / SIP world. So, even though I am using 4.0(2) of CVP, the 4.0(2) docs relating to Type 10 VRUs and SIP are pretty thin on detail. However, the 4.1 CVP docs cover this area off in a bit more detail. So, I ended up configuring things as per the 4.1 Config Guide, and also made a few changes to other config pieces, and I now seem to be able to get DNP Xfers working consistently.
I'm not using SIP REFER Xfer, so the trick was in ensuring the route result went to the correct RC - that is, the CVP RC.
The end config involved turning off Network Transfer Preferred for all Routing Clients (including CVP), the Network VRU for the CM RC was removed, removing the label for the CM Routing Client, and ensuring that all routing scripts included a Set Node for "NetworkTransferPreferred=1".
So now the end result is a working DNP-based Xfer setup, which works for first, second, third, etc subsequent Xfers.
The only question I am still pondering is why it worked for the first one before! But I can probably live with not finding that one out. :-)
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...