Fire / Intrusion Alarm Panel over VoIP

[mciarfello]

Anyone implement their fire / intrusion based alarm systems over VoIP? These systems dial a phone number to the alarm receiver (server, etc.) and communicate a slow speed protocol between eachother. Worked great with the TDM phone system. Getting communication reliability issues when put on VoIP.

The "server" keeps printing out "data error" messages on an intermittent basis. Sometimes the alarm messages goe through just fine. I'd say it's 50% good / bad.

So, Alarm transmitter to VG224 port, H.323 over LAN to another VG224 port to the alarm receiver.

Worked with TAC today. The reliability is better but not perfect.

Just wondering if anyone had a GOOD experience with this. Otherwise, I will have to find another solution.

I know, why would you want to do this? Because it was on the TDM phone system and we have to try at this stage before the suggestions come out. There are also off-site

alarms that need to dial over the PSTN into the alarm receiver on campus, so it can't be avoided.

Thanks

[Nicholas Matthews]

We find that the best solution for the fire alarm systems is H323 with no DTMF configured. If you configure h245 alphanumeric or signal the DTMF protocols that the fire alarms use get distorted and won't work correctly.

It's definitely possible to get these up and working correctly.

Another common problem we see is that most of these fire alarm systems are more legacy telephony based, when stations used higher voltages. Due to hardware constraints and power usage, most of the Cisco analog connections have used a larger-but-still-in-specification voltage value. It's common to see voltage alarms with these devices.

This problem has recently been solved with the third generation VIC cards, with the VIC3-4FXO and the likes. These cards have increased the idle and ringing voltage to allow for greater interoperability.

So in short - yes you should be able to do this.

[mciarfello]

Thanks for replying back even though I posted in the wrong group. (Was tired.)

Here's the config the TAC engineer suggested.

dial-peer voice 224 voip

destination-pattern 5877

session target ipv4:10.76.227.136

dtmf-relay rtp-nte

codec g711ulaw

fax rate 14400

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco

!

So you suggest?

no dtmf-relay

He is tricking the router into thinking it's a T38 fax call and when (of course) we don't hear the fax tones, fallback to cisco protocol. This seemed to improve the number of good alarm sender to alarm receiver calls.

Where will the voltage alarms show up at? Any special commands to turn on to put it in the logg?

Thanks

[Nicholas Matthews]

There would be two methods to configure this, depending on how the fire alarm works.

Most of the fire alarms I've seen use some funky DTMF protocol where they fire off 50-60 DTMF digits in a matter of seconds and they've devised an entire protocol around sending digits. This may be confusing, because sometimes people will think it's a modem call because of the 'data transfer mechanism'. I would set up a sniffer, just have the thing call an actual phone, or use a butt set and find out if it's sending DTMF or actual modem/fax tones.

If it's an actual modem, you probably want to use modem passthrough mode 'modem passthrough nse codec g711ulaw' instead of T38.

My guess is that it's DTMF based.

The voltage alarms I was referring to originate on the fire alarms themselves. The router is oblivious to any voltage problem the fire alarm may have.

hth,

nick

[mciarfello]

Excellent. Thanks for the help.

[rbays@angelo.edu]

This post was helpful to me so I thought I would add in some additional info I received from TAC while working on a similar issue.  I have several security alarms that weren't able to signal through my MGCP controlled VG224s and 2821 FXS ports.  TAC replied:

The alarm system uses short duration (less than 50msec) DTMF digits to pass alarm details to a monitoring system. Since the FXS is under MGCP control and implicit to the way the MGCP control operates is DTMF events are to be reported back to the CallManager as they occur. The DSP recognizes the start of a DTMF tone and mutes the RTP stream (to prevent the in band DTMF tone double triggering as and when the out of band event occurs). As the DTMF tone from the alarm system is less than the DSP is expecting (generally a DSP needs greater than 50 msec of DTMF) , it does not send a MGCP NOTIFY message to the CallManager to indicated a DTMF event has occurred. Since the audio is also muted, the alarm details are not passed.

There is also an Enhancement bug open for this issue and is still in the open state:

CSCsg63981    Request to Support MGCP Packages Event Parameter - DTMF Tone Duration

So as was pointed out in the post, moving some of the FXS ports off to H323 and peering them with an H323 controlled FXO port connected to a POTS line solved the issue. As also pointed out above, DTMF relay on the peers is disabled so it doesn't trip up the signaling duration from the alarm panels.  While you still have to have some sort of analog service, this solution lets you centralize it at a particular location rather than having lines for alarms at each panel.  Hope this help someone else out.

[bill]

It does. Thank you very much

[harrismichael180]

Hello,

Sorry for answering for your question more years later, but Google ranks high your page in the list of the search results and I think it would be great to add some fresh information to your post. Here's an interesting guide that can be found at Codeproject: http://www.codeproject.com/Articles/787293/How-to-send-a-Contact-ID-alarm-to-the-Central-Stat It demonstrates a possible solution on how to make connection between your alarm system and the Central Station over your VoIP network by using an ATA device. This way you can receive alerts from the Central Station and you can even send alarm to the Station in case of emergency by using your own application. (This program has been written in C#.)

This solution is based on the Contact ID protocol that ensures the communication between the fire/intrusion alarm system and the alarm monitoring company. The data transmission can be carried out through a VoIP call. The author of this article used the prewritten VoIP components of Ozeki VoIP SIP SDK that defines the necessary VoIP functionality. It uses SIP protocol.

All the best, 

Harris

[mciarfello]

I think it's great that you added additional information.  This centralized and searchable post with all information might help others someday.

Keep adding.

I'm not sure if the MGCP enhancement made it yet.  Looks like the bug ID is only readable by Cisco internal.