IP Phone unregistration 1

[COUNTOLIVER]

Hi All,

Our customer has a 2LIMs TSW SP4.
28 Elu32 are shared in both LIMs: 20 for IPTelephony, other all for IPNetworking.
System consists of more than 500 IP phones (DBC42x02)

During normal operation all IP phones go concurrently unregistered and the only way to regain registration is a board restart (RFBOI)
All ELU32 are R7A
Telephones are R2C/R6A/R3G.

Any Idea?
BR

 

[drewMk2]

Try changing the firmware of the handsets to R2D/R6C/R3H this may fix the problem.
I know I had an issue with handset's losing there registration for some unknown reason but I changed the firmware and it has helped...

Goodluck

 

[whosrdaddy]

The fault is on the ELU32 and is known. only way to fix this : use IPLU.
There is (or was) a swap campaign at E/// :4 x ELU32 -> 1 IPLU

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[COUNTOLIVER]

@ drewMk2:

Terminals experienced single per phones logout, so I upgraded them to R6A, until now this problem seems solved.
May IGMP determine multicast filtering so the ELU32 doesn't manage properly registrations until a restart?

 

[whosrdaddy]

COUNTOLIVER, the ELU32 boards WILL block after high load. the problem is not on the phone. seeing that you have so many ELU32 boards, do you have loadsharing active?

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[COUNTOLIVER]

Hi daddy,
Using previous FW version, sometimes, a telephone went to restart. We updated them to R6A and this problem seems solved.
The problem I still have is a simultaneous terminal unregistration.
About your question: yes, TMLOAD is set to 10 but I seen that "gatekeeper discovery" is disabled on phones.

 

[whosrdaddy]

using AGK will alleviate the problem, but your network routers must support multicast to achieve this.

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[drewMk2]

There is another thing you could look into if the problem returns...

I have had an issue with Cisco 3750 POE switches and phones unregistering. not sure if is relivent in your case but it could be switch settings.

check if there are set to 100mbs full duplex.

Just an idea for you....

 

[COUNTOLIVER]

@ drew

All ELU32's are set to ETHCNF=2, all switch ports are set to 100 Full.

 

[VinceWhirlwind]

Speed/Duplex settings are completely and utterly irrelevant to GK registration.

If you have a problem with duplex settings, you will find errors on the switch and phone interfaces.

If you have no errors on the interfaces, you have no problem with speed/duplex settings.

If you actually bothered to do a test-lab setup before drawing these sorts of wrong conclusions, you would see the effect that a duplex mis-match would have on GK registration (none, think about it: what's the time-out on registration when the phone's at rest?) and on Voice Quality (ticking, buzzing, "static", etc...).

The scary thing is you've probably been giving your customers this sort of dud info, which reflects badly on all of us.

 

[drewMk2]

it was suggestion and any way what I originally suggested fixed issue didnt it??????


I have had IP to IP calls drop mid-coversation...
IP to IP calls are direct media and therefor have alot to do with the switch...

check that in your lab!

"There is no place like 127.0.0.1

 

[VinceWhirlwind]

Absolutely - your first suggestion was spot-on.

I just think it is very important that people in the proper process of fault-finding shouldn't be distracted by untechnical red-herrings.

Not everybody here understands IP networking (ie, our customers), and your later (terrible) suggestion has the capacity to mislead those people.

Running IP calls over a link/interface where there is a Duplex mismatch does not "drop" the call. Try it yourself. It's a very easy test.
When you've observed how IP telephony behaves across an interface that is erroring due to collisions, etc, you'll understand what I'm on about. Ditto with congestion.

"Dropped" calls are down to signalling - you can't cause it by losing a few packets - somehow, a tear-down is being received where it shouldn't, and your network switch can't send one of those.

As far as dropping a *lot* of packets - a network failure will show up in your monitoring and drop a lot more than one call!

 

[COUNTOLIVER]

Hi all.
The problem was a "storm" from a Server on the network segment where all ELU32s are installed.
This server sends an ARP Request to 255.255.255.255, all phones try to answer, then they go to unregistered, all ELU32s have same behavior but they remain like dead.

 

[whosrdaddy]

COUNTOLIVER,

the ELU32 board cannot cope with that amount of traffic (and the board crashes, this is a known fault). try to prevent broadcast traffic towards these boards.
other solution: use an IPLU board instead of the ELU32.

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!