A key aspect to troubleshooting Cisco IP Phones is understanding how they boot up and register in the first place.
This post is written with the explicit intention of simplifying the process as much as possible.
Let’s get started.
Below is the simplified topology we will be using to illustrate the process. It is likely that you will experience a network having multiple Call Manager servers, but I have kept it simple and only included one.
Also note that the Router won’t really come into play much here, but has been added for completeness (and also because I think it looks nicer).
The Bootup Process
Knowledge is power, but knowledge wont power your IP Phone.
For that you will need to ensure that the Switch it is connected to is Power over Ethernet (PoE) capable.
As the name implies, this means that the Switch is able to power the IP Phone via the Ethernet cable connecting it.
If the Switch is not PoE capable, then an external power unit must be used.
At this stage, CDP detects that the connected device is a Cisco IP Phone and send its information on which Voice VLAN to use.
Now the Phone is powered and on the correct VLAN, it will request an IP to the DHCP Server.
DHCP Request + Option 150
As the Phone makes a DHCP Request, it also receives something from the DHCP Server called Option 150.
Option 150 is additional, specific information given to Cisco IP Phones which includes the IP address(es) of the TFTP Server which the Phone must contact in order to retrieve its Configuration File.
The TFTP Server will be the Call Manager server designated as such.
Firmware/Config File from TFTP
The Configuration File received from the Call Manager server contains information required by the Cisco IP Phone to work with the Call Manager itself.
For example, this information includes but is not limited to:
- Date/Time settings
- XML Service URLs
- Firmware version
It is important to note that Cisco IP Phones come pre-loaded from the factory with firmware installed. While handy, this may not always be ideal since firmware may exist which is newer or which fixes bugs present in the pre-loaded versions.
In such a scenario where your Call Manager is configured to instruct Phones to use a specific firmware which is different to the firmware pre-loaded on the Phone, then this will be specified in the Configuration File.
When the Configuration File is received by the IP Phone and it is instructed to use a different firmware, it will then pull the firmware from the Call Manager TFTP Server and upgrade.
Once the Phone is running the firmware specified in the Configuration File and has adjusted its settings to operate with the Call Manager Server, it then attempts to Register with the Call Manager.
In the case that a specific Call Manager is down or otherwise unavailable, the IP Phone will then attempt to register with another Call Manager Server if possible.
These alternate Call Manager Servers are specified in the same Configuration File mentioned earlier. Note that the order of the Servers in the Configuration File is important as this will be the order the IP Phone tries to register in.
The Cisco IP Phone should now be up and registered to your Call Manager Server.
In short, the step a Cisco IP Phones goes through to boot are:
- Phone receives power (either from Switch via PoE or by an external power unit)
- Voice VLAN information is delivered to the Phone via CDP
- Phone sends DHCP Request
- Phone recieves an IP along with Option 150 information
- Phone uses Option 150 to retrieve a its Configuration File (and Firmware if necessary) from the TFTP server (Call Manager)
- Phone contacts the first Call Manager server in the Configuration File to register
- Phone registers successfully
Now that we know how it works, we can apply our knowledge to some situations where things aren’t working correctly:
- If you have a Phone that successfully receives an IP address, this means that the network configuration is fine and that the issue likely lies with the Call Manager configuration. Double check it.
- Conversely, if the phone doesn’t receive an IP address, this indicates that the problem isn’t necessarily to do with the Call Manager, but the network. This is usually an indicator of incorrect or missing Switch/Port connectivity to the Phone or DHCP Server.