When the Call Connects but the Alarm Never Arrives

A fire alarm dialer can be working perfectly and still stop communicating the day a building moves to a hosted phone system. The panel seizes the line, the receiver at the other end answers, and the call connects. What fails is everything after that: the handshake, the tones, the acknowledgment. The receiver knows a call arrived but cannot turn it into a building number or an event. Nothing broke in the fire alarm system. The transport underneath it changed, and digital alarm communicators are unusually sensitive to that particular change.

---

What Actually Happens When a Dialer Calls Over a Voice Platform?

A digital alarm communicator does not send data the way a computer does. It places an ordinary voice call and then exchanges information as audio tones, in a strict sequence with tight timing. Each step depends on the one before it.

1. The panel seizes the line and dials the receiver.
2. The receiver answers and sends a handshake tone identifying the format it expects.
3. The panel recognizes that handshake and transmits its message as tones carrying the account, the event type, and the zone or point.
4. The receiver decodes the message and returns an acknowledgment tone, often called a kissoff.
5. The panel hears the kissoff, considers the message delivered, and hangs up.

Break any link in that chain and the exchange fails. If the handshake never arrives intelligibly, the panel has nothing to answer. If the message tones arrive distorted, the receiver cannot decode them. If the kissoff is lost, the panel assumes failure and redials, repeating until it gives up and reports a communication trouble.

---

Why Does Compressed Voice Break Alarm Tones?

Voice platforms are engineered to carry human speech efficiently, and that engineering is actively hostile to signaling tones. Compression algorithms discard audio content that a listener will not consciously miss, which is a reasonable trade for conversation and a destructive one for a protocol where the precise frequency and duration of each tone carry the data.

• Lossy compression alters tone frequency and shape, so what arrives is no longer what was sent.
• Packet loss removes fragments of a tone, shortening or truncating it below what the decoder will accept.
• Jitter disturbs the spacing between tones, and the timing between them is part of the message.
• Echo cancellation and silence suppression can clip the leading edge of a tone or drop it as background noise.
• Variable network delay can push the handshake or acknowledgment outside the window the equipment waits for.

The symptoms follow directly. A receiver logs that a call arrived but produces an error rather than an event. Dialers retry repeatedly and eventually report failure. Results are often intermittent, working at quiet times and failing under network load, which makes the problem maddening to reproduce on demand.

The fire alarm system is doing exactly what it always did. The audio path underneath it is no longer faithful enough to carry the message.

Ordinary phone calls over the same platform usually sound fine, which is why this failure is so often discovered late. Human conversation tolerates the very degradation that makes a tone protocol unreadable.

---

What Does NFPA 72 Say About Dialers and Voice Networks?

The code anticipated this. Rather than naming a technology, NFPA 72 defines the class of service a dialer may use: a managed facilities-based voice network, a carrier-operated service that is functionally equivalent to traditional telephone service, with defined standby power and operational obligations behind it.

The requirement in NFPA 72 section 26.6.4.2.1 is that a DACT connect to that managed network ahead of any private telephone system at the protected premises. That clause is the one most often overlooked, and it is exactly the arrangement that fails: when a campus or enterprise routes its alarm dialers through its own phone platform, the dialer is no longer connected upstream of the private system, it is connected through it.

A New Jersey code bulletin explaining the concept notes that managed facilities-based voice networks are treated as functionally equivalent to the traditional switched network, and that a dialer is not the only permitted transmission means; any method recognized by the code may be used instead. Requirements vary by adopted edition and jurisdiction, so the applicable rules and any equivalency determination should be confirmed with the authority having jurisdiction rather than assumed.

---

How Do You Diagnose a Dialer Failure After a Phone Cutover?

The first job is separating a fire alarm problem from a transport problem, and the timeline usually settles it. If communications were healthy until the day the phone service changed, the investigation belongs on the telephone path.

1. Establish exactly when the behavior started and what changed on the phone system that week.
2. Check what the receiver logs: a call detected with no decodable data points to transport rather than to the panel.
3. Determine the path each alarm line now takes, including whether it passes through a premises phone system before leaving the site.
4. Ask who operates that path and whether the service qualifies as a managed facilities-based voice network.
5. Ask the telecom group specifically about the codec in use, packet loss, jitter, echo cancellation, and silence suppression on those extensions.
6. Test whether behavior differs between a line carried on the new platform and one still on legacy service, which isolates the variable cleanly.
7. Collect receiver logs and event printouts across several failures before drawing conclusions, since intermittent faults mislead on a single sample.

Network-side remediation is sometimes possible. Where a platform can be configured to carry those extensions on an uncompressed codec with fax and modem style handling, prioritized and shielded from other traffic, tone integrity can improve. Whether that is achievable depends on the platform and on what the telecom group controls, and it is a conversation to have early rather than a guaranteed outcome. Sites troubleshooting inconsistent reporting more generally can review the Digitize guide to intermittent fire alarm communication failures.

---

What Are the Durable Alternatives to a Dialer Path?

Tuning a voice platform to carry tone protocols is remediation, not a strategy. The platform can be reconfigured, the contract can change, and the underlying service can be replaced again. Sites that keep running into this eventually conclude that the dependency itself is the problem.

Approach	What It Solves	What to Confirm
Keep carrier-provided lines for alarm use	Preserves the existing dialers with no panel change	Whether the service qualifies and how long the carrier will offer it
Tune the voice platform for tone traffic	May restore decoding without new hardware	Codec control, prioritization, and who owns the configuration
Cellular or IP alarm communicators	Removes the dependency on premises phone service	Coverage, supervision intervals, and recurring cost
Report over the site network to a local head end	Keeps alarm traffic on infrastructure the site controls	Coordination with IT and a dedicated, supervised segment
Interface panels directly to a monitoring head end	Eliminates the dialed call entirely	What each panel can output and what detail survives

The last option deserves attention on any site with several buildings. Rather than each panel placing a phone call, building interfaces report continuously to a head end on the site. A Data Gathering Module collects contact outputs and a Muxpad II captures serial event text, both reporting to a System 3505 Prism LX over media the organization owns.

Transitions of this kind are normally phased rather than done at once, keeping working dialer buildings in service while others convert, an approach covered in the Digitize guide to bridging legacy and modern fire alarm systems and in its POTS replacement and alarm transport resources.

---

How Should a Phone System Migration Be Planned Around Fire Alarm?

Most of these failures are discovered after a cutover because nobody told the fire alarm stakeholders it was happening. Telecom projects are scoped around users and handsets, and alarm lines are easy to overlook because they have no user attached.

• Inventory every line serving a fire alarm, elevator, or other life-safety function before the migration is designed.
• Flag those lines as excluded from migration, or as requiring specific handling, in the project scope.
• Include the fire alarm service provider and the authority having jurisdiction in the plan, not just as a courtesy notification.
• Test each alarm line end to end after cutover, verifying decoded events at the receiving end rather than dial tone at the panel.
• Repeat testing under realistic network load, since these failures often appear only when the network is busy.
• Keep the legacy service active until the replacement path is proven, rather than cutting over and testing afterward.

Treating alarm lines as a distinct category during planning costs very little. Discovering after the fact that a building's alarms have not reached the receiver for weeks is a substantially worse outcome.

---

Frequently Asked Questions About Dialers and VoIP

Our phones work fine, so why would the dialer fail?

Human speech tolerates compression and small timing errors, while a tone protocol does not. A call can sound perfectly clear and still carry tones too degraded for a receiver to decode.

Is the receiver or the panel at fault?

Usually neither. When the receiver logs an incoming call but cannot decode data, the equipment at both ends is functioning and the audio path between them has altered the signal.

Can a dialer legally run over VoIP?

It depends on the service. NFPA 72 requires the connection to be a managed facilities-based voice network, ahead of any private phone system at the premises. A consumer or enterprise platform that does not meet that definition does not satisfy the requirement, and the applicable edition and local interpretation should be confirmed with the authority having jurisdiction.

Can network changes fix decoding?

Sometimes. Carrying alarm extensions on an uncompressed codec with appropriate handling and prioritization can restore tone integrity, where the platform allows that level of control. It is worth attempting but should not be assumed.

Why does it work sometimes and not others?

Because loss and jitter vary with network conditions. A path that carries tones adequately at a quiet hour may degrade under load, producing intermittent failures that are difficult to reproduce during a scheduled test.

What is the most durable fix?

Removing the dependency on dialed voice calls. Cellular or IP communicators, or interfacing panels directly to a monitoring head end on infrastructure the site controls, all eliminate the exposure to future phone system changes.

---

Get Your Buildings Reporting Again

If your dialers stopped decoding after a phone system change, the fastest path forward starts with confirming what each panel can output and what transport your site already has. Digitize can help you separate a transport problem from an equipment problem, review the diagnostic evidence from your receiving end, and scope a reporting path that does not depend on a voice platform you do not control. Tell us what you are trying to accomplish and we will work out how it can be done. To review your situation, Get a Free Consultation, call 973-663-1011, or email info@digitize-inc.com for engineering guidance and price quotes.