88XX offhook/onhook issues

[Andrew Skelly]

Has anybody encountered an issue where your 88XX (specifically 8851) phones have randomly exhibited off-hook/on-hook tendencies?  Over the past year we have had upwards of 250+ phones randomly go off-hook then on-hook in less than a second, sometimes causing active calls to be dropped.  Different hardware and firmware versions but the symptoms are always the same.  TAC hasn't found anything yet, so I'm just trying to gauge if this is an issue others are having.  Thanks.

[Ratheesh Kumar]

Hi there

Not with 88XX. Below are the same behavior with 7900 phones

7942 / 7962 phones go off-hook and then on-hook 400 milliseconds later

Bug ID  - CSCto78441

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCto78441/?rfs=iqvred

Description

Symptom:
7962 phones are going off hook and then on hook 400 milliseconds later, which prevents the user from answering the call properly. This behavior can be seen in the SDI traces:

11:33:42.540 |StationInit: (0000030) OffHook.|1,100,49,1.584290

and then back on hook roughly 400 milliseconds later:

11:33:42.981 |StationInit: (0000030) OnHook.|1,100,49,1.584297

Conditions:
This can occur on 7942 or 7962, and is more likely to occur when the phone is sitting at a steep angle and especially with a sidecar attached.

Workaround:
1. Invert the wall mount tab to be in wall mount mode.

2. Reduce the angle at which the phone is sitting by two notches. This may not be possible if a sidecar is mounted.

3. Do not use a handset, use only a headset.

4. Open a case with Cisco Customer Service or Cisco Technical support to have the affected handsets replaced.

Hope this Helps

Cheers
Rath!
***Please rate helpful posts***

[awood@firsthealth.org]

Has there been any update to this issue? We are having the same issue with a couple of phones on our network, one actually on the network and the second one registered back thru the expressway. 

[Andrew Skelly]

We had Cisco AS out to one of our sites to observe the issue.  They saw it first hand and recorded the issue to confirm it is happening.  They sent the offending phones in for hardware analysis.  Their conclusion was that there was corrosion on the hook switch.  Whether or not that was the cause of the issue for the dozens of phones we had/have with this problem I cannot say, but the one that they analyzed had corrosion on it.

[Anthony Holloway]

I can't help but click the Chuck Taylor logo.

[Greg Decroo]

Any additional updates on this condition?  We have this issue with Cisco 7841 phones running Firmware load sip78xx.12-5-1SR2-2 on CUCM Version 11.5.1.16900-16.  (Phones were purchased new almost 3 years ago)  This mostly happens with users who are working from their home so it is registering through our MRA server.  Once it starts to happen on one of the phones nothing seems to make it stop going off-hook and back on-hook continuously.  We have recycled the phone power as well as the home router that it is plugged into as well as resetting the phone back to Factory defaults) This is very disruptive for the user - especially UCCX Agents who's Finesse state continuously changes from Ready to Off-hook and then back to Ready.  

I end up shipping the Remote user a different 7841 phone to resolve the issue.  Once I get the replaced phone back and I plug it into our Corporate Network the phone seems to start behaving normally again.  Unless I'm just not giving the phone enough time to fail again.

[Ritesh Desai]

Hi,

Why are you using Cisco Hardphones not Cisco Jabber which is much easier to manage in my sense rather CP-7821.

I am seeing such a scenario first time so would not be able to comment much.

Just curious, does the agent able to login to Finesse using that phone?

[Greg Decroo]

For a small percentage of Agents that prefer to use a hardphone we have their hardphone configured as the Associated device in the CUCM RMCM Application user so their Finesse client controls their deskphone.



We use a mix of both Jabber and Deskphones with the large majority of Agents using their Jabber Softphone.



GD

[Andrew Skelly]

Easier to manage?  Perhaps.  Much more susceptible to audio quality issues?  Absolutely.  Jabber is fighting for laptop/desktop resources (cpu, memory) with everything else running on the machine.  A hard phone isn't.  For an agent taking customer facing calls you want the best audio experience possible and you are most likely to get that from a hard phone (as long as it doesn't keep going off-hook/on-hook and dropping calls).

[jschweigert1]

Not everyone can use a softphone.  If Cisco offers an option for using a physical phone off network (MRA) then they need to make it work.

[Andrew Skelly]

No additional updates.  Cisco is sticking with the "corrosion" theory on the handset terminal.  Ironically we are seeing this predominantly at work at home phones as well.  We were able to recreate in the office when we had a defective phone sent back in.  Replacement of the phone has been the only fix.

One way we have been able to see the on-hook/off-hook issue is by looking at the console logs on the phone itself. for "is_onhook".  One of the phones we saw with this had 27 instances of this in 3 minutes.  A value of 0 means the phone is NOT onhook and a value of 1 means the phone IS onhook.  So 13 times in 3 minutes the phone went offhook.  This value only appears when the phone goes off cradle, not speaker or headset.

[DAVID BURKHART]

This is happening to 7821 phones in my environment. I replaced an offending phone and plugged it up in my office. On the second day I heard dial tone off and on then realized this phone was acting up as reported. I wiped the config and the behavior stopped - until the next day. Still looking for a resolution. I've been running the same version of CUCM (11.5.1.18900-97) since 2016 and this issue has only presented on these relatively-new 7821s. 

[jschweigert1]

I have identified that this ONLY happens through MRA.  If I move the phone that is faulting from our external test network to our internal corporate network, the issue goes away.  This issue appears to be isolated to MRA phones, so I'm suspecting something with the Expressway's, but can't prove it.

[jschweigert1]

Our organization uses the 8811 phone.  I have noticed that for us the issue does not happen for any onsite phone, but only with our MRA phones.  Do you have the same problem or are you also experiencing this on your corporate network? 

I have tried many different firmware loads and none resolve the problem.  I've opened 2 TAC cases and they have basically refused to look into what is causing this.  I also reached out to our Cisco Territory Account Manager and Cisco does not want to take any of our faulting phones to send to the BU to try and find the root cause. I found that if the user only uses either a headset of the speakerphone, if I have them remove the handset and cable from the phone (see photo), the issue stops.  

If Cisco is saying that there is corrosion that is causing the issue, why is this happening to many phones across the world throughout different organization?  Sounds like an excuse to me.

[Joshua Lamb]

It makes sense considering we have had hundreds of phones now at this point with this same issue 8851 and 8865 having this issue, all fixed when upgrading firmware and disabling the handset. If it is affecting MRA only for you, possibly this is a different issue or perhaps you get more use out of your MRA phones. 

For us it is affecting phones no matter the location.