Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

5220 IP phone. Waiting for Comms 1

Status
Not open for further replies.

Mitelpassion

IS-IT--Management
May 2, 2005
1,153
ZA
Anyone seen this issue where the IP phones boots and just "sits" on "WAITING FOR COMMS"?

Again this phone worked fine up till this morning?

Regards,
Eugene
 
Your phone can not "talk with your ICP."

We need a lot more information. What you have just said is "my car does not work!" How is your network setup? Where is the phone, compared to the ICP. What are you using for DHCP? Has anything changed on it. The more info you post, the more willing people (techs) are in helping you.

You will learn very quickly on this board, and any other telecom board, if you don't provide details, no one will help you.
 
What platform (3300/200) ?

A few months ago I had an incident with a 200ICP where a nearby lightning strike paralyzed every IP phone in the place.
All the TDM phones still worked and there were no alarms.
Resetting the IP phones also did nothing.
The customer ended up power-cycling the 200ICP & all was well.
 
DPLite sets (Dual Mode) will do this on a pre 5.2 system (speaking 3300 here). But you say the set worked fine this morning, so I guess it's not a replacement set.
 
well normally it doesn't get to the waiting for commission until the firmware updates so it must be talking to the icp.

Matthew McGowan
Reynolds Park
 
MATT85:

1st) what is "waiting for commission"? Never heard that one.

2nd) what makes you say "it must be talking to the ICP?" Are you saying once the phone gets its firmware it has to work? (I think that's what your saying?)
 
Ok. I didn't figure to provide more info, as nothing had changed and the phoned worked fine up till this morning.

I guess what I was asking is what does "waiting for comms" mean. I thought it was merely the phone waiting for the controller to take control and that it's already aware of the ICP and knows it is there.

Anyway the voice network and data network are two physically segregated networks. there is routing between the two and this is done by a core switch. DHCP resides on the ICP.

I haven't cycled the 3300 yet but will schedule a reboot tomorrow.

Thanks for the help all.

It's on a 3300 release 6.1
 
TheMitelGuy:
1) well i don't really remember if waiting for commission appears when its on the local network because the phone boots up so fast but when i use the teleworker 5220 i see the phone download the firmware then it says waiting for commission, which my guess means the icp is in the final process of registering the assigned extension.

2) it must be communicating somehow if it is getting an ip from the DHCP(if in fact using the icp for this) & its downloading the firmware, but i'm not sure because mitelpassion didn't say, and no i'm not saying it must work because obviously its not. I was just giving my thoughts. :) i'm not sure why this is happening.

maybe make sure in form 9 well i mean i don't know what it is on a 3300 but look in the desktop device assignments form and make sure everything is still inputed correctly for that phone if its just one phone i'm assuming. but then again it should still ask you for the pin # if its not registered. also i know in the maintance terminal in the 200icp you can reboot all the IP phones without having to reboot the whole system if that makes it any easier. and if that still does nothing go ahead with the full system reboot.

Matthew McGowan
Reynolds Park
 
NO DO NOT GO AHEAD WITH A FULL SYSTEM BOOT. That is not the proper way to correct this problem. You should never have to hard-boot your ICP (3300 is exempt for your daily courtesy).

"WAITING FOR COMM" refers to "WAITING FOR COMMUNICATION" NOT "WAITING FOR COMMISION." I have no clue where you learned that from?

"WAITING FOR COMM" means the following:
- The phone has a valid IP address and subnet
- The phone has been instructed where to download the firmware (FTP) from the FTP server or the ICP (75% this is the ICP it's self).
- The phone has applied that new firmware, if required.
- The phone has a IP address of what it is TOLD is the right ICP (shown in as option 129 in your DHCP scope options. **this is where your set is locking up**

You can assume one of the following issues:
1) The phone has no path (TCP/IP) path back to the ICP (i.e. cable, router, switch or firewall issue). This could be as simple as the cable not being connected somewhere as well...

2) The phone's DHCP address has expired and the DHCP server did not offer a new one with the same scope options (very possible).

If you reboot the phone, do you get a "WAITING FOR COMM" screen or does the phone boot right up? Also, what is your ICP, 3300 or SX-200?
 
Had the same problem last month on a 3300 V6.0.5.8.

I caused the problem by deleting the user, the phone (5215) then rebooted and said waiting for comms.i then tried it on another phone and the same thing happened.

A simple reboot fixed the problem.Mitel said the mac address of the phone must have got stuck in the cache!!

i dont delete users anymore only renumber
 
Hi Alfred,

I did excately that. And yes the mac address DOES get stuck in cache. I also had a 5550 console acting up. tried reinstalling it and couldn't.

I also deleted a device and recreated it. However when the phone booted up it remembered it's extension number and worked just fine. When I looked in the config, the mac address for that DN was blank! Go figure... A reboot also fixed all my problems I had on this site.

Clearly release 6 somehow cache the mac addresses.

REgards,
Eugene
 
good that the problem has gone. i will have to try it on V6.1 to see if the same thing happens
 
Did you try to clear the pin on the phone after you changed/deleted it on the 3300?

Cache is not a known issue?
 
The MAC address HAS to be cached in the controller if it is acting as the DHCP server. Another thing to try would be to go into the DHCP client listing (can't remember the name of the form off the top of my head) and delete the instance for that phone, and reboot the phone. You may need to re-register the set to that extension.
 
I had tried deleting the pin from the phone (holding star during power cycle?) and also deleted the lease for that specific phone under DHCP. Nothing worked.

In short I spent more that 6 hours trying various things. Things that should have had no bearing on my issues, but tried it anyway as I was desperate to fix my problem.

The reboot fixed all my problems I was having. My other post on this forum "5220 Phonebook that dissapeared" was also an issue on this specific site. The reboot too fixed this.

Regards,
Eugene

 
It's amazing how many problems I've been able to fix in my time in this industry just by re-booting whatever it was I was working on at the time. I've come to call this procedure the "technician's last resort" solution. Of course, if that doesn't work, you could always try a 15 lb. sledgehammer.
 
I find it sad to think that Bill Gates has succeded in convincing us all that power-cycling or "rebooting" our technology products is a universally acceptable method of troubleshooting and repair.

The problem with a shotgun approach like this is that we haven't "found the trouble or fixed" anything and in time grow apathetic.
Whatever obscure sequence of events caused our gadget to stop working in the first place is still there in the code and so will eventually bite us again.

Welcome to the computer age.
 
This has turned into an interesting conversation. If we (humans, and ultimately computer/software programmers), create better (perfect) software, we would not have to do that. As our software requests (which are features in the PBX world) get more and more, it becomes hard to create a bug free system.

Imagine if we only had DND, CF, and voice mail. There wouldn't be much to that system and would probably tick for ever without a reboot (oh wait, that's what we call a Key System?!?!?!?).

In my opinion, our software will get better over time. New features are always going to happen, but as we come closer to SIP (and SIP based routing) the features will either work perfectly or not at all, as they are industry standards (i.e. the feature will have to work to open standards, and tested to meet them!).

Just my two cents
 
My music on hold would not play Background music on the IP sets or during a transfer on anyphone or while anyone was hold. after a reboot the problem was fixed. yes its amazing now how everything is switching to OS instead of just circuitboards. my sx200 never needed a reboot or had the option.

Matthew McGowan
Reynolds Park
 
MATT85: That is not a bug...
____________________
From the manual
--------------------

Programming
WARNING: The music source must be programmed BEFORE it is connected. If it is not connected
when it is programmed, then do one of the following:
• disconnnect and reconnect the device
• remove and reinstall the card
• reset the bay
• reset the controller.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top