Current Location ：
Power Planning for IP Phones: PoE Budgets, UPS, and Outages
A voice system that loses power is a voice system that stops, and the stop is usually more abrupt than people expect. Analog phones drew their power from the PBX over a pair of copper wires, so a handset kept working through a mains failure as long as the PBX had battery. IP phones invert that dependency: the intelligence still sits in a central platform, but each handset now needs local power and a local network path. Power planning is therefore not an electrical footnote to a voice project; it is the difference between a site that keeps answering calls during an outage and a site that goes dark the moment the lights flicker. This article covers switch power budgets, what to protect with a UPS, how to think honestly about runtime, and how to test the result.
Start From the Device Inventory, Not the Switch Datasheet
Switch vendors publish a total power budget, and the natural approach is to compare it against the number of phones. That comparison is usually optimistic. Handsets draw differently depending on whether the screen is lit, whether a sidecar or expansion module is attached, and whether the phone is supplying power onward to something else. A switch that looks comfortable on paper can be close to its limit once expansion modules, wireless devices, and cameras share the same unit.
| Element | What to count | Common mistake |
|---|---|---|
| Base handsets | Worst-case draw per model, not idle draw | Using idle figures and discovering the limit only under load |
| Expansion modules | Counted as additional draw on the same port | Assuming the phone budget already covers sidecars |
| Shared switch devices | Wireless access points, cameras, badge readers on the same switch | Budgeting only for phones and ignoring everything else on the unit |
| Headroom | Allowance for moves, adds, and temporary devices | Designing to the exact installed count with nothing spare |
| Power source redundancy | Behaviour if a power supply in a modular switch fails | Assuming redundancy covers full load when it covers partial load |
Deciding What to Protect
Not everything needs battery, and trying to protect everything is how projects end up with inadequate runtime on the things that matter. The useful question is not what can be protected but what must stay alive for the business to keep answering. In most sites that list is short: the switching that serves the phones, the routing that reaches the voice platform or the carrier, and the voice platform itself if it is on site.
Desk handsets are a separate decision. Protecting every handset means protecting every switch, which is expensive and often unnecessary if staff can forward calls or use mobile devices during an outage. Protecting the network path, by contrast, means that calls can still reach the platform and be routed to a mobile, a softphone, or another site even if the desk phones are dark.
Runtime Is a Business Decision
UPS runtime is usually bought in round numbers that nobody can defend. The honest way to set it is to ask what the site does during an outage. If the procedure is to keep answering for the duration of a typical short interruption and then invoke a documented fallback, the runtime requirement follows from that procedure. If the procedure is to work through anything, the requirement is different and much more expensive. Write the procedure first, then buy to it.
- Define what must keep answering during an outage: network path, platform, carrier termination, or all three
- Set runtime against the documented fallback procedure, not against a round number
- Check whether carrier equipment located on the site is also protected, since an unprotected carrier handoff defeats everything downstream
- Confirm the emergency calling path still works when mains power is lost
- Include the gateway or border equipment in the protected list if it terminates trunks on site
- Test with a controlled shutdown rather than trusting the runtime display
Testing the Failure You Designed For
A power design that has never been exercised is a hypothesis. The test does not need to be dramatic: schedule a maintenance window, remove mains power from the protected path, and observe what happens to registration, inbound calling, and emergency calling. The first test usually reveals something mundane and important, such as a switch that was never moved onto the protected circuit, or a carrier device sitting on an unprotected outlet.
Record the measured runtime rather than the vendor's stated figure. Battery capacity degrades, loads grow, and the measured value from a real test is the only number worth planning against. Repeating the test annually is a reasonable cadence, and it is far cheaper than discovering the gap during a real outage.
Redstone Approach
Redstone supports availability planning as part of voice platform design. Our teams can review device inventories and power budgets, help identify which components must remain energised for a site to keep answering, coordinate with your electrical and facilities vendors on protected circuits, and participate in controlled outage testing. Where a design includes Redstone REX IP-PBX or RGW gateway equipment on site, we can advise on placement and power dependencies so the voice path is protected coherently with the rest of the site. Detailed power specifications are scoped in writing against the actual installed equipment list.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
