Call disconnects when headset button on 5420 pressed, AWH-55+ headsets

[calcomp2]

Anyone experienced a problem where an incoming call is disconnected when answered using the headset button on a 5420 (with a connected AWH-55+ headset)?

We use IP500s at multiple sites with DS8 cards connecting 5410/5420s handsets. Software is 4.1 and 4.2. Systems and handsets/headsets are less than two years old.

At first I thought perhaps just a bouncing 5420 headset key was the culprit (first press answers then a bounce hangs up the call.) However, two very reliable users (one on the 4.1 system and one on the 4.2 system) report multiple occurrences of the problem (and neither is the aggressive-type stabbing the headset button.) And, no other key on the 5420s they use seem to "bounce."

I've asked one user to try answering calls exclusively using the button on the AWH-55+ headset, and it appears calls do not disconnect when answered at the headset.

Additionally, there is some indication the problem can be minimized by not answering the alerting call immediately. That is, one of the users reports that waiting for a ring cycle or two before answering with the headset button on the 5420 seems to reduce the frequency of disconnects.

Incoming calls at these two facilities are via POTS lines connected to analog 4 mezzanine cards. The AWH-55+ headset base stations are configured per the book for connection to the 5420 (telephone configuration dial on the base is set to position 3.) The AWH-55+ headsets otherwise work normally.

This problem is happening too frequently (multiple times daily per user), at two separate locations, to be a fluke.

Any thoughts or suggestions?

Thank you.

 

[amriddle01]

Have you followed the steps on Page 20 of the following document? It describes your problem pretty much exactly

http://www.lctinc.net/downloads/plantronics_awh55_userguide.pdf

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[calcomp2]

Page 20 as in "Suddenly the call is dropped. (Talk indicator on the headset and base will not be illuminated.)"?

I will try (and should have tried) the suggested steps.

However, I don't think the page 20 description quite fits. Perhaps my post's opening sentence should have said: ... an alerting call is immediately disconnected upon pressing the headset button on the 5420 ...

Except for answering the alerting call with the 5420's headset button, the AWH-55+ headset and 5420 handset combo otherwise function normally. The previous call, and the next call, are answered without disconnecting the caller upon pressing the headset button on the 5420. There are no similar unusual reports of callers suddenly being dropped once the call is established while using the headset. There is a hint that the frequency of the problem is reduced if the alerting call is allowed to ring for at least one ring cycle before being answered (with the 5420 headset button.)

I'll report back after measuring any change a headset system reset might bring.

 

[amriddle01]

I am fairly certain you should only press the headset button once upon first connecting the headset, after that you should use the headsets Talk button on the boom, perhaps that is the issue

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[calcomp2]

Thanks Andy for your posts.

Although there is some conflicting information from the user community, it appears the disconnect problem is not related to which button is used to answer the call. That is, answering an alerting call with the headset TALK button does not solve the problem compared to answering the alerting call with the 5420's headset button.

Also, at my desk where I spend way too much time, it's easier to press the headset button on the 5420 (vs. shoving the boom into my ear while pressing the TALK button.) I'll be in a heap of trouble if my proposed solution to this problem is "don't use the phone's headset button."

The one consistent tidbit is waiting to answer the alerting call using either method improves the problem. I'm waiting for more feedback on this, especially since it means suggesting we should delay answering customer calls (which is of course better than apparently disconnecting them!)

And, just noticed in another thread the good news you've shared. Congratulations!!

 

[amriddle01]

Thank you very much You cold try a monitor trace of a call that has the problem and one that is delayed so avoiding the problem and then compare the two and see if that sheds any light on the issue, or watch the call trace progress in SSA and see what that shows

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[amriddle01]

Are they pressing the Drop key to end the call? Try it as oppose to using the headset button.

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[Telecomboy]

If you keep the headset button active, you should be able to answer the call by pressing the ringing incoming line. Then to end the call, press the drop button. The whole time, leaving the headset button active.

 

[amriddle01]

The correct method is as follows:

To answer an incoming call:

Press HEADSET.

If you are already on a call:

• Place the first call on hold

• Press the button next to the flashing bell icon.

To clear a headset call:

• Press DROP.

To manually make a call:

• Press HEADSET.

• Dial the number. Remember to include the required access code (for example; 9 for an outside line) and listen to the progress of the call.

Stick with that and it should work, if not it's a bug/fault somewhere



ACS - IP Office Implement

"What the Crocodile Hat....was that?