VoIP Versus Intrusion Alarm

Symptom:

Your intrusion alarm is programmed to make a voice-type phone call to an outside monitoring service when you, your pet or a burglar sets off the alarm. Also, typically the alarm machine will periodically send a test message saying that the alarm is not ringing, which the service will acknowledge, so the alarm machine knows that communication is working. You install VoIP (Voice over Internet Protocol). Calls to the monitor either don't get made, or are made but ignored, and the alarm machine displays an appropriate error code for communication failure.

What's happening:

There are two problems here. First, it is common for the alarm machine to be wired like this:

House Phones ----+-- Alarm Machine ---- Phone Company
DTMF Generator --/

The DTMF generator is the part of the alarm machine that dials the monitor service's phone number, and then uses tones to report whether or not the alarm is ringing. When a message is to go out, the machine switches the phone connection away from the house phones, killing the connection for a possibly chatty human, and over to the DTMF generator. But when installing VoIP you stopped paying the phone company for voice service, and the alarm machine's call via the phone company goes nowhere.

Once you work around this problem and send the call to the ATA (Analog Telephone Adapter) for VoIP, you find that the ATA is stripping out DTMF and packaging it up in digital payload packets, either RFC 2833 packets on the voice channel or SIP Info packets on the control channel, depending on the configuration. How many alarm monitor services are watching for VoIP digital payloads? Only the smarter ones.

How to fix:

For the routing problem, normally the ATA is installed among the house phones. The right fix is to run a wire from the ATA's phone jack to the alarm machine's uplink, replacing the now-defunct uplink to the phone company. Good luck running the wire neatly and safely. Or else relocate the ATA near the phone company connection, in the likely case that internet access is feasible there.

A quick fix is to exchange the phone wires on the alarm machine, so the whole house (including the ATA) becomes the uplink from the alarm machine. The alarm machine can't kick off a chatty human, but if the phones are silent it can then talk to the ATA, dial out, and send its DTMF messages.

To bring communication back to life, I reconfigured my ATA to send DTMF in-band, that is, as audio tones (packaged as if they were sounds) rather than as digital payloads. Digital (typically RFC 2833) is more reliable, but we don't notice missed DTMF signals when dialling or responding to IVRs (voice menus). It is likely that in-band DTMF will help in many cases but not all; it depends on how aggressive the ATA's compression is and what the monitor's equipment is paying attention to. Also, in theory the VoIP provider might convert in-band DTMF to RFC 2833 just to give a better customer experience, in which case the intervention at your ATA will have no effect.

Credit to CallCentric customer service (my VoIP provider) for suggesting this intervention.

The VoIP ATA compresses the audio signal to reduce bandwidth; the G.729 codec compresses by a factor of 8. RFC 2833 mentions that aggressive compression may alter the sound enough to impair recognition of DTMF. However, jimc thinks that a pair of sine wave tones would be the easiest sounds to compress accurately. Even so, be alert for reliability problems with in-band DTMF.

Glossary:

VoIP

Voice over Internet Protocol

DTMF

Dual Tone Multi Frequency -- tones from a phone keypad

ATA

Analog Telephone Adapter -- converts phone audio to digital form and sends it to/from the VoIP provider

RFC

Request for Comments -- the governing law of the Internet

SIP

Session Initiation Protocol -- to connect a VoIP call

IVR

Interactive Voice Response -- a voice menu