For our VoIP ATA we have the Obihai OBi200.
We also have a Napco Gemini
series intrusion alarm.
It is programmed to send a message to an outside monitoring service using
a voice phone line in a digital mode.
The alarm machine is unable to contact the monitoring service over VoIP. The goal here is to fix it; otherwise we are going to have to give up the outside monitoring feature.
Likely similar issues will be seen with any ATA, or type of alarm, or monitoring service equipment.
The alarm's phone communication is supposed to be set up like this: House phones are each wired into a punch block, all in parallel, with one uplink. That connects to the alarm machine. It has a transfer switch which normally connects the house uplink to its own uplink, which runs to the real uplink to the phone company, which in our case used to be the FiOS ONT (their VoIP).
However, when there is an alarm the transfer switch disconnects the house uplink and connects to the machine's internal DTMF generator (and/or possibly a 300 baud modem, or possibly other coding styles). The machine dials the alarm company's number, their automated equipment answers, and the machine reports the alarm. There is also a communications test mode, which sends a test code even though there is no alarm. The importance of the transfer switch is, the alarm machine can kick off a chatty human and get exclusive use of the phone line.
Now we complicate matters by installing our own VoIP ATA among the house phones, and cancelling the phone company's voice service. When there is an alarm the machine gets exclusive use of the pathway to the discontinued phone company voice link, and the call goes nowhere.
This was fixed
by interchanging the phone input and output on the
alarm machine. This means that when there is an alarm the internal generator
gets connected to the house phones. If someone is chattering, the alarm
machine cannot kick the person off, but when nobody else is using the phone
it can, and actually does, connect to the ATA and dial the call.
This is good progress, but unfortunately the alarm monitoring service does not recognize the communication test message.
CallCentric customer service suggests trying to do DTMF signalling in-band (in the ATA), and to disable codecs, but keeping PCMU and PCMA. This is not a configuration normally supported by CallCentric.
In one blog post the author said that G.729 and G.726 codecs would not pass DTMF tones properly, which is probably why CallCentric suggested disabling them. RFC 2833 also mentions that aggressive compression may alter the tones enough that the other end cannot recognize them reliably. However, DTMF tones are well within the passband of a phone audio channel, and I would be surprised if actually used codecs actually trash the DTMF. On the other hand, I thought that it was very plausible that the ATA would intercept DTMF and send it in non-audio SIP or RTP (RFC 2833) packets, whereas the monitoring service is plausibly totally analog and is not paying attention to the RFC 2833 payloads. Therefore my first trial was to put DTMF in-band.
One possible red herring: we can reliably use IVR (voice menus) on the other end, responding with DTMF. If they have VoIP all the way, they will receive and respond to the RFC 2833 packets. Whereas if the signal path includes circuit-switched hops, at the point where VoIP ends the RFC 2833 tone or DTMF payloads will be played back as authentic audio tones, in-band. So the fact that IVR works doesn't tell us much about how to communicate with the alarm monitoring service.
Test Procedure:
Authenticate to Toucan (the OBi200 ATA).
Try setting: Service Providers -> ITSP Profile A -> General -> DTMFMethod -> (change to) InBand. Choices are Auto (is default), InBand, RFC2833, SIPinfo.
The last comm test flurry was 10-03 20:08 to 21:00, about 20 calls at various intervals. It sas calling the alarm company's number. The last call (spam) on the report was from 1 000 000 0000 at 10-05 12:18.
Testing: House can dial out (to cellphone). Voice quality incoming is reasonable. Voice quality outbound is awful while inbound is decent. An outsider can call in, and voice quality is normal (both directions).
Doing this test is hard. Let's try InBand again. When the two phones are close and can hear each other, they get really confused, and the house -> cellphone channel takes precedence. With two testers in different rooms, voice quality is normal in both directions.
I also tried disabling codecs (with DTMFMethod = Auto), keeping PCMU and PCMA enabled but none other. The voice quality was not improved, which suggested to me that my various interventions were not causing the poor incoming quality. I did not do a complete test of disabling codecs and I reverted to the default, which is PCMU, PCMA, G.729, G.726-32, but iLBC disabled.
Setting off a communications test: Simultaneously press and hold * and A (on 8 key) for 10 secs. It did cause one comm test call. Outcome? After several minutes the comm test failure error message vanished. There were no further comm test calls (checked 4 hours later), where when it's failing it will retry up to 20 times about every 3 minutes on average.
Complete functional test: We turned on the alarm machine, then opened a forbidden window, setting off the alarm. The first time we entered the alarm reset code right away, and no sign of communication was found. On the second attempt we let the alarm be noisy for 30 seconds, giving it enough time to dial the number and play the alarm report codes. A minute or two later we got a voice call back from the alarm company. Functional test was passed.
Conclusion: the communication problem was fixed by putting DTMF in band. It was not necessary to disable codecs.