I2004 sets fail after approximately 1 hour of no use

[ledfordb]

OK team,
I try my best to only post unusual happenings. I need you guys input, so here goes.

1. Do Nortel VOIP phones support RSTP on the network? We have a flat network with no routing between the sites for this VLAN.

2. The VLAN that the VOIP phones is private to only the VOIP phones. We have 5 VOIP phones on that network at this time.

3. If we put a laptop on the VOIP VLAN it can ping the PBX room from the far site in less than 1ms without missing any pings.

4. The first call in or out has no voice traffic. The call rings on the cell phone but dead air for both parties when call is established.

5. Both parties can tell that the phone was answered because the ring cycle stops.

6. If you call the person back, everything works great on every call inbound or outbound. If you let the i2004 sit in an idle condition for about one hour the problem returns.

7. If we set up a laptop pinging the PBX in a loop all the VOIP phones work all the time.

I am very open to suggestions, I appreciate your help more than you can imagine.


Thanks

 

[acewarlock]

Use something like

http://www.nagios.org/

it can monitor and ping all the IP's to keep them alive.




This is a Signature and not part of the answer, it appears on every reply.

This is an Analogy so don't take it personally as some have.

Why change the engine if all you need is to change the spark plugs.

 

[ledfordb]

Thank you Ace,
Is this the easiest fix for this timeout problem? Is it commonly programmed up in this manner?

Thanks again!!!!

 

[acewarlock]

I've never heard of that problem before, maybe Monday someone else will see this and have a better answer.




This is a Signature and not part of the answer, it appears on every reply.

This is an Analogy so don't take it personally as some have.

Why change the engine if all you need is to change the spark plugs.

 

[ledfordb]

Just a wild shot here but I have read where all Nortel IP sets have an internal watchdog timer.
The timer is defaulted at 200 seconds. It is reset by the TPS every 100 seconds and finally the display updates every 30 seconds.
If the IP set fails to acknowledge these or any other messages within 400ms, the TPS will register the IP telephone. Maybe I have an firmware release issue?

Also, should I have DHCP set to off and hard set the IP and subnet addresses?

I'm fresh for any advice.....my brain has been strained...

Thanks again!!!

 

[911guru]

You are sort of correct. 200 second watchdog timer in the phone. If it gets to zero the phone reboots. The TPS sens a reset every 100 seconds, and a display update every 30. If either of those is not acknowledged, then the TPS de-registers the phone.

At that point the watchdog will not be updated anymore and the phone will reboot. You seem to indicate that the phone is functioning, it;s just that audio is not passing after an hour. Here is my assessment:

You can initiate a call, therefore you have to assume that the phone can see the TPS, and the TPS can see the phone. No issue there. The issue seems to be with peer to peer connections. That is the patch that the audio takes. Therefore you have to assume that the 2 phones cannot see each other. There is no ack on audio packets.

It smells very much like a NAT issue, although I understand you think you have a flat network. Something is amiss in the network I suspect.

911Guru

http://pbx-e911.com

 

[DaddyOfThree]

Hmmm... it sounds to me like you have a ARP/FDB issue in our core network. As explained by ledfordb and 911guru the Nortel IP Phones will automagaically reboot themselves if they don't receive the heartbeat from the Nortel Succession Signaling Servers or Survivable Remote Gateway (SRG).

Next time the problem occurs check to make sure that your routers (or layer 3 switches) have an ARP and FDB entry for the Nortel Succession equipment (Call Server and Signaling Servers - primary and standby if you have two - and any Voice Gateway Media Cards). It sounds like the laptop is causing the network to populate the ARP/FDB tables keeping your connection alive... once it stops the ARP/FDB entries time out and then the phones are unable to communicate with the Succession backend.

You might want to check all your VLANs (including the PVID on each port) to make sure you haven't mis-mapped something somewhere.

Cheers!

 

[Triton101]

Have your IT people check your LAN switch port for your VGMC TLAN connections, make sure that the ARP tables are not being flushed took quickly. See if they can see the MAC address of the VGMC TLAN port after an hour...

Make sure it's not your VGMC that is not the issue, the DSP resource is from the card.

Your mentioned "if we setup a laptop to ping the PBX all the time all VOIP phones work all the time"

PBX does that mean you are PINGING the ELAN IP of the Call Server???? I don't see how that would help the DSPs and phones... since they communicate on the TLAN and not ELAN....

 

[ledfordb]

Thank you team. I will investigate this further and see if I can isolate this failure. I will post with results or more confusion.

Thanks again!

 

[TMCTech]

We are having the same problem at our location. We had to reboot our switch due to a UPS problem. Our local support tech had loaded the latest patches a few months back but the switch was never re-booted to get them installed. Se when the switch came back up the patches got loaded and we started having the same problem that ledfordb is describing.

One of our users figured that by placing the "dead air" call on-hold and picking it back up she could get the connection made.

We have opened up a ticket with Nortel but so far we have not received a solution.

These are the patches we have loaded right now:

VERSION 3221
RELEASE 4
ISSUE 00 T +
DepList 1: core Issue: 11 (06/08/21:20:00EST) ALTERED

IN-SERVICE PEPS
PAT# PRS/CR PATCH REF # NAME DATE FILENAME SPECINS
000 Q01235569 ISS1:1OF1 p06000_1 14/03/08 p06000_1.cpp NO
001 Q01255995 ISS1:1OF1 p06002_1 14/03/08 p06002_1.cpp YES
002 Q01255995 ISS1:1OF1 p06003_1 14/03/08 p06003_1.cpp NO
003 Q00680586 ISS1:1OF1 p08657_1 14/03/08 p08657_1.cpp NO
004 Q0351495 ISS2:1OF1 p12996_2 14/03/08 p12996_2.cpp NO
005 Q00386768 ISS1:1OF1 p16532_1 14/03/08 p16532_1.cpp NO
006 Q00657710 ISS1:1OF1 p17353_1 14/03/08 p17353_1.cpp NO
007 Q00981727 ISS1:1OF1 p18139_1 14/03/08 p18139_1.cpp NO
008 Q00828101 ISS1:1OF1 p18240_1 14/03/08 p18240_1.cpp NO
009 Q01349231 ISS1:1OF1 p18450_1 14/03/08 p18450_1.cpp NO
010 Q00880139 ISS1:1of1 p18557_1 14/03/08 p18557_1.cpp NO
011 Q00871809 ISS2:1OF1 p18606_2 14/03/08 p18606_2.cpp NO
012 Q00891273 ISS1:1OF1 p18659_1 14/03/08 p18659_1.cpp NO
040 Q00992968 ISS1:1OF1 p19351_1 14/03/08 p19351_1.cpp NO
064 Q00985017 ISS2:1OF1 p19553_2 14/03/08 p19553_2.cpp NO