Unable to ACD Sign Out, F9600 and Intellicenter

[Havokmon]

Hi,

We're running a F9600 PBX with Intellicenter version 2.1.ICSV.2 on SCO Unix.

Randomly, we have agents who, after successfully signing into the ACD, are unable to sign back out. The only way we're able to get them out, is to restart the PBX. At the moment, it appears NO ONE is able to sign out :/

When we try to sign out, we supply a proper exit code, but then the phone gets a fast busy and they aren't signed off.

1st, what could be the problem?
2nd, Is there a way to sign off the ACD without shutting down the PBX? Once the phone is in ACD sign-on state, I can't really do anything with it from the EMML.

I thought the actual ACD signon was done in the PBX, so I wouldn't think it had anything to do with the Intellicenter. If that's true, what can be done in the PBX?

Thanks for your help

Rick

 

[Havokmon]

Hmm I think it might be related to bad ports. We've got errors on the EMML now:

MN FAULTY DCU01 DCU
MN FAULTY DCU00 DCU
MN FAULTY DCC0 IOU
MN FAULTY DCU0 IOU

It seems like it's probably related, as the Intellicenter runs off DCU01.

I think we may try replacing the PSIOU or PSDCC card (Is the PSDCC - DCU2x ?)

 

[SpankyMcF]

This is a communication error between the IC and PBX.
The signon/signoff request is initiated by the PBX and sent to the IC. The PBX will wait for a programmed lenght of time for a reply. If the two are unable to communicate, timeout will occur resulting in reorder tone.
The Eicon card to DCC port is losing communications.

Since you have a PSIOU card this is obviously an ES.
If your PSDCC card is in slot 23, then it is programmed as DCC2 (DCU20 to DCU23). If the PSDCC card is in slot 22, the it automatically becomes DCC0 (DCU00 to DCU03) and the two ports on the PSIOU card are disabled.

When this issue occurs, try to restore the DCC port.
"RES IO,DCU01"

If the port fails to restore, the PBX and IC link is down.

 

[NewNic]

IC is now up to 7.1 running on windows server

There are several patches of the the 2.x version running on SCO. The latest 2x load is 2.1.5, there are several enhancements and fixes. Altura can supply you will the updates

 

[Havokmon]

Oh you hit the nail on the head allright

I didn't realize the sign-on/off required the Intellicenter link to be up, so it's definitely related to our Intellicenter <->PBX communication issues.

I've tried doing a RES IO,DCU01 - many times I always get an error, as if the port is still online. I can do a rem io, dcu01 then res io,dcu01 but that doesn't cut it. The only thing that does fix it is a PBX restart.

In trying to determine precisely which DCC port was what card, I pulled the PSDCC card (which was in slot 23). The ACD did not go down, meaning it was DCC2 - exactly as you said. Unfortunately I didn't realize the PSDCC card wasn't hot-swapable, so we ended up restarting the PBX anyways.

I'm getting together with our phone support guy on Friday to try and determine exactly what's going on. I belive he's already replaced the PSIOU card, but I'm not entirely sure. That's the one with the DCC0 port, correct?

Also, I've noticed that if I pull the network card in the Intellicenter, it goes from Down to Connecting to Online within a minute or so. ANY network card in the Intellicenter, randomly causes that process to run slow.
Last week, I completely removed the Intellicenter from our network, and direct linked a workstation to it in case it was a network issue, but that didn't help.
I've got a 3rd card in there now, we'll see if that helps.

I have a feeling, since the only noticable change seems to come with modifications to the Intellicenter machine, we should upgrade the Intellicenter machine and software. But, what stops my thoughts there is that the only 'final' solution usually means restarting the PBX - argh!

Thanks for the input!

 

[telm59]

Display ap,

this will tell you what port the acd is on.

look for LAPB.

 

[Havokmon]

FYI - I firewalled off the Intellicenter.. Because that old SCO box had just about everything open, and guess what, our Intellicenter issues have dissipated.

Obviously something on the network is causing problems, but I'm not seeing any 'out of the ordinary' traffic. It might just be new and old clashing. For Example, nessus showed it had a routing vulnerability.

In any case, just leaving the required ports open to the network seems to have alleviated my issues.

(I blame Windows - this didn't happen with Netware )

Rick