Troubleshooting · Symptoms
Phone Keeps Rebooting: Power, DHCP and Provisioning
The phone restarts mid-morning. Then again after lunch. Users blame the phone; engineers who swap the phone watch the new one reboot too — because the reboot is usually a symptom of the phone's environment: the power it is fed, the network answers it receives, or the configuration it keeps being handed. A phone is a small computer that reboots when its world stops making sense.
Three systems feed a desk phone: PoE power from the switch, DHCP for its network identity, and a provisioning server for its configuration. Each produces a distinctive reboot pattern.
Match the pattern to the system
| Pattern | Likely system | Why |
|---|---|---|
| Reboots under load — busy times, many phones active, backlight/screen features on | PoE power budget | Switch PoE allocation is oversubscribed; phones brown-out when draw peaks |
| Reboots at regular intervals (hourly-ish) or after network changes | DHCP | Lease conflicts, a second DHCP server answering, or the phone failing to renew and restarting its stack |
| Reboots after every provisioning check / at a set poll interval, or loops 'updating configuration' | Provisioning | The server pushes a config the phone rejects or that sets a reboot flag; a bad file loops forever |
| One phone only, random times, gets warm | The phone itself | Failing hardware/power supply — the swap test confirms |
| Whole row of phones reboot together | Switch/uplink/power event | Shared infrastructure: switch reboot, UPS transfer, PoE module fault |
The PoE budget mistake
PoE faults deserve emphasis because they are miscounted constantly. A switch advertises '24 PoE ports' and a total power budget (say 190W). Phones draw by class — many desk phones are Class 2 (~7W) but video/executive models are Class 3 (~15W) — and the switch allocates against the class or negotiated draw, not the idle draw. Fill the switch with Class 3 phones and the budget exhausts before the ports do; the switch then sheds or browns-out ports under load, and phones reboot precisely when the office is busiest. The fix is arithmetic: sum the worst-case draw of everything powered, keep it under ~75% of the switch's budget, redistribute phones across switches, or use local power adapters for the greediest endpoints as a stopgap.
Diagnosis sequence
- Record the pattern before touching anything: which phones, what times, what interval, what the screen shows in the seconds before reboot (provisioning message? DHCP? plain black?).
- Check the switch: PoE budget utilization and per-port draw, port error logs, and uptime — a switch that rebooted takes its phones with it and leaves a log line.
- Check DHCP logs for the phone's MAC: conflicts, NAKs, a rogue second server, or a lease the phone cannot renew (scope exhaustion on a busy VLAN is a classic).
- Check the provisioning server: is this phone's config file valid, recently changed, or flagged to reboot? Compare against a stable phone's file; a bad template pushed fleet-wide reboots fleets.
- Swap test, two ways: the suspect phone on a known-good port with a known-good config, and a known-good phone on the suspect port. Fault follows phone → replace it. Fault stays → the port/power/config is the fault.
- Fix the identified system, then watch a full busy day — PoE and DHCP faults only declare victory under load.
Frequently asked questions
- Why do reboots happen at the busiest times?
- Power budgets and DHCP scopes fail at maxima: peak draw happens when every device is active, and lease churn peaks as everyone arrives. A fault that respects business hours is an infrastructure-capacity fault until proven otherwise.
- Can a bad Ethernet cable reboot a phone?
- Yes — marginal cabling causes link flaps and, on PoE, intermittent power delivery. A phone that reboots when its desk is bumped or its cable moved has told you the diagnosis; re-terminate or replace the drop.
- The whole office rebooted at once during a storm.
- That is power: a sag or UPS transfer dropped the switch (phones have no batteries). Put switches on appropriately sized UPS units and confirm phones ride through a transfer test — after hours, deliberately.