sjforcum

Hi All,

Here's the situation:

I setup a site with 60+ 9630 IP Sets. One of the units is apparently re-booting once or twice a day. It is the only phone in this environment which is experincing this behavior.

What has been done to date:

* We changed the telephone. Same behavior
* We removed the station programming and re-built it.
* Confirmed firmware
* Moved to different LAN port
* Confirmed 100/Full settings on both ends
* Ran new cabling to office (it's the next office over from the comms room, so length isn't an issue)

Here's where I'm starting to point the finger...

We took the set, immediately after failure, and moved it to another physical location in the office space. It has not failed again since. However the replacement telephone we put in the gentleman's office with bridged appearances of the published extension HAS had the behavior re-occur.

I'm saying it's network related, although I can't point my finger at what.

Has anyone else run into something similar?

TIA,
SJF

stubborne

Are you running inline pwr or a pwr supply? Has the pwr supply been replaced? I would replace all of the patch cables too (if you haven't). Could be bad pwr in the office, maybe try a small UPS. Sure sounds like an infrastructure problem..

__________________
Stu

PBXtech.info

 

sjforcum

it's running with in-line power.

I'm not on-site, but the on-site data engineers claim to have:

• Replaced ALL patch cables
• Moved the patch to a different port on the Cisco POE
• Hardset the phone and Switch to 100/FULL
• Moved the patch to a different drop within the gang
• Replaced the telephone
• Reporgrammed the station in CM
• Moved the faulty telephone elsewhere in the office, put a new phone in the "mystery" office with bridged appearances...the "defective" phone worked without issue in the new location, the phone in the mystery office had the behavior re-occur.
• Ran a new drop from the comms room to the users office and certified the drop. After the new drop was installed the behavior stopped for approx. 3 days....
• We just suggested a separate power brick this morning.

Like I said...I'm still pointing the finger at the network / cabling...but since it's an Avaya phone failing, they are still kind of pointing the finger at us....

stubborne

I think you proved it's not an Avaya phone issue when the problem is isolated to a room, not a particular phone. Good luck!!!

__________________
Stu

sjforcum

My thoughts as well....but I was told to be thorough....and I've run into instances in the past where this stuff came back to me...

fataldata

Plug the phone in directly to the router/switch to eliminate station cabling from the equation.

__________________
Systems In Use:
S8700 CM3.0 and S8710 CM3.1.1

PBXtech.info

 

oozenoz

Sounds to me like you may be picking up interference.

When they reran the cabling, did they put it into conduit or perhaps even move it to another area of the wall? Is there anything consistent about the time when the phone reboots? Any other equipment in the area that could be running/starting at the time the phone reboots?

Fataldata is right - take the phone from the room, plug it directly into the port you are currently using and monitor it for reboots to isolate the cabling.

__________________
- calvin

savvasc

We had a similar problem with another type of phone. We finally found that the switch was overheated. As soon there was overheat the phones getting the power from the specific switch were rebooting. Try another switch as well , and also try local power

sjforcum

Hi Guys,

After travelling from Boston to New York City to personally troubleshoot this thing, I found and did the following:

The phone was running on a local power brick.

The new data drops were located right next to the old drops. Between them were electrical drops. There isn't really much option since most of the office is glass....

The switch and CM were both logging loss of connectivity errors at the same time...

So here's what I did:

We cut the phone down to 10/Half.
We setup monitoring of the PC*. If it's wiring, in theory we should see the PC drop at the same time.


The phone has not had a failure since this change to 10/Half.

I'm trying to determine if fighting to get the cabling issue corrected is worth the hassle. The phone seems to be responding normally at the lower speed. Has anyone had any experince running these phones at 10/Half? What type of degradation can I expect? The user hasn't complained and he's somewhat phone intensive....

*Up until I was on-site, no one believed me that the user might not even NOTICE his LAN connection bliping...we did a test by plugging and unplugging his NIC. Nothing other than a small balloon on the bottom of his screen popped up.

oozenoz

This is quite possibly the source of interference - could have been there with the old drops but never detected. As we all know, short hiccups may never be noticed by a user; they may just complain of 'slow connections'. Degraded performance due to errors won't cause XP to show the cable disconnected as your test did.

Your users will not notice any difference at all between 10/half and 100/full. Just because the lines are configured at that rate doesn't mean you're ever sending that much data... A G.711 VoIP connection uses less than 90K in a single direction. Throw in a little silence suppresion and compression, and you reduce the bandwidth requirements quite a bit. (Afterthought - I do want to clarify that this applies only to the phone connections - if you were to set your PBX gateway connections into the LAN to 10-half, you could experience problems if the total user traffic exceeded the total cacapcity on those segments.)

__________________
- calvin