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
Voice call alarm notification is a method of alerting on-call staff by placing an automated telephone call when a critical alarm occurs, rather than relying only on email or text messages. A ringing phone is still the most reliable way to wake a technician at 3 a.m., which is why many telecom carriers and utilities keep voice dialing in their notification plan even after moving most alerts to email.
This article explains why email and text alone can let critical alarms slip by, how traditional and IP-based dialing paths compare, how to keep voice traffic separate from monitoring traffic, and how to layer notification methods so one failure does not leave a site unwatched. It is written for central office supervisors, network managers, and NOC leads at rural telephone companies, cooperatives, and utilities who are responsible for after-hours response.
Email and text notifications are convenient, inexpensive, and easy to route to a group. For most alarms they are the right choice. For the alarm that cannot wait until morning, they have two weaknesses.
The first is delivery. Many monitoring systems send text messages through a carrier's email-to-text gateway, converting an email address into an SMS. Some carriers have discontinued or restricted those gateways, and when that happens, alerts that used to arrive as texts simply stop. Nothing on the monitoring side looks broken. The messages leave the system and never arrive.
The second is attention. Even when a text arrives, it may not wake anyone. Phones on silent, do-not-disturb schedules, and a single short buzz at 2 a.m. all work against a text message.
A rural telephone company learned this the hard way. An air conditioner failed at one of its sites overnight. The text notification did not go through, and the site stayed above 100 F for several hours before anyone responded. Every piece of the monitoring worked except the last step: getting a human being to act.
A phone call demands attention in a way a text does not. It rings until answered or until voicemail picks up. It can repeat. It can speak the alarm so the technician knows what failed before getting out of bed.
Voice dialers also support escalation. If the first person on the list does not answer or acknowledge, the dialer calls the next person. That turns one point of failure - a single on-call phone - into a chain.
Voice notification works best when it is reserved for alarms that truly need someone now:
Everything else can stay on email. Keeping voice calls for critical alarms protects their value. If the phone rings, it matters.
Traditionally, a site dialer connected to a plain old telephone service (POTS) line was valued as an independent path. If the data network went down, the dialer could still call out over the copper telephone network.
That independence is weaker than it used to be. Many carriers now carry traditional voice calls over IP transport internally, and signaling that once ran on dedicated circuits now often rides the same IP networks as everything else. A POTS line on the customer side may still depend on IP infrastructure somewhere upstream. A network outage that takes down data services can affect traditional calls too.
That does not make POTS dialing useless. It means teams should evaluate notification paths by what they actually depend on, not by what they used to depend on.
| Notification Path | Strengths | Dependencies To Check |
|---|---|---|
| Inexpensive, easy to route to groups, good for non-urgent alarms | Mail server, IP network, recipient checking email | |
| Text via email-to-text gateway | Reaches phones without extra hardware | Carrier gateway availability, which can change without notice |
| Native SMS via cellular modem | Does not rely on email gateways | Cellular coverage at the head end; recurring service plan |
| Voice call via POTS dialer | Rings until answered; supports escalation | Telephone line, plus any IP transport the carrier uses upstream |
| Voice call over SIP | Uses existing VoIP infrastructure; no copper line needed | IP network and SIP provider; security of the SIP connection |
A cellular path can add real diversity, but only if it does not share infrastructure with the primary path. Ask where each path actually goes before assuming they are independent.
As telephone companies move their own voice services to SIP, it is natural to want alarm calls placed over SIP too. That raises a network design question that experienced telco engineers flag immediately: SIP traffic should not share a network with equipment monitoring traffic.
There are two reasons:
The preferred approach is a physically separate Ethernet interface dedicated to SIP, with VLAN tagging as a fallback where a separate port is not practical. Alarm masters with several network interfaces make this straightforward. DPS's T/Mon alarm masters include multiple Ethernet ports, so voice, monitoring, and IT traffic can each have their own interface. DPS discusses broader isolation practices on its secure monitoring page.
DPS offers Site Dialer options that work with NetGuardian RTUs and with T/Mon alarm masters, including the T/Mon MINI, T/Mon SLIM, and T/Mon LNX. The current T/Mon Site Dialer uses a traditional POTS telephone connection to place voice calls for selected alarms.
Interest in SIP-based dialing is growing among carriers that have moved their own voice services to SIP. Teams that want SIP dialing in a future budget should describe their requirements in writing now - which alarms should call, who should be called, escalation rules, and network separation - so any future option can be evaluated against them.
For immediate needs, a practical combination is:
A basic rule of alarm notification is that a silent system is not proof of a healthy network. DPS factory training makes the point with asynchronous messages: their failure mode is silence. A discontinued text gateway, an expired mail password, or a disconnected phone line all look exactly like "no alarms."
Protect against that with routine checks:
Site RTUs such as units in the NetGuardian family can also send their own email and SNMP traps directly, adding another independent route for critical alarms.
A phone call rings until answered and is far more likely to wake an on-call technician than an email or text. Reserve calls for critical alarms and keep everything else on email.
If texts were sent through a carrier's email-to-text gateway, that gateway may have been discontinued or restricted. Native SMS through a cellular modem avoids that dependency.
Not always. Many carriers carry traditional voice calls over IP transport internally, so a network outage can affect POTS calls too. Evaluate what each path actually depends on.
No. Use a dedicated Ethernet interface for SIP, or VLAN tagging if a separate port is not available. SIP connections are common attack targets and have different network requirements from monitoring traffic.
Only critical ones: power failure on batteries, high temperature, loss of critical equipment, and combined conditions such as power failure with low fuel.
At least monthly, and after any change to staff, phone numbers, mail servers, or carriers. Confirm each method actually arrives.
If your critical alarms depend on a text message that might not arrive, or might not wake anyone, it is worth adding a path that rings. DPS Telecom has built alarm monitoring and notification equipment since 1986 and can help you match each alarm to the notification method it deserves. Get a Free Consultation, or call 1-800-693-0351 or email sales@dpstele.com.
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...
