Why Fax, Fire Alarms, and Elevators Resist VoIP

Every VoIP migration hits the same wall. You have moved the phones, the users are happy, the old PBX is unplugged, and then someone asks about the fax machine. And the fire alarm panel. And the elevator phone. And the security system. And the postage meter in the mailroom that apparently has a phone line plugged into the back of it.

These are the analog holdouts. They are devices that were designed for a dedicated, always-on, copper-pair analog phone line, and they resist conversion to VoIP for reasons that range from "annoying but solvable" to "governed by life-safety codes that dictate exactly what may replace the line." Understanding why each one is difficult, and how difficult, saves you from learning the hard way that your fire alarm has been offline for three months.

Why analog devices are different from phones

A VoIP phone is designed to work on a data network. It speaks SIP, it handles codec negotiation, it tolerates reasonable amounts of jitter and packet loss, and it recovers gracefully from brief network interruptions. It was built for this environment.

Analog devices were built for a completely different environment. A traditional analog phone line (POTS — Plain Old Telephone Service) provides:

A dedicated circuit. When the device goes off-hook, it gets a circuit with guaranteed bandwidth and zero contention. No other traffic competes with it. No congestion, no packet loss, no jitter. The connection is either there or it is not.

Line power. The phone company provides 48 volts DC on the copper pair. The device draws power from the line itself. No external power supply needed. No UPS. No network switch. If the building loses power, the analog line still works because the central office has its own battery plant and generator.

Simplicity. The signaling is electrical. On-hook, off-hook, dial tone, DTMF tones, ring voltage. No software stack, no firmware updates, no network configuration. The device has worked the same way for decades.

VoIP eliminates all three of these. The circuit is replaced by a shared data network. The line power is replaced by a dependency on your network infrastructure (switches, routers, internet connection) plus external power. The simplicity is replaced by a stack of protocols and a dependency on multiple systems being functional simultaneously.

For a phone on someone's desk, these tradeoffs are fine. For a device that calls the fire department when your building is on fire, they are not.

Fire alarm panels

This is the one that can actually get someone hurt, so it deserves the most attention.

Fire alarm communicators dial out to a central monitoring station when an alarm triggers. The traditional setup is two dedicated POTS lines (a primary and a backup) connected to the fire alarm control panel (FACP). The panel seizes the line, dials the monitoring station, and transmits alarm data using a protocol like Contact ID or SIA. The monitoring station acknowledges receipt. If the primary line fails, the panel uses the backup line. The panel also regularly tests the lines by placing supervision calls to verify they are working.

The reason this is hard to convert to VoIP:

Reliability requirements. NFPA 72 (the National Fire Alarm and Signaling Code) specifies how alarm signals must be transmitted and the acceptable failure modes. A POTS line either works or it does not, and the panel can detect a failed line almost immediately by checking for dial tone. A VoIP connection can fail in partial, ambiguous ways: the network is up but the SIP registration has lapsed, the internet is up but the trunk provider is having an outage, the ATA has power but its firmware crashed. The fire panel has no way to know that the VoIP path behind the ATA is broken.

Power independence. A POTS line works when the building power is out. A VoIP path requires your network switch, your router, your internet connection, and your VoIP provider to all be functioning. Even with a UPS on every piece of equipment, you have multiplied the points of failure. If the UPS runs out before power is restored, the alarm communicator goes silent, and nobody knows.

Code compliance. Your local Authority Having Jurisdiction (AHJ) — the fire marshal or building inspector — has to approve the alarm communicator arrangement. Many AHJs have historically required POTS lines and are cautious about approving alternatives. This is changing, but it varies enormously by jurisdiction.

A generic ATA is not the answer. The issue is not that IP transmission is categorically prohibited — NFPA 72 recognizes multiple transmission technologies — it is that the code requires the communication path to be a listed arrangement with supervision and fault reporting, backup power, and transmission-time performance, all approved by the AHJ. A consumer ATA on the office VoIP system is not listed for fire alarm service, cannot report the failure of the network behind it to the panel, introduces latency and potential packet loss into a signaling protocol designed for a clean circuit, and does nothing to address the power dependency problem. Whether any particular arrangement complies is ultimately the AHJ's call, and a generic ATA is not going to get that approval.

What actually works

The industry has moved toward two alternatives:

Cellular communicators. A cellular module (often called an alarm communicator or radio) is installed in or next to the fire panel. It communicates with the monitoring station over the cellular network, bypassing both POTS and VoIP entirely. These are UL-listed for fire alarm use, have their own battery backup, and are increasingly accepted by AHJs. Most major alarm monitoring companies now support cellular communicators. This is the most common replacement for POTS lines on fire panels today.

IP communicators. UL-listed IP alarm communicators connect the fire panel to the monitoring station over an IP network. These are not ATAs. They are purpose-built devices designed to meet fire alarm communication standards, with their own supervision mechanisms, acknowledgment protocols, and fallback paths. They typically require a dedicated, monitored network connection and may require a cellular backup path. AHJ acceptance varies.

The key point is that both of these are engineered solutions with their own listing and certification. They are not "plug the fire panel into the VoIP system." If you are migrating a building off POTS, the fire alarm communicator needs its own conversation with the alarm company and the AHJ, separate from the phone system migration.

Elevator phones

Building codes (ASME A17.1 for elevators, IBC for the building) require a phone in the elevator cab that connects to a location where someone can dispatch help. The requirements typically include:

• The phone must work without user action beyond lifting the handset (or in some cases, just pressing a single button)
• The call must connect to a live person or a monitoring service, not to a voicemail box or auto-attendant
• The phone must work during a power outage (elevators have battery lowering, and the phone needs to work after the cab reaches a floor)
• The connection must be reliable enough that a person trapped in an elevator can get help

A POTS line inherently meets all of these. A generic ATA on the building's VoIP system does not, for the same reasons as fire alarms: power dependency, multiple points of failure, and the inability of a simple analog device to detect that the VoIP path behind the ATA is broken. That is not the same as saying IP or cellular paths are prohibited — recent editions of ASME A17.1 accommodate two-way communication over alternative means — but the arrangement must satisfy the code's power, monitoring, and reliability requirements and be accepted by your inspector, which a bare ATA will not.

The trapped-in-an-elevator scenario is worth thinking through. The building lost power. The elevator stopped between floors. The emergency generator (if there is one) is running the elevator controller to bring the cab to a floor, but the passenger does not know that. They pick up the elevator phone. If that phone is connected through an ATA that is plugged into a network switch that lost power when the building did, there is no dial tone. The passenger is stuck in a dark elevator with a dead phone.

What actually works

Cellular lines. Same concept as fire alarms. A cellular device in the elevator machine room provides a phone connection independent of the building's data network and power. This is the most common POTS replacement for elevator phones. The device has its own battery and its own cellular connection.

Managed elevator phone services. Some companies provide a complete elevator phone solution: hardware, cellular connectivity, monitoring, and testing. They handle the compliance requirements and provide documentation for your building inspector.

As with fire alarms, the answer is not "plug it into the VoIP system." It is a separate, purpose-built solution.

Security and burglar alarm systems

Security alarm panels work similarly to fire panels. They have one or two phone lines, they dial a central monitoring station when an alarm triggers, and they periodically test the lines. The reliability requirements are less stringent than fire alarms (NFPA 72 applies to fire, UL 681 applies to burglar alarms), but the basic problem is the same.

The consequences of failure are different. A fire alarm communication failure can be a life-safety issue. A security alarm communication failure means a break-in might not be reported. Still serious, but the regulatory framework is less rigid.

Many security alarm companies have already migrated their customers to cellular or IP communicators, driven partly by the ongoing retirement of copper POTS infrastructure by the phone companies. If your alarm system is still on POTS lines, your alarm company almost certainly has a cellular upgrade path. It is often a straightforward swap.

One thing to watch for: some alarm panels use the phone line not just for alarm communication but also for remote programming and firmware updates by the alarm company. If you remove the POTS line, confirm with the alarm company that they can still service the panel remotely via whatever replaces it, or that they are willing to do on-site service visits instead.

Fax machines

Fax over VoIP is covered in detail in Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It, but the short version is: fax machines send data as precisely timed audio tones over a connection they expect to be clean and consistent. VoIP introduces codec compression, jitter, packet loss, and echo cancellation that can corrupt or destroy those tones.

Fax is the most solvable of the analog holdouts because the alternatives are mature:

T.38 fax relay. If both your VoIP system and your trunk provider support T.38, the fax tones are decoded into data at the sending end and reconstructed at the receiving end, eliminating sensitivity to the VoIP path. This works well when both sides support it. When only one side does, it can fail silently.

Fax-to-email services. Move faxing off the phone system entirely. Inbound faxes arrive as email attachments. Outbound faxes are sent via a web interface or email. No fax machine, no analog line, no ATA. This is the most reliable option for most businesses.

Dedicated analog line. Keep a single POTS line (or an ATA on a high-quality trunk) for the fax machine. Inelegant but effective. As POTS lines become harder to get and more expensive, this is a less viable long-term option.

Unlike fire and elevator lines, fax does not have a code compliance dimension. It is purely a reliability question. If faxing is critical to the business (medical offices, legal firms, government), invest in a solution that works rather than hoping G.711 passthrough will be reliable enough.

Postage meters and other oddities

Postage meters phone home to download postage. Credit card terminals (the older dial-up kind) call a processor to authorize transactions. Some building management systems use analog lines for remote monitoring. Older medical devices report results over phone lines.

These devices generally have the same problem at a smaller scale: they were designed for a clean analog circuit and they make assumptions about timing, tone signaling, and connection reliability that VoIP does not guarantee.

For most of these, an ATA is an acceptable solution because the stakes are lower. If a postage meter fails to download postage, you try again. If a credit card terminal times out, you run the card again. Annoying, but not a safety issue. Set the ATA to use G.711 with no compression, disable echo cancellation on that port, and test thoroughly before considering the migration complete.

That said, many of these devices now have IP-native or cellular alternatives. Modern credit card terminals use IP or cellular. Postage meters increasingly connect over the network. When a device is up for replacement, replacing it with one that does not need an analog line at all is better than maintaining an ATA indefinitely.

The migration checklist

Before you cancel the POTS lines in any building, walk the building and inventory every device connected to a phone line. Check:

• Fire alarm panel — How does it communicate? How many lines? Who is the monitoring company? What does the AHJ require?
• Elevator phone — What are the local code requirements? Who monitors the elevator phone line?
• Security panel — How many lines? Who is the monitoring company? Do they offer cellular?
• Fax machines — How many, and how critical? Can users switch to fax-to-email?
• Everything else — Postage meters, credit card terminals, building automation, medical devices, gate access systems, weather monitoring equipment, anything with an RJ11 jack

For each device, the question is not "can we make this work on VoIP?" It is "what is the right replacement path for this specific device?" Sometimes the answer is an ATA. Sometimes it is a cellular communicator. Sometimes it is replacing the device with an IP-native version. And sometimes, particularly during a transition period, the answer is keeping a POTS line or two until the rest of the migration is complete.

The worst outcome is discovering six months later that the fire alarm has not been communicating with the monitoring station since you pulled the copper. Inventory first, plan second, migrate third.

For more on fax-specific issues and solutions, see Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It. For the broader context of VoIP migration planning, see the MSP's Guide to VoIP series.