I have had this problem in three offices starting in 2013. And it just happened to me today in an overseas office. This problem can remain hidden in your telephone system for years and not be a problem because it’s so rare for a phone to get assigned a new IP address via DHCP.
Basically, a phone reboots for some reason. When it comes back up, there’s no dialtone. Or, if you have more than one gateway, you might get intermittent dialtone.
In my network, these items were also true:
- The gateway and the phones are on the same subnet
- The phone was assigned a different IP address when it rebooted (this may not be obvious since you don’t always know the phone’s previous IP address)
If you have more than one gateway, the problem might seen intermittent. you can “list trace station” and watch the phone pull dialtone:
12:19:49 G711A ss:off ps:20
rgn:1 [10.9.10.90]:39798
rgn:1 [10.9.10.3]:2094
That IP address on the third line – that’s the gateway assigned to serve dialtone for this call. In my case, I have a gateway in the local office, and a gateway in the datacenter. Whenever the user said “hey, there’s no dialtone!”, it had drawn a resource from the local gateway in the same subnet. The phone worked in all other ways – there was just no media.
There are MILLIONS of Avaya forum postings regarding no dialtone, one-way audio, etc. In my case here, the problem was caused by the arp cache in the G450 gateway. That’s pretty obscure. The IP address changed, but the MAC address in the arp cache did not change. So the gateway is trying to feed dialtone to the wrong MAC address.
The fix was simple: log into the G450 and issue these commands:
- ‘no ip arp inspection‘ (this disables arp caching)
- ‘clear arp-cache‘ (this clears the arp-cache, which sounds scary but will not affect service)
- ‘copy run start‘ (this will write the settings to flash memory to survive a reboot)
That fixed the issue of no dialtone. It did not fix the issue of phones rebooting and getting different IP addresses though. I will write a different post for that, since it was a completely unrelated issue.
I hope this helps! Please let me know if this works for you.
Roger
Hi Roger, I have all new Avaya 9608G phones with an IP500v2 Call unit. We had older Cisco CE500 switches that required us to do switchport mode trunk on all interfaces that a phone was connected to, but if we had a power outage, all interface would revert to switchport mode access. Never could get it resolved with all the Cisco Guru’s. The switches have since been replaced and now how should we configure the newer Cisco 2960 switches? Is switchport mode trunk still a requirement? My assumption would be yes since a PC is plugged into them. I have tested and across a reboot the command stays so that is resolved. But I have been reading that not to use lldp and dhcp option 242 together since it will confuse the phones? I have this strange issue now where the phone will say “Request Error Please Wait” The red light for the line will disappear and no dialtone. The at top of phone screen, it will say “retrieval in Progress” then “Retrieval successful” and I will get a line light again and dial tone again. It keeps cycling thru this process over and over. I have a video I would like to share if it would help.
Wow Jerry – that’s amazing because I am having a similar problem at one of my client’s sites. They are also describing four beeps during a call, and I am also getting “08:43:45 denial event 2054: Signaling CONN Congestion” during the “list trace ras ip-station xxxx” as the phone logs in. Could you try a list trace and see if you also get a denial event while that is happening? You can also email me at roger at rogerthephoneguy.com if you’d like. Good call with lldp and dhcp options simultaneously. I’ll check with the network team and see if lldp is enabled. Sounds like we can tackle this together.
I’m using 9630s exclusively, and the “file retrieved please wait” message stays at the top of the phone and doesn’t go away.
Hi Roger, I am a total Newbie when it comes to Avaya. LOL Can you tell me how to do the List trace? Thanks!
Oh no problem. Unfortunately, you cannot use the typical Avaya Site Administrator interface. You have to do terminal emulation. I always SSH to my PBX and you can do it through the PBX. At the command line you “list trace station 1000” and it will show you the events from the phone.
However, I spoke with Avaya this morning and they tell me the “file obtained, please wait” is a corrupt settings file. It’s a long shot, but you could delete the settings file from your http server and let the phone regenerate it. Do you know where that is? You can ask the phone by pressing menu, network information, and maybe right-arrow. Somewhere in there is the “HTTP Server” setting. That will tell you what web server is feeding the config files to the phone. If you delete the settings file for your phone, it will rebuild it next time it writes its log (when a call is finished).
BTW, the “Request Error” message is on this page and we have only 1 call server.
https://downloads.avaya.com/elmodocs2/one-X_Deskphone_Edition/R1.5/output/16_300694_4/96xxinstall056.html
Roger,
I understand that the 46xxsettings.txt file that resides on the file server could be corrupted, or that the copy the phone received was corrupted in transmission.
Your comments confuse me for two reasons. First, I do not understand how deleting that 46xxsettings file from the File Server would prompt the phone to create a new settings file, or even new settings. I believe the phone would simply boot up with either just the handful of generic settings, or worse simply remember the old (possibly corrupted) values. It would take clearing all the phone’s settings to ensure nothing bad was still being remembered, by invoking MUTE, 27238# and then the CLEAR option.
Secondly, a phone only downloads the 46xxsettings file at boot up. I’m pretty sure it does not download the file the next time the phone rewrites its call log file.
Finally, a 96xx series phone should be able to receive information from both LLDP (typically a VLAN assignment), AND Option 242 information from a DHCP server. If the phone receives conflicting information, then the general rule is that the last value it received is the one the phone uses. If the use of both of those sources of settings causes problems, I would suspect a bug in the phone’s firmware and advocate changing the firmware.
If I have misunderstood the issues, please let me know.
Hi John! Good questions and I’m sorry about the misunderstanding – I probably screwed up the post somewhere. I’ll check it out and try to make it clearer.
What I meant to say is the phone will regenerate it’s personal data file – the one like ‘2099_96xxdata.txt’ in the backup folder. Once in my environment we had a network outage and a couple phones wrote a partial file to the web server. Later, when the phone loaded this file, I lost dialtone. The other time, the hard drive filled up on the web server and one poor phone wrote a partial config as the last bytes filled up. Then later, it loaded that partial file and would not work. Of course, if the phone gets a phone call and writes again, then it will be fine. These two cases were special in that they wrote a bad file at a bad moment, and did not write again once the issue was fixed. Somehow, they rebooted or were logged in somewhere else, and that phone read the incomplete file. Anyway, it’s EXTREMELY RARE and I obviously explained it badly. Sorry about that.
As for the 242 option, I’m fortunate that my network doesn’t seem to have any LLDP info so I guess I’m good. But strangely I have a phone that seems to have pulled option 66. It’s another strange case and I’m not sure if it’s worth writing about. It’s only affecting daisychained phones. Thank you SO MUCH for your input and for reading about all of this madness!
Since we’re on the subject, do you know the difference between CLEAR and RESTART PHONE? I assume CLEAR only clears out the DHCP cache and IP settings, and RESET VALUES clears everything else? Also, is there a MUTE # code that will reboot the station? So it’s a little faster than MUTE CRAFT # and reboot? Thanks a bunch! Roger
Roger,
Ahh, now I understand the guidance you offered in your post. You were talking about the phone’s personal data file and I misundersood that to be about the settings file. Thanks for clarifying it!
Since DHCP Option 66, which gives the IP address or the hostname of a single TFTP server, is a public option, and because Avaya tries to follow the standards, I’m not surprised that an Avaya phone would capture it if the DHCP server automatically offered it. I believe many VoIP phones, including Cisco (?), rely on Option 66 to identify from where to download their configuration files. In contrast Option 242 (and Option 176 before that) are intended to be vendor-specific (i.e. used only by Avaya endpoints)
In our classrooms, we often need to wipe the phone’s settings because it won’t let go of outdated/bad settings. I have tried both CLEAR and RESET VALUES and cannot see any difference between them. However, I literally just stumbled on documentation that suggests that a CLEAR wipes out everything, and the RESET wipes out everything except for the extension number and password. I’ll need to test that next month.
I assume you are looking for a menu option to wipe out the phone’s settings. To cause a phone to reboot, I find it fastest to simply unplug it.
I believe only the 16xx series of phones had the ability to directly wipe out the phone’s settings through a phone’s keypad command (i.e. Mute 2 7 2 3 8 7 3 7 3 8 # (Mute C R A F T R E S E T #) ). For the 96xx series of phones, one must log onto the phone’s administration menu (MUTE, 27238#), and then scroll down to the CLEAR menu option.
And thank you for providing this and so much other useful information. I LOVE your “Flowchart of Avaya Routing”. I included it (giving credit to you) in one of my presentations at the last IAUG in Orlando.
John I am SO FLATTERED that you shared that flowchart with IAUG!!! Thank you!!
And it means even more coming from you, who obviously know a TON about Avaya. It’s even more meaningful now. Thanks for the comments about SIP also. This blog is even more valuable when you comment like that.
Feel free to email me any time at roger@rogerthephoneguy.com if you have any suggestions about posts or even if you’d consider writing an article here.
At the moment, I’m really struggling with intermittent one-way talkpath. This is the bane of supporting VoIP, and I think I spend more time trying to demonstrate it is the network and not Avaya more than anything else I do.
Thanks for reading it, and huge thanks for sharing it. I’m really touched.
Roger