CVP - Agent Subsequent Xfer via DNP

Unanswered Question
Feb 7th, 2008

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.


C.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
cvenour Thu, 02/07/2008 - 16:00

Looking in the CAD agent logfile shows the following error:

2008-02-07 11:25:35:848 INFO PHDV0000 CEventSink::OnControlFailureConf: FailureCode = 32 - PeripheralErrorCode = 10144 - ErrorMessage = IPCC Error [10144]No Agent (or supervisor) is available to take your call - MessageType = Unrecognized MessageID: 0? - UniqueObjectID = call.5003.16778225.1001

2008-02-07 11:25:35:848 ERROR PHDV3000 CEventSink::OnControlFailureConf: General exception occurred.


------------------------


Looking in the CTIOS log shows the following:

02/07/08 11:25:35.832 2936 agent Thd(2316) [call.5003.16778225.1001] eConsultationCallRequest ( 6389 )

02/07/08 11:25:35.832 2936 agent Thd(2316) [call.5003.16778225.1001]::MakeRequest( eConsultationCallRequest )

02/07/08 11:25:35.832 2936 agent Thd(2316) [call.5003.16778225.1001]::MakeRequest: (ConsultType:1 DialedNumber:6389

UniqueObjectID:call.5003.16778225.1001 ClassIdentifier:3)

02/07/08 11:25:35.832 2936 agent Thd(2316) CCtiOsSession::MakeRequest(eConsultationCallRequest)

02/07/08 11:25:35.832 2936 agent Thd(2316) CCtiOsSession::MakeRequest: (ConsultType:1 DialedNumber:6389

UniqueObjectID:call.5003.16778225.1001 ClassIdentifier:3)

02/07/08 11:25:35.848 2936 agent Thd(5160) CCtiOsSession::OnEvent( eControlFailureConf ), EnablementMask = 3c0000

02/07/08 11:25:35.848 2936 agent Thd(5160) CCtiOsSession::OnEvent, (CallType:2 FailureCode:32 PeripheralErrorCode:10144

EnablementMask:0x3c0000 UniqueObjectID:call.5003.16778225.1001 CallStatus:3

MessageID:eControlFailureConf ErrorMessage:IPCC Error [10144]No Agent (or supervisor) is available to take your call

ICMEnterpriseUniqueID:icm.148690.40320204

DeviceUniqueObjectID:device.5003.1001)

02/07/08 11:25:35.848 2936 agent Thd(5160) [call.5003.16778225.1001] eControlFailureConf : (CallType:2 FailureCode:32

PeripheralErrorCode:10144 EnablementMask:0x3c0000

UniqueObjectID:call.5003.16778225.1001 CallStatus:3

MessageID:eControlFailureConf ErrorMessage:IPCC Error [10144]No Agent (or supervisor) is available to take your call

ICMEnterpriseUniqueID:icm.148690.40320204

DeviceUniqueObjectID:device.5003.1001)


------------------------


Both contain the "IPCC Error [10144]No Agent (or supervisor) is available to take your call" message.

Riccardo Bua Fri, 02/08/2008 - 01:10

Hi C.,


I am afraid this is the kind of scenario typical for a TAC SR, a complete set of logs would be needed and some time to review them too.


Regards,


Riccardo

cvenour Fri, 02/08/2008 - 18:59

Hi Riccardo,


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. :-)


C.

Actions

This Discussion