5000 HX controller extension busied out

[bhackbarth]

What could cause an extension to be busy on the 5000 if there are no active calls on the controller?  DSS keys assigned to the extension blink rapidly.  I looked at phones under Device status and  the status for that extension is "Busy", but under active calls there are none.

It's not in DND or anything like that, the DND allowed flag is set to No.

After hours I right clicked that extension and hit Reset this phone, which caused it to go back to normal Idle.

Now this afternoon I looked and it is busy again!

[DND ON]

Does the error log show anything? It sounds like an issue with the keyset itself. Try swapping with a known working phone and see if the problem follows the phone or the port.

[NTEDave]

Is it a Digital phone? If there are too many errors on the cable run/phone i'm fairly sure it can go out of service??

Are there any alarms on the system?

[Tech Electronics]

Bhachbarth,

Go to the phone and dial the feature code for Background Music (default: 313) and see if that fixes your problem.

Thanks,

TE

[bhackbarth]

Sorry for the lack of follow up on this.  The problem seems to have vanished, but I think I was able to reproduce the problem.

DND: nothing amiss in the logs

NTEDave: these are 5330 and 5340's.   No alarms.

TE:  good thought, but background music does tie up a G.7xx resource and is viewable under Resource usage.  But I made sure this was turned off for sure.

I was adding a new extension and dialed a trunk group that was busy. The extension began camping (or waiting)  for the trunk group and started playing background music.  I hit speakerphone to hang up.   Hours later after the drive home I opened Admin and Diagnostics and viewed the status of the phones, and the set I added was marked busy. No Active Calls on the controller.   Right click - restart phone.  Phone went offline, rebooted, came online and was busy again.   Reset controller.  Phone came up busy again.

Waited until next morning; extension was not busy anymore.  When I have some time I'll try turning off trunk group camping and see if that's it. It seems like it doesn't revert to idle after camping for a resource.  This particular deployment uses ARS everywhere with camping turned on so that may have been triggering the random sets to remain busy after they camped for it.

I never observed these behaviors on 5.1 SP4 which I miss having for this deployment.