Fault Isolation Order
A voice callout that dials correctly, rings the right person, then disconnects on pickup and advances to the next contact is a call-progress problem, not a dialing problem. The software has already done its part by the time the line is answered. What fails next is one of three things: there is nothing to play, the line presents an answer signature the modem cannot read, or the modem misreads a legitimate answer as a disconnect. Work them in that order because each check is cheaper and more deterministic than the one after it.
| Observation on the answered call | Most likely cause | Deciding check |
|---|---|---|
| Silence, then immediate hang-up, every alarm, every contact | Alarm has no voice message assigned or message file is empty | Open the alarm definition and play the message from the configuration tool |
| Hang-up on some contacts only (cell, VoIP, PBX extensions) | Called-party network returns tones or silence the modem interprets as disconnect | Call the same contact from a desk phone on the same line; call the contact from the modem line by hand |
| Intermittent, unpredictable, any contact, any time | Modem call-progress detection marginal for this line; noise, level, or loop-current behavior | Substitute modem, then substitute line; log every occurrence with time and contact |
| Message starts, cuts off, then next contact dials | Modem drops the voice stream mid-play or acknowledgment window is misconfigured | Watch the modem log during a test call; confirm acknowledgment method and timeout |
The installation in question had a vendor-supplied modem, a programmed message, a fresh driver install, and a fresh software install, and the fault still returned intermittently. That combination pushes the diagnosis toward the modem-to-line interface, and the sections below build the proof in commissioning order.
Alarm Message Content Check
Before anything else, confirm that every alarm on the callout list has a non-empty voice message. An alarm with a blank message produces exactly this symptom: the call connects, the empty message plays in zero seconds, no acknowledgment arrives, and the escalation logic moves on. The person who answers hears a click and dead air.
- Open the alarm definitions and sort by the alarms that triggered the reported callouts. Do not rely on a sample; check every alarm that has produced the complaint.
- For each, open the message assignment and play the message from the configuration tool. Confirm audio is heard and the duration is non-zero.
- If messages are built from text-to-speech or concatenated phrases, confirm the tag description or phrase list is populated. A message that references an empty tag description plays as silence.
- Confirm the message file path resolves on the runtime machine, not only on the engineering laptop where it was built.
Do not move on until a test call from the software, to a desk phone within earshot, plays the full message audibly. If it does, the message content is cleared and the fault is downstream of it.
Phone Line Characterization
Voice modems detect that a call has been answered by reading the line: loop-current reversal or a break in ringback on a true analog loop, or voice energy and silence timing where no supervision signal is available. PBX analog ports, VoIP analog terminal adapters, and some carrier lines do not return answer supervision at all. On those lines the modem falls back to timing-based detection, and a short silence after pickup, a comfort-noise burst, or a burst of line noise is enough to trigger a false disconnect.
- Identify what the modem is plugged into: a carrier analog loop, a PBX analog station port, or an analog terminal adapter on a VoIP service. Record it.
- Plug an ordinary handset into the same jack. Dial each contact on the list. Note what is heard at pickup: an immediate clean connection, a pause, a beep, or a recorded network announcement.
- Dial a contact and stay on the line. Confirm the connection holds for several minutes without clicks or dropouts. Any audible instability here will be read by the modem as a disconnect.
- Move the modem to a different line, preferably a direct carrier analog loop, and repeat the test callout to the contacts that most often see the hang-up.
The line is cleared when a test callout on the alternate line plays the message and accepts acknowledgment to every contact that previously failed. If the fault follows the modem to the new line, the line is not the cause.
Modem Substitution and Driver State
A driver reinstall does not change modem firmware call-progress behavior, and a software reinstall does not change the modem. If both have been done and the fault persists, the remaining variable is the physical modem and its detection thresholds. Vendor-supplied does not mean immune; it means the vendor has seen it work on lines that behave well.
- Confirm the installed device is a voice-capable modem presenting a TAPI voice device to Windows. A data-only modem will dial and appear to work but cannot play audio or detect answer correctly.
- Enable modem logging in the Windows modem properties before the next test. The log shows the command sequence, the call-progress result reported at pickup, and the hang-up command issued afterward. The result code that appears immediately before the hang-up tells you whether the modem reported busy, no carrier, silence, or a voice event.
- Run a test callout with the log active and the contact instructed to answer and stay silent for a few seconds, then speak. Read the log at the point of pickup.
- Install a second voice modem of a different make or model on the same line and repeat the test. Keep the original modem's serial port and driver removed so the software binds only to the substitute.
The modem is cleared when the substitute unit completes every test call and the log shows a clean answer event at pickup. The modem is condemned when the substitute passes and the original fails on the same line under the same test. Return the failed unit to the supplier with the log excerpt; that is what their support channel needs to reproduce it.
Intermittent Capture and Correlation
An unpredictable fault is only unpredictable until it is logged against the variables that drive it. Set up a capture before the next event rather than trying to remember afterward.
| Record per occurrence | Why it matters |
|---|---|
| Timestamp and alarm tag | Correlates with message content and with the software's own callout log |
| Contact called and contact type (landline, cell, VoIP) | Separates called-party network behavior from local line behavior |
| Position in the call list | A fault only on the first dial after idle points to line seizure or modem warm-up; a fault on later dials points to detection |
| Modem log excerpt at pickup | Gives the actual result code that caused the hang-up |
| What the answering person heard | Dead air versus partial message separates content and playback faults from detection faults |
Ask whether the fault occurs on more than one runtime machine, if the site has several. A fault on one unit only is a hardware or line fault on that unit. A fault on every unit, regardless of modem and line, is a configuration fault and the message and acknowledgment settings need a second pass. Collect at least a handful of occurrences before drawing the conclusion; a single event proves nothing on an intermittent problem.
End-to-End Callout Verification
Verification is a scripted callout, not an observation that it has not happened lately. Run it after each change, and run the final pass on the modem and line that will stay in service.
- Force a test alarm on a tag whose message content was verified in the first section.
- Have the first contact answer normally, listen to the full message, and acknowledge with the configured DTMF code. Confirm the software logs the acknowledgment and stops escalation.
- Repeat with the first contact not answering. Confirm the software waits its configured ring or timeout, hangs up cleanly, and dials the second contact.
- Repeat with the first contact answering and staying silent for the full message. Confirm the call stays up for the entire message rather than dropping during the silence.
- Repeat the answered-and-acknowledged test to each contact type present on the list: landline, cell, and any VoIP or PBX extension.
- Leave modem logging enabled and run the sequence a number of times spread across the shift, then review every log for any pickup that did not produce a clean answer event.
The system is commissioned when every answered test call plays the complete message, every acknowledgment stops escalation, and the modem log across the full run shows no hang-up issued at pickup.
Frequently Asked Questions
What happens if the WIN-911 alarm has no voice message assigned?
The call connects, an empty message plays instantly, no acknowledgment is received, and the software hangs up and dials the next contact. The person who answers hears a click and silence, which looks identical to a modem detection fault until the message is played back from the configuration tool.
What happens if the modem is on a PBX or VoIP analog port instead of a carrier line?
Those ports usually provide no answer supervision, so the modem relies on silence and voice-energy timing to decide the call was answered. Comfort noise, a pause after pickup, or a network announcement can be read as a disconnect and the call is dropped before the message plays.
What happens if I only reinstall the modem driver and the software?
Nothing changes at the line interface, so an intermittent detection fault returns. The driver controls the command sequence; the modem's firmware and the line's signalling decide whether pickup is recognized, and only a modem substitution and a line substitution separate those two.