Security System Monitoring over IP or VOIP?

[linuxha]

Some of the ATA's will disable the analog port when the Ethernet cable is disconnected which is read by the panel when the ATA goes offline (not registered with SIP provider/PBX).  I agree that VoIP for alarm communication is much different than VoIP for voice and cellular does make much more sense. 

 
If you lose your ISP access you may still have your home network, so the Ethernet won't go down.
 

In many installations it is possible to use cellular as primary and an ATA for VoIP as backup, but as with any VoIP installation, QoS is the most important point because any interruption in data communication can cause alarm data to not be readable by the alarm center.
 
Also, if using an ATA, remember to put your ATA, network switch, network router, and DSL modem/cable modem/IAD/ONT on UPS as well, because all will need power to continue operation during a power outage in support of VoIP.

 
A lesson we learned from TS Sandy (it was a TS when it hit NJ but was a Hurricane shortly before hand). Most ISPs don't have their internet access back'd up. Not sure about the VoIP or the their Voice services (not a real PSTN service). It was interesting to see the jury rigged gas generators tide up at comm's level on the poles.

 

[Del91574]

Not an expert on security or ATAs being used for alarms but that article pointed out many mistakes.
 
I don't know if you can config an ATA to drop the line voltage (FXS port)  on loss of IP connectivity to the VoIP CO. If you can't then I'd agree 100%. I don't think my SPA-3102 can do that.
 
[Edit]: Sorry about the multiple posts. I think I removed the extras.

That install was a comedy of errors actually, with an unfortunate loss of life and should affect the industry. I went through the documents on a FOI act and know the expert. The takeaway of that install is the system was installed with a cellular backup and was still connected to the VOIP line. (ATA if you look in the picture, Arris FYI, one of THE most popular being installed in the wild) and the system did NOT ever switch over to cell after the viable line via the VOIP was disabled/cut. Disregard the tamper loop discussion and other installation mistakes. The system, just like HAI, with a line cut monitor would never report a fault with no viable communications path.
 
An ATA, or connecting a panel to a box without a viable connection is akin to hoping for the best and negating the line cut supervision on the panel. Nextalarm is hit or miss whether or not they truly supervise their connection. There's lots of factors, but honestly, it should not be considered as a viable choice. Keep in mind, NA, and many of their "solutions" are not UL and NA doesn't monitor their own accounts....there's a lot of other dirty little secrets with them.
 
VOIP for alarm is exactly that. TCP/IP communication is entirely different. A true TCP/IP path from the panel (albeit via dialer capture) is supervised by the CS, assuming they monitor the heartbeat and the keep alive functions of the communicator.
 
Personally, being in trade, I wouldn't go with TCP/IP as a comms route on a basic residential service. Same reason why fire marshals don't allow a 100% IP based monitoring on fire alarm for both dialers. Too easy for the path to go down. There's no silver bullet, and yes, Sandy and a few other items have proven that even cellular and POTS aren't without faults, but I can attest, during Sandy, my POTS did NOT go down at all. Net and cell (there were about 60% of cell towers down in the NE) did go down. That's coming from a guy that installs and maintains CS' and also installs.

 

[Del91574]

If you lose your ISP access you may still have your home network, so the Ethernet won't go down.
 
 
A lesson we learned from TS Sandy (it was a TS when it hit NJ but was a Hurricane shortly before hand). Most ISPs don't have their internet access back'd up. Not sure about the VoIP or the their Voice services (not a real PSTN service). It was interesting to see the jury rigged gas generators tide up at comm's level on the poles.

PSTN is required to have standards and recovery plans. ISP's are NOT. Remember, POTS is a utility and governed as such. Granted, media can be destroyed and infrastructure damaged, but the government mandates one and not the other. And from first hand experience, while ISP's had some services running, the repeaters and otehr infrastructure in areas connecting to the trunks were down and significantly unreliable.

 

[ano]

PSTN is required to have standards and recovery plans. ISP's are NOT. Remember, POTS is a utility and governed as such. Granted, media can be destroyed and infrastructure damaged, but the government mandates one and not the other. And from first hand experience, while ISP's had some services running, the repeaters and otehr infrastructure in areas connecting to the trunks were down and significantly unreliable.

If you are not aware, back in 2012, both AT&T and Verizon have started the process of requesting that they be allowed to shut down the PSTN.  If you think they are going to have and maintain it forever, you might want to look into that.
 
In Jan. 2014 the FCC agreed to start the process...
http://arstechnica.com/tech-policy/2014/01/att-plan-to-shut-off-public-switched-telephone-network-moves-ahead-at-fcc/

 

[Del91574]

If you are not aware, back in 2012, both AT&T and Verizon have started the process of requesting that they be allowed to shut down the PSTN.  If you think they are going to have and maintain it forever, you might want to look into that.
 
In Jan. 2014 the FCC agreed to start the process...
http://arstechnica.com/tech-policy/2014/01/att-plan-to-shut-off-public-switched-telephone-network-moves-ahead-at-fcc/

I am very aware of what is going on in the industry and communications. I deal with it daily.
 
It may be true, however there hasn't been a formal ruling by the FCC as to whether or not VOIP is going to be mandated to meet the regulations under the 1934 telecommunications act and what the definition of VOIP is on the national, state, and utility regulatory statutes. Once the decision is actually made, I'd be willing to wager there's going to be more involved to move the services or transportation methods to the present utility standards. The main reason why there's no regulatory at this point is the FCC is hoping the industry will develop their own solutions free from the normal regulatory obligations.
 
The players are arguing whether or not it's a telecommunications platform of information service. There's also regulatory which are preventing them in doing such without understanding the impact. It's not like the AMPS network, analog cell or 1G data that is simply switched off and migrated to another platform.
 
Given how deregulation has worked for the air travel industry, the electricity industry and a few others, I wouldn't want to rush into something blindly by a sweeping "by 2020" mandate. It's too early and it's not going to be an easy or fast process based on all the interconnected systems and proving the "hold harmless" portion of any clause.
 
While not exceptionally popular, it's going to be a while before PSTN goes away.

 

[StarTrekDoors]

If you lose your ISP access you may still have your home network, so the Ethernet won't go down.

 
I absolutely agree that loss of the ISP could be catastrophic with regard to alarm and notification.  I stand firmly by my recommendation to consider VoIP using an ATA as secondary to a more reliable primary. VoIP is fine for voice, but alarms, like fire alarm, burglary, or other - those always need to work and all solutions require a UPS for survivability!

 

[bdAZ]

An update here from OP ..
 
So I ordered NextAlarm's new ABN4A device, had it shipped to me up here and Canada, plugged it in, everything registered and worked great. Then I went to register a monitoring account. The new system won't support Canada! What a pain! I've spent $100 in shipping and customs, their website clearly states "scores of satisfied customers across the United States and Canada..." (https://info.nextalarm.com/about-us/) it wasn't until I tried the autoregister form. Calls to sales and tech support and they told me "our new system doesn't support Canada at this time."
 
Apparently their older system that does VOIP monitoring DOES support Canada. So now I'm on the hunt for one of their older devices (the "Sparrow2" device). Anyone know where I can find one of these? These things are quite difficult to source nowadays.
 
Thanks

 

[ano]

An update here from OP ..
 
So I ordered NextAlarm's new ABN4A device, had it shipped to me up here and Canada, plugged it in, everything registered and worked great. Then I went to register a monitoring account. The new system won't support Canada! What a pain! I've spent $100 in shipping and customs, their website clearly states "scores of satisfied customers across the United States and Canada..." (https://info.nextalarm.com/about-us/) it wasn't until I tried the autoregister form. Calls to sales and tech support and they told me "our new system doesn't support Canada at this time."
 
Apparently their older system that does VOIP monitoring DOES support Canada. So now I'm on the hunt for one of their older devices (the "Sparrow2" device). Anyone know where I can find one of these? These things are quite difficult to source nowadays.
 
Thanks

Have you tried here?  http://VoIPAlarm.com
 
I'm trying to figure out what the deal with all the versions is?  I have to old Linksys version and got an email recently saying that the firmware in it has been updated, so now it supports their "new" system. Then I get a different web page, but personally i liked the old web page version better.

 

[bdAZ]

Have you tried here?  http://VoIPAlarm.com
 
I'm trying to figure out what the deal with all the versions is?  I have to old Linksys version and got an email recently saying that the firmware in it has been updated, so now it supports their "new" system. Then I get a different web page, but personally i liked the old web page version better.

 
Yes, that's actually the same company as NextAlarm (according to NextAlarm). The website is littered with old information - I contacted the distributors and they informed me that VoipAlarm is listed as "out of business" on their site now.
 
I'm surprised there isn't more competition in this space given I'd imagine there are a number of households dropping land lines nowadays..

 

[drvnbysound]

Yes, that's actually the same company as NextAlarm (according to NextAlarm). The website is littered with old information - I contacted the distributors and they informed me that VoipAlarm is listed as "out of business" on their site now.
 
I'm surprised there isn't more competition in this space given I'd imagine there are a number of households dropping land lines nowadays..

 
The people I know who have dropped land lines either: A) Don't have monitoring or security systems at all or B) Are using internet or cellular based monitoring.
 
I don't know anyone personally who is currently using landline based monitoring.

 

[ano]

The people I know who have dropped land lines either: A) Don't have monitoring or security systems at all or B) Are using internet or cellular based monitoring.
 
I don't know anyone personally who is currently using landline based monitoring.

They are all the same thing. Alarms for the most part ALL communicate through a phone line using Contact ID. They use it because it is standard. There isn't an Internet alarm standard that all have agreed on.  Yes, correct, most people don't use analog phones lines anymore, but this analog signal still needs to get to the alarm monitoring station somehow, and there are really only limited ways to do that.  They can use cellular which does nothing more but turn the Contact ID audio into digital voice like any phone call, then the monitoring centers "hears" it in Contact ID form.  Many cellular phones are starting to use VoIP now for all cellular calls because its more efficient. (Look up VoLTE, for example.)
 
Outside of cellular, there is only two ways to get the Contact ID analog to the monitoring center. VoIP or proprietary IP.  I have NextAlarms older adapter and it uses VoIP, but its designed to send Contact ID tones.  You could also connect it to Vonage or Ooma VoIP that you use for voice, but that isn't recommended. Lastly a converter can convert analog Contact ID to a propriety IP signal the monitoring center uses.  The con of this is the converter box can only talk to a specific monitoring company. 
 
So really there are only three types of monitoring, analog POTS (disappearing), VoIP, or proprietary IP through a converter box.  The last two methods can travel over wireline Internet or cellular. 
 
Maybe some day the industry will agree on an Internet monitoring standard, but we are not here yet, and panels like the Omni will probably never support it anyway.

 

[Del91574]

They are all the same thing. Alarms for the most part ALL communicate through a phone line using Contact ID. They use it because it is standard. There isn't an Internet alarm standard that all have agreed on.  Yes, correct, most people don't use analog phones lines anymore, but this analog signal still needs to get to the alarm monitoring station somehow, and there are really only limited ways to do that.  They can use cellular which does nothing more but turn the Contact ID audio into digital voice like any phone call, then the monitoring centers "hears" it in Contact ID form.  Many cellular phones are starting to use VoIP now for all cellular calls because its more efficient. (Look up VoLTE, for example.)
 
Outside of cellular, there is only two ways to get the Contact ID analog to the monitoring center. VoIP or proprietary IP.  I have NextAlarms older adapter and it uses VoIP, but its designed to send Contact ID tones.  You could also connect it to Vonage or Ooma VoIP that you use for voice, but that isn't recommended. Lastly a converter can convert analog Contact ID to a propriety IP signal the monitoring center uses.  The con of this is the converter box can only talk to a specific monitoring company. 
 
So really there are only three types of monitoring, analog POTS (disappearing), VoIP, or proprietary IP through a converter box.  The last two methods can travel over wireline Internet or cellular. 
 
Maybe some day the industry will agree on an Internet monitoring standard, but we are not here yet, and panels like the Omni will probably never support it anyway.

Ano,
 
They are NOT the same. The issue is people are still purchasing LEGACY platform panels and then attempting to get them to communicate via methods they were never intended to or without the manufacturer's solution (usually purchased separately and with a different service) and then wanting to go to a CS that does not have the infrastructure to support the monitoring method appropriately. CID (or SIA) apply to the automation present at the CS. Almost every direct port IP solution into a CS is NOT CID, just data. The receiver portion passes the information to the automation, where it is translated from there and brought into the automation.
 
You're also only speaking about dialer capture based products. Almost every manufacturer has a direct to panel solution to get the data from the panel directly and to the CS via an IP port from the service provider. Dialer capture is really only on the products that don't have their own solution....or can't put the data out to a device that receives serial data. A great example of this is HAI....they have a product that has no support for TCP monitoring or a direct port into a compatible communicator, cellular or TCP.
 
As an example, almost every large and fully featured FACP out there does not have a dialer card onboard or it's an optional device, yet I can get a board that is TCP/IP, cell or POTS and connect to the panel directly and pass the data.....the issue with burglar panel manufacturers are they don't have a way to get the data out of their panels to a compatible dialer. It's the manufacturers not working on the legacy designs. There's at least a dozen certified dialers on the market that can take data straight into them and pass POTS or TCP/IP or cellular, so the issue comes down to the host panel, memory and the ability to get the data out of them to those dialers.
 
The TCP/IP monitoring standard has been decided and standardized. Has been for years. The issue is the smaller CS' don't want to purchase the necessary equipment or only work with what they are comfortable with, so that means that there's less choice for a CS or if the CS doesn't have an agreement with the service providers, they can't receive the data from them. That's the issue.
 
The truth is consumers are looking for a solution strictly at a specific pricepoint vs. performance. I can buy literally the same alarm panel with a cellular output or network connection, or both, but it costs more money than the same hobbled platform. So a line item of $250 for an open install vs. the legacy platform, which is the consumer going to choose without understanding.....and I would be able to ship signals to ANY CS that has adopted the supported standards, same as Elk, GE, Honeywell, or DSC on either POTS, TCP or cell. I could even get something like an Uplink 5200 and ship my signals to every CS out there...if they have an IP receiver or an analog.
 
There's far more ways to monitor an alarm panel than the 3 you mention. The issue is what hardware is needed to facilitate and what the CS can support. The majority AREN'T proprietary, the only part that is would be whether or not the CS can receive the signals from the vendor getting the signal there.
 
In the specific case of HAI, shame on them with their design and panel.

 

[pete_c]

@Del,
 
Knowing that telco's are eliminating copper and not providing resilience with fiber / cable (other than batteries which eventually are ignored) what is the most common standard that comes in to play with commercial CS monitor for fire and alarm.
 
I mean for years now you could always utilize a copper line during a disaster (no power and such) with no issues as as it always worked.
 
What happens now during a 5 or more day disaster when your VOIP or Cellular batteries only last 4 hours or 6 or whatever?
 
Is it up to the consumer to provide week or more long power supplies to make up for the mickey mouse replacement of the old legacy sure bet always up copper lines?

 

[Del91574]

Pete,
 
Commercial fire is an entirely different animal, but the AHJ's and NFPA have recognized that fact. NFPA 72 2010 allows for cellular as a sole path, however the performance is clearly stipulated and further tightened in NFPA 72 2013 with specifics regarding the performance based nature of the system and intervals between checks and stipulations on performance and requirements of the integrator upon failure or trouble detection. Whether or not the AHJ allows it is an entirely different fight, though companies like Telular have clear documentation to put in front of them to show the units are compliant.
 
This is why FACP's were originally required to have 2 phone lines to begin with....to allow the reporting of the trouble line on the backup or vice versa. Before that, it was via leased lines, municipal ties (still exist here) or Mccullough loops (as a kid growing up, the local FD used to blast horn signals from what I now know as a Mccullough loop system, they published a list of all the coded signals and my grandparents had one hanging in their cabinet)
 
There is no silver bullet, however in the case of a major disaster, there's only so much you can do, end to end. This is part of the issue that the FCC was looking at that Ano mentioned. Transitioning from a utility based model to a technology and data based model....somewhere something is going to have to be looked at.
 
The smartest course of action for an integrator would be to get a device that has 2 paths, like Honeywell's unit (TCP/IP and cell) and go with the performance based monitoring model, which unfortunately also puts the larger burden on the integrator (runner requirement) which will get passed back to the end user (PSA contract or billable call) which will inevitably negate the cost savings of the alternate path to the CS other than the PSTN (or actually cost more in the case of trouble signals).
 
The largest issue I see is there's no standardization or requirement for the end user to use listed components or supply an adequate UPS on their network gear. How many DIY or integrators are actually pushing the issue and ensuring the UPS meets the same standards as the alarm panel? 
 
Not until something exceptionally bad happens will it be addressed, and still, how many people will really see the issue other than "X works" for me, which is the issue of installing VOIP adapters on alarm panels, NA's digium boxes (never UL listed, nor were their services) and the complaint of when the next firmware sent through by the ISP stops a reliable communications route or even kills it altogether (has historically happened over the years, though improved) which is why the dialer test on the panel is so important and mandated on fire installations (30 days) though plenty of DIY and pros don't actually program this.....willful negligence. Some CS even bill service based on the amount of signals sent to them, so the integrator or DIY cut the signals altogether or move to limit what the panel can send and how often.
 
My view is just because you can do something or make it work via X or Y means, doesn't mean it's a good idea, no matter how well you've thought everything through. There's a reason why I stress UL listed communications, routing and hardware. Plugging your legacy panel into a magic box, then to your Linksys (now Cisco) router and Motorola surfboard into your UPS you bought at Staples via your premium plus cable package through whoever doesn't mean it won't work, but there's no checks and balances end to end for the performance of the system as a whole and notification of such. The end user can move to a more robust solution with business grade hardware, until the ISP portion has been addressed and considered. How many times does an end user have to reboot their modem or network gear vs. a business application to get items to work again?
 
I believe that until security panels come out that have built in NICs or cell connections (which is silly on most panels because that locks you into locating your panel in an area you can get cell service or pull a heavy cable to remote an antenna) the problem isn't going to be fixed. Same on the consumer market....I can't compete with a mass market panel install and the related markups to get a panel whose only difference is a NIC or native IP capability (say a V20P vs. V21IP, DMP or whoever else). The consumer only sees the line item. The other issue that's going to come up is how to get the panel connected to the net securely, especially when you're looking at a wireless bridge. That's the next biggest hurdle.