7900 Series Sidecars -- They don't work?

[danplacek]

We've had problems with 7900 series sidecars (and phones with sidecars on them) for some time. Recently this has been worse, and has given me the opportunity to research this across our customer base.

What I found:

7975 + (2)7916-24: We have 4 of these, spread across 3 clients. EVERY SINGLE ONE REBOOTS ON A REGULAR BASIS. Sometimes during calls, sometimes just randomly. Two of the three clients are experiencing it more often, but all of the phones reboot randomly. Firmware upgrades/downgrades do nothing.

7960 + (1)7914: There seems to be a bug where the labels on the sidecar are blank. We are experiencing this on 4 of them, spread across two clients.

We are not alone in this either: https://supportforums.cisco.com/thread/2148145

If you rearrange buttons... different ones go blank. We currently have a case open with TAC -- they have no clue. They requested we run "debug ephone detail mac xxx"... this crashed the customers phone system during business hours. In fact -- I have seen that debug crash the UC500 almost every time I have ever used it. (5+) I love it when even the debugs are buggy.

We tend to install more SPA phones (mostly due to cost), so there are relatively few of these in our install base. At this point it appears that every 7900 series sidecar we are aware of (or the phone they are attached to) are NOT stable. Has anyone had similar experiences? Or the opposite?

Thanks.

[Alexander Maroukian]

Hello Daniel,

Please try to do the following under the telephony service:

no create cnf

create cnf

I saw alot of  issues because the CNF files for the phones are not updated.

HTH,

Alex

*Please rate helpful posts

EDIT: Also it needs time to get the new info on the sidecar after implementing changes. Do reset of the ephone after implementing changes.

[danplacek]

Thanks Alex -- however we have done that and it does not help.

It might be worth noting -- on issue #2 -- the sidecar labels -- the buttons themselves ARE configured and DO work... the labels are just blank. The lights even indicate the correct status.

[Alexander Maroukian]

Hello Daniel,

I am sure that you have done it, but please try again after update of the CNF file to power cycle the 7960. Sometimes reset command does force the the phone to reload but it did not get the CNF file this is for 7940/7960 phones. When power cycled it does contact the TFTP and get the new CNF.

Best regards,

Alex

[paolo bevilacqua]

Go to phone user setting and adjust contrast for the module.

If that doesn't make the lables readable, the module is faulty.

[danplacek]

Paolo: It is not a contrast issue -- most of the buttons are fine -- it is only a few that are blank. I also doubt the sidecar is faulty, I can move it to another phone and it will work fine (sometimes). If I rearrange the buttons on the sidecar -- different positions go blank... so it is not an issue with the LCD. Please note, we have FOUR of these currently (at 2 different customers) and the thread I referenced is someone else having the same problem; I strongly suspect software is the issue here. I also noticed -- both of those customers are on UC520's.

Alex: Ok, I will give it another try.

Does anyone have any comments on the other issue? Does anyone have that combination of phone/sidecar installed anywhere?

Thanks.

[paolo bevilacqua]

That wasn't clear to me. I have plenty of sidecars anywhere and all do work perfectly.

Update both phone and sidecar firmware.

This assumes the UC500 is updated already.

[danplacek]

Paolo: Thanks, I will check their firmware versions, I am not sure if those customers have been brought to SWP 8.6.0 yet.

Do you have any 7975 + (2)7916-24 's deployed? That configuration in particular has been problematic for us.

[paolo bevilacqua]

Yes, I do have it at multiple customers, and as mentioned before, it works just fine.

As always with Cisco products, if something doesn't work good, is due to software bugs.

[Alexander Maroukian]

Just to add to what Paolo have already said - the firmware of the phones (7975)should be 8.3(5) and later.The current vesion of the sidecars 7916 - is cmterm-7916.1-0-4-2.

I can confirm 7916 is working on phones connected to UC500 I have seen it and tested it alot.

Best regards,

Alex

[danplacek]

For the rebooting 7975s:

Client A:

IOS: uc500-advipservicesk9-mz.151-4.M4b

7975: SCCP75.9-1-1SR1S

7916: B016-1-0-4

Client B:

IOS: uc500-advipservicesk9-mz.151-4.M4b

7975: SCCP75.9-1-1SR1S

7916: B016-1-0-4

Client C:

IOS: uc500-advipservicesk9-mz.151-2.T4

7975: SCCP75.8-5-4S

7916: B016-1-0-4

The same problem occured on older firmwares as well.

We have continually upgraded to try to get away from the problem.

I feel the need to emphasize as well -- we are only seeing this problem on phones with DUAL sidecars. (we DO have power bricks for both sidecars)

For the 7914 label issue:

Client A:

IOS: uc500-advipservicesk9-mz.151-2.T4

7960: P00308010200

7914: S00105000400

Client B:

IOS: uc500-advipservicesk9-mz.151-2.T4

7960: P0030801SR02

7914: S00105000400

Thanks.

[paolo bevilacqua]

You can have the TAC look at both problems. You will need a support contract for that.

I'd recommend you update to latest firmware first.

[danplacek · Accepted solution]

Paulo:

We get service contracts on all of our equipment.

For the 7975 issue: we have had cases open with STAC for about 2 years now (eventually they give up and close them). Still no resolution. I STILL have a L2 case open on the issue. Currently they want a permanent packet capture server installed at the customer site to do long-running packet capture of the phones. This is insane.

For the 7914 issue: I have a case open with TAC right now, they are doing some internal testing... no progress yet, but I am hopeful.

[Alexander Maroukian]

Hi Daniel,

For this reboots did you check for cabling or switch issue. Almost sure that you have tried it but want to be sure. The phones usually reboots when lost connectivity to the CME even if for very short amount of time. Did you try to connect  one of this 7975 phones to one of stable phones cable?

Best regards,

Alex

[danplacek]

We have replaced and verified cabling, yes. (Plus this is mulitiple phones, multiple locations)

The first customer originally had a ESW520, this was replaced twice. The first time with the same model, the second with an SF300.

The other 2 sites have SF300's. Switching out the switch has had seemingly no effect.

One REALLY weird thing has come up -- we were setting up to do packet capturing at one of the sites... somehow turning on port mirroring seems to have stopped the phone from rebooting... which makes no sense. This is not conclusive evidence, as it hasn't been mirrored that long yet... but it is definetely unusual for the phone to go this long without rebooting.