[cisco-voip] Traffic Issues with 7900 Series Phones

Tue Feb 14 13:55:21 EST 2017

All,

Just to follow up on this one, though it has been a long time…

While the details on the whole thing are very slim, TAC was able to actually reproduce the issue we were reporting on the 7941/61 and G-GE flavors of phone. Phones that receive “too much” traffic (somewhere in the order of billions of packets) seem to fall apart, which results in poor audio quality internal to the phone (jitter/loss not seen in captures before or through the phone), high ICMP echo latency, delay in functionality, etc – until the phone is power cycled. Clicking “Reset” in the UCM does nothing to fix this. I have one site where this occurs frequently, and another with similar behavior issues but the condition seems to be transient.

Unfortunately, I don’t have a confirmation if this is a hardware or software issue, but, this conclusion was reached only just after the 1/31 end of software support for these models, and given the hardware end of support dates being long ago, the issue will not be fixed. It is implied it is a hardware issue, but we don’t know what actually is going on in the background on the device. Something with the nature of the traffic that these phones are exposed to (volumes? Types? Sizes?) is a problem, and the 7900 series, save for the 7945/65/75 and the 7916, are dead and done.

The recommendation has been to move to the 7800/8800 series of phones, which will not be a cheap nor prompt fix, but, if you all are still chasing this sort of issue, unfortunately, if it is the same as ours there is not much to be done it seems.

Regards,

Adam Pawlowski
University at Buffalo

From: Stephen Welsh [mailto:stephen.welsh at unifiedfx.com]
Sent: Tuesday, November 08, 2016 12:59 PM
To: Pawlowski, Adam
Cc: Executive; Wes Sisk (wsisk)
Subject: Re: [cisco-voip] Traffic Issues with 7900 Series Phones

Hi Adam/Wes,

Thought it may be of interest Wes so copied you in.

We got confirmation from another client that they have an issue that causes their phones to unregister (reset as far is we can tell) when taking a screenshot (using PhoneView or manually with the direct URL on the phones web page http://[PhoneIP/CGI/Screenshot]).

The client had an issue on the 7962 running SCCP42.9-4-2SR2-2S, specifically when using a hostname for the AuthenticationURL, when he changed it to an IP Address it resolved the issue.

I suspect this may be a firmware bug (possibly a new one), but it may also have been an issue with the host(s) the hostname was pointing too. However this is the first time we have seen this behaviour and the phone should not un-register just because it cannot communicate with the authentication server.

Kind Regards

Stephen Welsh
CTO

[cid:image001.png at 01D286C9.FB1A02A0]

On 4 Nov 2016, at 20:37, Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>> wrote:

Hi Stephen,

                We are a PhoneView user certainly. If you are accessing the phone web server we have noted that it will cause other operations to be missed that involve it (XML anyways) . We aren’t running an idle URL here, nor is our homegrown user location polling script running, as far as I am aware – but I will check. If there’s some information we can provide that would be useful to you, or that we can look at here, we can work on that sure. We’re on 9.4.2SR1-1, testing 9.4.2SR2-2 to the same result. I have not tried to roll back to a previous version, but I am having flash backs to off hook autodialing and expansion module crashing issues that I certainly don’t want to go back to.

Regards,

Adam

From: Stephen Welsh [mailto:stephen.welsh at unifiedfx.com]
Sent: Thursday, November 03, 2016 2:13 PM
To: Pawlowski, Adam
Cc: Executive
Subject: Re: [cisco-voip] Traffic Issues with 7900 Series Phones

Hi Adam,

I believe your organisation is a PhoneView customer, we have a recent support ticket that may be related to this issue, he describes issues with the phone responding when taking screenshots (i.e. accessing the phones web server), I wonder if this may be a new bug introduced in a new version of firmware.

Happy to host a WebEx session to investigate.

Kind Regards

Stephen Welsh
CTO

<image001.png>

On 2 Nov 2016, at 18:22, Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>> wrote:

After much hair pulling and frustration, I wanted to ask the group here in case anyone has seen this or has any thought on what we should be looking for.

We have a number of 7900 series phones that have been exhibiting issues that appear to me to be that the phone is getting hung up on something. Some sort of frame or packet is screwing with the network chip/board or the OS which is causing it trouble. I see missed traffic, missed responses, high ICMP echo times - and phones that eventually get stuck with their ICMP echo response times being all over the board - with some report of call trouble and CMR showing crazy jitter. If I power cycle the phone that clears and it works fine for a while.

I realize these items are pretty much end of useful life, pretty much all done with software support, and are going to drop off of the compatibility matrix and probably functional support in the near future. But, while we still have a ton of them - has anyone noted any particular type of traffic that causes the 7900 series phones grief?

I don't have loss on the network, there do not seem to be any transient broadcast storms rolling by. We do see an increased amount of mDNS, IPv6 (phones are v4 only) etc, but nothing stands out as causing a particular problem. It just seems that whatever this is, is causing a memory leak or something, wherein it gets bad enough that things go to hell eventually.

Any thoughts?

Adam P
SUNYAB
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170214/c4b7de95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1364 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170214/c4b7de95/attachment.png>