alarm POTS lines

Home » Asterisk Users » alarm POTS lines
Asterisk Users 10 Comments


I’ve brought this up in the past and there was a good discussion – am
wondering if there have been any new developments.

Our dialtone service, like I am sure is true for most ITSPs, touts the
ability to drop your POTs lines for significant savings. For businesses
we have a low-cost Atom based PBX and a “fax relay” setup locally with
hylafax/iaxmodem to solve that issue, and it is working very well. We
don’t however, have a solution for their alarm lines.

The problem is of course that modem calls over VoIP are flaky at best.
Even though these alarm calls are low baud rate, when we test with the
alarm company we only pass about 30% of the time (ulaw from customer site
to our central switch, then out a T1). To be fair there is no QoS on
their Internet links yet, and that certainly plays a role.

But it seems to me that there should be a solution much like our “fax
relay”, where we literally accept the fax call over the local LAN, produce
a PDF file, transfer it to the central switch which then dials it back out
over a T1. In that case the only “modem over VoIP” is on their local LAN,
which has performed well for us.

I would love to see a DSP “modem” that could answer an asterisk channel,
send the data stream over TCP to some remote asterisk, which could then
“relay” the stream by making an outbound DSP modem call on a PSTN trunk.
Has anyone attempted anything like this?

As an aside, since the recent thread on Seagate Dockstar installs, I have
several running. This would be the perfect platform for the “relay” on
the customer end, being so ridiculously cheap (I bought three for $30
each, plus 3 $10 4G USB sticks).

So hoping this will spark some comments on the concept in general, and
really hoping someone has actually tackled something similar. It could
open up a nice niche for even residential customers with expensive POTS
lines dedicated to alarm systems.


10 thoughts on - alarm POTS lines

  • It can’t be relayed; the alarm protocol is interactive, so a solution
    analogous to T.38 must be used.

    Guess what? There is already a standard for this, called V.150, Modem
    over IP. It certainly would be possible to implement this sort of thing
    for Asterisk, and some small steps in that direction have been taken way
    in the past… I’d suggest doing some Google searching to see what you
    can find.

    Or those customers could switch to cell-connected alarm panels (which
    are rapidly becoming less expensive and provide reliability benefits),
    or even IP-connected alarm panels. Either choice would be better in the
    long term than trying to convince an ancient alarm panel’s modem to work
    over a packet network.

  • I did find an interesting thread for this in 2006 🙂 I wonder if it is
    being made overly complicated, though. I guess what I was envisioning is
    something like IAXModem that would provide a serial device… if that
    could be done, to the point where minicom or similar could actually make
    data calls via a PSTN line, then I would be very close to what I need.

    I envision this:

    An ATA on the local LAN with a dockstar running asterisk. An instance on
    this machine of an “iaxmodem-like” DSP that registers as an IAX extension
    and can be called by the ATA. A “serial proxy” daemon on that same
    machine that has the tty device open and sees the inbound call, answers
    it, then constructs a TCP session to the “serial proxy” daemon on the
    remote asterisk server. On the remote asterisk server another instance of
    an “iaxmodem-like” DSP accepts the Hayes commands to dial out again to the
    alarm company’s modem pool, and once connected starts feeding it the data
    stream coming from the alarm panel at the client’s site, and sends back
    the replies in the same manner.

    I really think this would work, and the daemon wouldn’t be that difficult
    to write. I don’t think I have a prayer of hacking iaxmodem to do what is
    needed to emulate a modem though 🙂 Between the dockstar and the ATA
    (which I am already providing for dialtone anyway) it is around a $40 cost
    solution for me, and the customer gets to drop the POTS line, which is
    around a $30/month savings for them. I’d probably just eat the added cost
    to get the customer, and could even charge some modest fee for the “alarm
    connection” that would still in the end save them money.

    Totally agreed – but in our remote area of the world ancient technology will
    continue to be used for some time to come, and I need a way to sell service to
    those people that will refuse to replace any of their equipment. I don’t think
    I am alone here… and the concept would also apply to credit card processing
    machines, ATM machines, and other embedded modem devices that will probaby be
    with us for some time. Look at fax, for example. Wouldn’t we love to tell our
    customers to dump their old fax machines for scanners and email? Some people
    just won’t until the thing catches fire or otherwise dies.

    So is there anyone out there with the DSP skills to do the “iaxmodem-like” part
    of what I describe above? Would a bounty raise any interest? A little
    more searching today turned up this:

    Which is REALLY close to what I need…


  • href=””>

    Alarm panel communication, at least with Ademco, is done only with
    DTMF. When I tested the Asterisk AlarmReceiver application I found
    that the DTMF tones were so short they weren’t always recognized by my
    ATA in RFC 2833 mode. Changing it to inband DTMF worked better, but
    then I was having issues with the AlarmReceiver application. Have a
    look at the below link, which touches on alarm panel communicates.

    Since the communication is done with short DTMF it only takes a few
    seconds once the remote end answers to relay the message. This is not
    the same as modem communication when sending a fax.

    At least for alarm communication the solution would be an ATA that can
    correctly recognize and translate the DTMF to RFC 2833. Then it is up
    to the remote end to correctly translate this back to DTMF to send
    over the T1. The below link explains the different DTMF modes
    supported by Asterisk.


  • You all do know that this is something you could be sued for since this is ‘life safety equipment’ ? I’ve heard from multiple sources that if it isn’t against the nfpa that it will be very soon
    Ask yourself if you want to be subject to a lawsuit if someones house is robbed, someone dies, house/business burns down and the alarm panel is unable to communicate? Ask your insurance rep if they will cover you doing this type of voip stuff and they’ll most likely tell you not too. Bottom line is this is NOT a smart thing to put on voip.

    Tammy A Wisdom
    Summit Open Source Development Group

  • nfpa only applies where nfpa is actually a requirement, ANYTHING anyone
    does that is not required (residential fire and burglar alarm) is better
    than the alternative of nothing at all. Calling yourself a ulc certified
    monitoring center or something like that is a no no if you don’t meet
    those requirements, but selling a service as what it is, is perfectly
    fine, if you are not guaranteeing something you can’t provide you are in
    the clear.

    All that aside things are moving to direct tcp/ip communication, using
    voip to talk to antiquated monitoring equipment is just an interim fix
    as the consumer end technology is moving faster than the central station
    technology. The argument voip is unreliable compared to pots really is
    not true if everything is setup properly. tcp/ip and anything that lives
    on top of that protocol like voip etc., has much more flexible routing
    and failover than any pots circuit could ever hope to have, and can use
    multiple independant paths for communication, and the connection can be
    held open like a dvacs circuit for continuous monitoring without all the
    overhead of individual copper pairs and multiplexers at the monitoring
    center. Its hard for the manufacturers of this equipment to stomach
    though that a pc with a network card is actually more functional than a
    multimillion dollar piece of hardware they used to sell, so change is
    slow coming.


  • jon pounder wrote:
    You want to bet your business and liability insurance on that position?

    Anyone considering this direction had better run it by their business
    insurance risk management department, and a good lawyer versed in laws
    involved in the state(s) involved.
    VOIP is NOT yet as reliable as a POTS circuit. The degree of
    unreliability depends on the providers involved, but network managers
    have yet to put into place It certainly is getting somewhat better, and
    one can skew the statistics with the volume of data involved, but when
    life safety issues are involved, it isn’t there yet. Even Mobile ( radio
    ) backup is considered secondary for reporting, and then not for
    fire/sprinkler systems.

    the safest circuit for monitoring, though seldom available anymore, is
    the supervised loop to the monitoring station.
    A PC with it’s inherent frailty is way down the list in terms of reliability

    John Novack

  • Jeff LaCoursiere wrote:

    I can’t pretend to know what an alarm system needs out of a modem, but
    as far as iaxmodem acquiring data-modem capabilities that part is
    already developing. IAXmodem inherits its DSP capabilities from
    spandsp, and you can see on the spandsp that certain modem types are
    already available in the newer spandsp snapshots. That doesn’t mean
    that you can expect iaxmodem or spandsp to work for you anytime soon
    out-of-the box, but know that eventually you’ll see this happen.


    There are many reasons besides ignorance that faxes (and thus fax
    machines) are still around. For one, there is a serious technological
    work-flow hurdle involved with the scan-to-email approach replacing fax
    completely because, for one, it’s not like you can do that for every one
    of your would-be fax recipients. Consequently trying to replace faxing
    with a scan-to-email approach ultimately means that someone still has to
    do some faxing. As it’s typically easier to send a fax than to
    scan/attach/email, work-flow productivity will actually drop by forcing
    the abandonment of fax machines (i.e. by utilizing a mail-to-fax service
    for intended recipients where a direct e-mail will not work).

    (I’m convinced that fax machines are with us for the long-haul. Now,
    whether or not futuristic fax machines operate directly with a POTS line
    or with IP connectivity seems clear that it will eventually become a
    hybridization, but I truly believe that those who engineer that future
    technology will necessarily have to divorce the IP-side of the systems
    away from the whole modulation/demodulation over audio channels bit. On
    an IP network it simply makes no sense to take a data stream, and
    modulate it to audio only to demodulate it back to a data stream again
    because the IP network makes the modulation/demodulation superfluous
    where it was necessary on the PSTN. So this running of T.38 FoIP over
    SIP VoIP is consequently a passing phase; it’s not a solid-enough
    solution to replace traditional faxing.)

    As I said before, I think the work is already being done. And for what
    it’s worth, the monthly $30 or $40 summed over years is a petty amount
    compared to the necessary development cost of the kinds of technologies
    you’re discussing. You’ll gladly pay $40 monthly for life than need to
    pay $100K to develop this stuff.

    And note that it uses spandsp (albeit a newer snapshot than iaxmodem
    currently uses), so iaxmodem is therefore not far-off from where you
    claim to need it to be.



  • I did notice that he based his stuff on a newer spandsp, and that his app is
    actually functional to a point, though it is based on jack audio which I
    really don’t need. So it doesn’t seem far off at all. In fact it seems that
    it should be possible to take the functional parts from his work and merge it
    into iaxmodem. Not too far beyond my own capabilities, but for lack of time 🙂

    Ah, but it is not for me personally, it is for the ~20,000 residents of the US
    Virgin Islands that currently pay $40/month for a POTS line just for their
    alarm monitoring. As far as the reliability of POTS lines – in our area, that
    is exactly the problem. The ancient copper pairs are rusting in our salt air
    and haven’t been replaced in decades, and the phone company is dealing with
    bankruptcy, so won’t be addressing it anytime soon. Dead lines are a common
    occurance, and I am willing to bet that many of the alarm panels are at this
    moment unable to place calls and the owner doesn’t even know.

    Regardless the solution would also be good for non-emergency equipment like
    ATMs, postage stamp meters, CC machines, etc. Not that the “product” has a ten
    year life span or anything, but what does these days?

    Thanks everyone for the comments – I was unaware of the DTMF methods used by
    some panels, and may start running some tests in our lab.

    I’ll post back to the list if we get anything working reliably.


  • If the owner doesn’t know, then they have a pretty terrible monitoring
    service 🙂 All the ones I am aware of here will notice that a
    customer’s panel has not ‘called home’ in a short period of time and
    call the customer to let them know.

  • You would desire the entire path to be UL listed if you are doing
    anything other than facilitating the phone call to the central
    station. There is app_alarmreciever in Asterisk, and furthermore the
    ContactID protocol is pure DTMF so that should work without issues.
    But why use phone lines at all? Recently I installed a DSC T-Link
    TL260GS which uses internet and GSM, there is no phone line plugged
    into the alarm panel at all.

    SIA format is 110 or 300 baud, ContactID is (rapid) DTMF.