WAN Disruption Causes some 9641Gs to not "connect" 1

[demanding]

Using CM 6.0 and our 9641Gs are on 6.2209. We have found on occasion where after a WAN blip and the 9641Gs re-register, not all of them will fully connect. The phone appears to be fine, you can make internal calls but not external; ringer, call timer and other features may not work - not everyone is the same apparently. When I status the station, in the connected type field, it shows "N/A" instead of the phone model and the parameter download field shows "complete" as usual. Everything else appears normal. We reboot the phone - the field then shows the phone model and everyone works normal again. Our Vendor has found nothing wrong but still researching. Thoughts on this? Also - is there any way to see if phones are in this state other than a status on each one (some locations are pretty large). They do not show in an alarm state by the way.

 

[jimbojimbo]

Are you currently enabled for Time-To-Service on your network region?
Are the specific failed extensions rebooting and getting new IP Addresses? Possible ARP cache issue.
Is your logging set for IP registrations and what are you seeing in the IP Event logs?
Are you using CLAN or PE for registration? Possible simultaneous registration issue.
What CM Version/Service Pack. Should state CM6.0.1 SP<X> or update <xxxxx>.

 

[demanding]

Time-to-Service? Where is that noted?
Do not know if they are getting new IP addresses or not.
I'm not seeing anything out of the ordinary in the logs.
No CLANs. Reg PE.
CM VSN and Firmware noted above.

 

[smokinjoe2938]

sounds to me like a recovery rule is not in place on the network region form on page 2, that why the rebooting of the phone works as it forces it to reregister back to the clan or processor, hope this helps

acss sme acis sme acss cm 5.2.1 acss cm and cmm

 

[demanding]

I have a theory about this...does it make sense that since the outage occurred during business hours, it is highly likely the phones were in use (the ones we have had to reboot), the current call stayed pegged, and since the outage was a blip, the user did not notice it (I have experienced it in failover testing)...so when the WAN was good to go again after a few seconds, those users hung up and their phone was hosed?

We have had outages after hours where this does not happen...now we have had 2 during business hours and this has occurred...

 

[jimbojimbo]

1. Fix your WAN.
2. Look at the second page of the IP Network Region form. TTS is enabled by setting the Near End Establishes TCP Signaling socket to "y". Be aware this works with newer phone models and one-X Agent/one-X Communicator but is an issue with older hard phones and IP Agent/IP Softphone. If you have firewalls in place you will also need to open up the port for the TCP connection to reach the phone coming from 61440-61444(default) and going to 1720 or 13926. With TTS enabled the CM creates a TCP socket to the endpoint. This helps when there is a network issue or a system interchange.

 

[demanding]

That is already set to "y".

 

[wpetilli]

I've had issues like this when upgrading firmware. On the media gateway, clear the arp cache and then disable arp inspection. Not sure if that's what your issue is, but it's worth checking it.

 

[demanding]

Thanks - no entries in the gateway for the location with these issues. We recently had another WAN blip of a few seconds but as before, it caused a number of phones (35) to lose the "connected type" information and then the user's ringer would not work. You could adjust the volume, but it did not make any difference. The phone does not show any symbols either. A reboot fixes the problem but this is not always a good solution depending on the user's work needs at the time. Avaya is pressing us to do the usual "upgrade", "test", "grab traces" which we get, but other sites are not as severe as this one.