Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat Today
Dial-up failover refers to a secondary alarm transport path that activates only when the primary IP or LAN-based monitoring path is unavailable. In a typical DPS Telecom architecture, a NetGuardian RTU continues to report alarms over LAN under normal conditions, and then automatically places an outbound dial-up call to a T/Mon alarm master only when the primary polling path fails.
This article explains how to design dial-up as a true failover mechanism (not periodic dial-out polling), what must be configured on both the remote RTU and the head-end, and how to test the design without creating duplicate alarm paths. The scenario is based on a common request from a large metropolitan public transportation operator that needed dial-up continuity for multiple remote NetGuardian units already communicating over LAN.
Dial-up failover for remote monitoring is a continuity technique where a remote device uses the public switched telephone network (PSTN) as a backup path to deliver alarms when IP connectivity is degraded or unavailable. Dial-up failover is most often used when remote sites have limited WAN redundancy, when IP transport is shared with other critical systems, or when the organization wants an out-of-band path that is operationally independent from routers, firewalls, and carrier transport.
In transportation and industrial environments, dial-up failover is typically applied to alarm reporting for power, environmental, access, and communications telemetry. Dial-up failover is most effective when it is event-driven and conditional, so that dial-up is used only during primary-path failure and not as a parallel, always-on reporting channel.
A failover path is operationally useful when it answers one question consistently: "Did we lose visibility because the site is healthy but unreachable, or because the site has a real alarm?" A true failover design helps restore telemetry during a primary-path outage without adding noise or confusion during normal operations.
Periodic dial-out polling refers to the alarm master (or head-end) placing calls to remote devices at a fixed interval, such as every 60 minutes, to collect status. Periodic dial-out polling can be valid for legacy networks, but it is not the same as failover for a LAN-connected RTU.
When a remote NetGuardian is already reporting alarms over LAN, adding periodic dial-out polling from the head-end creates two concurrent alarm paths. That dual-path design can produce duplicate events, unclear root cause, and additional operations work because staff must distinguish whether an alarm arrived over IP or dial-up.
| Design Choice | How It Works | Common Outcome | When It Fits |
|---|---|---|---|
| Periodic head-end dial-out polling | T/Mon calls the remote device on a schedule to collect status. | Parallel alarm paths and possible duplication when LAN is also active. | Legacy-only dial environments, or sites without LAN telemetry. |
| RTU-initiated dial-up failover (recommended) | NetGuardian calls T/Mon only after detecting primary polling failure. | Dial-up becomes a conditional backup path, reducing duplicates. | Sites with LAN primary monitoring that need out-of-band resilience. |
A failover strategy should be designed so that the backup path is quiet during normal operations. Dial-up minutes, modem resources, and operator attention are all conserved when dial-up is reserved for true exceptions.
A dial-up failover trigger is the logic that determines when the RTU should place an outbound call. In a typical deployment, the NetGuardian considers the primary path to be healthy while it is being successfully polled (for example, via DCP polling or another LAN monitoring mechanism). When polling becomes inactive, the RTU can be configured to dial the head-end.
One common implementation uses a setting conceptually described as "only dial if poller inactive" or similar failover logic. The precise label can vary by model and firmware, but the intent is consistent: do not dial during normal LAN visibility, and do dial only when the RTU concludes the head-end cannot see it over the primary path.
Remote provisioning for dial-out failover typically includes the following items. The values themselves depend on the specific deployment, but the checklist describes the categories that must be verified.
In many organizations, contractors or a separate field team performs the NetGuardian provisioning while the NOC team manages T/Mon head-end configuration. That division of responsibilities is common, but it makes a written commissioning plan more important because both ends must agree on device IDs and call routing.
A Trip Receiver in T/Mon refers to a receiver job configured to accept inbound dial-up connections from remote devices. In a failover design, the dial-up call is initiated by the remote NetGuardian, so the head-end must be listening for rings and capable of negotiating the connection and receiving alarm data.
The Trip Receiver is distinct from a dial-out polling job. The receiver exists so the head-end can accept the call on demand, at the moment the remote RTU decides dial-up is required. This is the essential architectural difference between periodic polling and conditional failover.
If dial-up is intended to be strictly failover, the receiver should be configured and validated in a way that does not create routine dial-up traffic during normal LAN operation.
In infrastructure monitoring, a dual-path device model refers to representing the same physical site with two logical device entries so each transport path can be tracked independently. In T/Mon, dial-up alarms commonly appear as a second instance of the device, even when the alarm definitions are the same as the LAN instance.
This approach prevents accidental overwriting of state and makes it clear which path is currently providing telemetry. It also allows the NOC to alarm on path health, such as "LAN poll failure" versus "dial-up active."
A naming convention is a control mechanism. A consistent label reduces operator uncertainty during incidents.
Alarm definitions can remain consistent across both device entries when the RTU points are the same. The operational difference is the transport path and the intended usage pattern.
A shared line arrangement refers to a phone line that is not dedicated exclusively to the monitoring receiver. Line-sharing devices can route calls based on ring patterns, caller ID, or time-of-day rules. This can be helpful in constrained environments, but it adds variables to dial-up alarm reception.
When a line-sharing device is present, the receiver must reliably detect inbound rings and gain access to the call path. Some line-sharing approaches can delay answering, suppress ring signals to attached equipment, or require specific ring cadence behavior. These behaviors can affect whether the T/Mon receiver job and modem reliably answer.
A shared line is not automatically a blocker for failover, but it requires explicit test cases during commissioning because dial-up is often used precisely when the network is already in an abnormal state.
A dial-up failover commissioning test is a controlled procedure that proves the RTU can switch from the primary path to dial-up, that T/Mon receives the call via the receiver job, and that alarms are readable and actionable. A good test plan isolates one change at a time so a failure can be diagnosed quickly.
The most important success criterion is that dial-up is quiet during normal operations and activates only when the primary monitoring path is not working.
A split-responsibility deployment is a project model where field contractors provision remote RTUs while NOC staff configure the alarm master and monitoring workflows. This model works well when responsibilities are explicit and validated by test results.
| Task Area | Typical Owner | Items To Exchange Between Teams |
|---|---|---|
| NetGuardian dial-up number and failover trigger | Field team or contractor | Dial destination number, device ID, failover settings confirmation |
| T/Mon receiver (Trip Receiver) configuration | NOC or head-end team | Receiver job parameters, modem/line mapping, answering behavior |
| T/Mon device database entries | NOC or head-end team | Primary device name, dial-up failover device name, matching IDs |
| End-to-end failover testing | Shared | Test window, rollback plan, what constitutes pass/fail |
This responsibility mapping reduces project friction and avoids the common failure mode where each team assumes the other side has already completed a prerequisite.
Dial-up failover troubleshooting is fastest when symptoms are mapped to the layer that can plausibly cause them. The table lists common symptoms and the first checks that typically resolve them.
| Symptom | Likely Cause Category | First Checks |
|---|---|---|
| RTU never dials during a LAN outage | Remote failover trigger not enabled or poll failure not detected | Verify failover checkbox/logic, verify the poller inactivity condition is actually met |
| RTU dials even when LAN is healthy | Failover set to always dial or primary polling not considered active | Verify trigger logic is conditional, verify the poller is active and correctly associated |
| T/Mon does not answer inbound calls | Receiver job/modem/line issue | Verify Trip Receiver job state, verify modem sees ring, verify line-sharing behavior |
| T/Mon answers but no alarms appear | Device ID mismatch or routing issue | Verify inbound identity maps to the dial-up device entry, verify IDs match expected values |
| Operators see duplicate alarms during normal operation | Parallel polling and failover both active | Disable periodic dial-out polling, ensure dial-up is receiver-only and event-driven |
Dial-up is a constrained medium, so clarity in identification and state handling is essential. A dual-instance approach in T/Mon is often the simplest way to preserve clarity.
Alarm path resiliency is the design practice of ensuring alarms still reach the NOC when one transport path fails. DPS Telecom architectures typically combine RTU-based telemetry collection with an alarm master workflow that normalizes alarm presentation for operators.
NetGuardian RTUs are commonly used to collect discrete alarms and analog values at remote sites, and they can be configured for multiple communication methods depending on the model and requirements. T/Mon alarm master products provide centralized alarm display, correlation, and operational workflows, including receiver jobs for inbound communications and database structures that support clear device identity.
When organizations need to reduce monitoring tool sprawl, DPS Telecom solutions often also support protocol mediation and alarm integration approaches that consolidate events from multiple sources into a single operational view. In a dial-up failover project, consolidation is achieved primarily through consistent alarm definitions and clear labeling of the primary versus failover device instances.
Dial-up polling is a scheduled head-end activity where the alarm master calls sites periodically. Dial-up failover is an event-driven behavior where the RTU calls the head-end only when the primary path is unavailable.
Yes. A receiver function must exist at the head-end to accept inbound calls, and T/Mon typically requires a corresponding dial-up device entry to map and display alarms correctly.
T/Mon often represents dial-up as a separate logical device entry so path state and alarm presentation remain unambiguous. The failover instance can use the same alarm definitions but be clearly labeled as dial-up failover.
Sometimes. Line-sharing devices can change ring behavior or line seizure order, so the receiver and modem must be tested under realistic conditions to confirm they reliably detect and answer incoming calls.
Disable periodic head-end dial-out polling and rely on RTU-initiated dial-out. Then induce a controlled primary-path failure so the RTU dials only when the poller is inactive.
The most common mistake is enabling a parallel dial-out polling schedule at the head-end while also keeping LAN monitoring active, which creates two alarm paths during normal operation and can result in duplication.
Dial-up failover is simplest when it is designed as a conditional, RTU-initiated backup path with a properly configured T/Mon receiver and clearly labeled device instances. DPS Telecom can help review the intended workflow, align remote device IDs with head-end configuration, and plan a test procedure that proves failover without creating duplicate alarm paths.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 19 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
