STRANGE ISSUE OF AGENT GOING INTO RESERVED STATE!!!

Unanswered Question
Nov 4th, 2009

Guys,

I have a new install of UCCX 7.0(1) and I have this wierd issue.

When a call is placed to the RP, the script attempts to select an agent assigned to a CSQ, at this point the call goes to the agent phone, ring once and then the agent goes to reserved state. On the agents CAD, you actually see the call and on the phone you see a missed call.

On another agent phone, when the call is placed to the agent, the agent goes directly to reserved state.

Both phones DN have the same partition.

I have checked all CSS/PT and Its obvious this is not the issue.

Any ideas please.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Ayodeji Okanlawon Thu, 11/05/2009 - 00:16

Josh,

Thanks. I do not have SR4. So I am not sure if this applies to this issue.

I did do test to confirm that the CTI ports can indeed xfer calls to the agent DN by using a redirect step to agent DN and it did work.

Yes, agents DN are unique.

Do not know where to look now

Ayodeji Okanlawon Thu, 11/05/2009 - 01:18

Hi,

Attached is the MIVR log for one of the calls.

The impotant bits are highlighted.

It shows th following

1. Call offered to CTI port 5703

2. Call recieved from ANI=1010 on RP 5711

3.CSQ "sales" selected and agent hqph2 allocated for the call

4. Immediately the agent was selected, its agent state change from Available to Reserved

with a reson code of "0"

Snippet below:

Agent hqph2.allocateRsrc(33570654) 90976: Nov 05 07:43:03.850 PST %MIVR-SS_CM-7-UNK:RmCm contact 33570654[16222/2] (33) .setAllocatedResource(hqph2) 90977: Nov 05 07:43:03.850 PST %MIVR-SS_RM-7-UNK:Agent hqph2 .addAssociatedContact(Contact:RmCm contact 33570654[16222/2] (33) 90978: Nov 05 07:43:03.850 PST %MIVR-SS_CM-7-UNK:RmCm contact 33570654[16222/2] (33) .addAssociatedResource(hqph2) 90979: Nov 05 07:43:03.850 PST %MIVR-SS_RM-7-UNK:Rsrc: hqph2 New State:RESERVED Old State:AVAILABLE Reason code:0 90980

Attachment: 
Ayodeji Okanlawon Thu, 11/05/2009 - 10:52

Guys,

In the end, it was not a UCCX server problem. It was a SIP phone issue...SIP phones!!!! God I ha............................te them!

Actions

This Discussion