Security company's alarm center problem with notification via FXS port


Hello, I have the following problem:
I used an analog telephone exchange in one location in combination with an alarm exchange that was connected to the security company’s alarm center.
And the communication to the call center over the analog line worked properly.

Afterwards, the old power plant was replaced with UCM 6202 at the same location.
The plan was to continue communication via the analog FXS port at the UCM 6202 exchange.
The FXS port on the exchange is set up and working properly…when an alarm occurs, the alarm control panel makes a regular call via the FXS port on UCM 6202, but the alarm center reports that they have not received anything that their center can recognize.
I have very little technical support from the security company so I have to test only on my own and try to fix the problem.

What I would like to mention is that the ISP has set up a sip trunk to the UCM 6202 ip exchange…an analog line was raised from the same provider before this, i.e. an analog line over their ATA device.
My assumption is that some signal distortion occurs when sending DTMF tones from the UCM 6202 to the security company’s alarm center.

Current settings on UCM 6202:
*DTMF Mode: Inband
*Jiter Buffer Adaptiv Size 100, Max 400 (I experimented with these things)
*Echo Cacellation ON (I experimented with these things)

I did a few combinations but i didn’t get the correct call.
I also did captured packets when the alarm was triggered…I did the analysis RTP stream (with Wireshark)…and I see that they are correct…I record them and return the tone to one of the DTMFChecker and get the numbers that were sent.

Does anyone have any idea what else I can try?


Create separate trunk for alarm (turn off register but provide all data) - shadow trunk
Codec ONLY PCM (a/u - depend on your location)

Any other codec can destroy transition as it will convert it.

Alarm sent modem signal or DTMF codes ?


Most alarms systems do not send DTMF tones to signify the alarm condition. There are numerous alarm formats and some are somewhat more tolerable of less than ideal conditions than others. However, having said that, if the alarm notification is a critical aspect you would be wise to abandon the ATA and revert to cellular or copper line. There are a number of insurance companies that take a dim view of alarm signaling over VoIP and may make it difficult for you (or your client) to get a claim honored. In fact, you may be assuming some liability if a incident occurs and the alarm fails to do what it should. I am surprised that the alarm company did not steer you away from the effort and I guess you now know why they won’t help.

The setting changes being made are pretty much isolated to the ATA side of the conversation and I imagine that the alarm company is experiencing issues on their end with how the data is delivered and not anything to do with DTMF.

You can do a Google search to get a feel for what reporting formats there are and while some folks have indicated success using an ATA, the type of alarm and the report format (speed and signaling type) are the key elements.


Personally I would use an ATA (if you can get it, and keep it, working, but only where there is a backup cellular alerting mechanism. I would not use an ATA by itself.

In fact, several alarm systems have an Internet module that lets you send alarms to the monitoring station over the Internet. That seems to me to be a better solution.


Thank you all for the answers, You helped me to find some solution :smiley:
I only used the PCMA codec, but the situation is the same
We switched to optics and we no longer have a copper line :slight_smile:
The new exchanges have IP communicators, but that would mean changing almost the entire alarm.

I used ATA SPA 2102 and everything works fine. It seems that the FXS ports on the UCM 6202 do not have all the possibilities as ATA and that they are left only for making calls via analog phones, and for such situations the ATA is used :slight_smile: