Alarming Facts about VoIP

One of the best ways to grab attention is to use a play on words, and I couldn’t resist a golden opportunity. Alarm systems and voice over Internet protocol (VoIP, aka cable digital telephony) may not always mix, and this column will look at what cable telecom providers and alarm companies need to watch to ensure compatibility. A good place to begin is the interface between residential security systems and plain old telephone service (POTS) telephone lines. In my case, when the phone rings, Snoopy barks, but that’s an increasingly smaller subsegment of security systems. Today’s electronic watchdogs usually are designed to seize a phone line automatically, dial out, and send status information to a centralized alarm monitoring point, either on a regular basis or when some form of intrusion occurs. Problems Four problems needed to be solved to make this happen. First, it is necessary to attach the alarm system to the phone line transparently so that it does not interfere with a phone call when there is no alarm. Second, the interface to the alarm system needs to be such that a telco installer is not required to be present when the alarm system is attached. Third, it is imperative that a live telephone call be terminated when an alarm condition occurs, to allow the alarm system to be able to dial out immediately to the centralized alarm location. Finally, the alarm system must communicate with the centralized alarm location via an efficient signaling method that is compatible with POTS. The solution to the first two problems is the RJ31X jack. In case you haven’t seen one of these, it’s a three-port modular jack, with one port consisting of screw or punchdown connections to the telephone company network interface device (NID), another port with screw or punchdown connections to the house side of the residential wiring, and a third port consisting of an eight-pin modular connector that accepts a plug connected to the alarm system leads. The eight-pin jack is built with internal shorting bars, such that when nothing is plugged in, the leads on the two other ports are connected to each other. When a plug from an alarm system is inserted, it opens the shorted connections and creates an alternate path that interconnects each lead through the alarm system. When there is no alarm condition, the alarm system is thus transparent to the phone system. However, when an alarm occurs, the alarm system disconnects the house wire side from the network side and "listens" for dial tone. If no one is off-hook at the time, this is the same as a phone going off-hook, allowing the alarm system to sense dial tone and then dial out to the centralized alarm location. On the other hand, if there is a call in progress, this action disconnects the existing call and allows the alarm system to seize the outgoing telephone line and dial out. Third problem solved. Once a connection is made to the centralized alarm location, communication is established using one of several possible protocols. All are unique to the alarm industry, with Contact ID and SIA being the most common. In general, the protocols use tones to convey digital information, very similar to the way a fax machine works. There is an initial handshake exchange that verifies the connection, a data transmittal interval that provides the details of the specific alarm, and a "kissoff" tone that signifies the end of the transmission. The differences between the formats are the tone frequencies, tone intervals and the coding used to indicate the specific alarm. The tones are in the voice frequency range and are therefore compatible with POTS. The tough nut Now let’s see what can happen when we change over to VoIP. Most cable VoIP systems provide the interface to the operator’s coax via an indoor multimedia terminal adapter (MTA). Common installation practice is known as "backfeeding," which includes disconnecting the existing NID and plugging the MTA into an existing RJ11 wall jack. Since all the RJ11 jacks are interconnected, this allows the MTA to replace the NID effectively as the interface to the service provider’s network. For an alarmed house, however, the problem is that the RJ31X jack is no longer in the path to the service provider’s network and doesn’t even have a network side connection once the NID is disconnected. It is possible to avoid this problem by connecting the MTA to the network side of the RJ31X jack, but this is not as simple as plugging the MTA into any RJ11 jack. Instead, either a spare pair must be used as the path back to the RJ31X (with appropriate modification of the connector back to the MTA), or a separate, new telephone pair must be installed from the MTA back to the network side of the RJ31X jack. Obviously, phone service will be available from all RJ11 jacks except the one used to provide the path to the RJ31X. However, even with this wiring change, the alarm system may not function properly. Depending on the MTA codec, the tones used to communicate with the central alarm system may not survive the analog-to-digital conversion process, especially if compression and/or vocoding are involved. Possible solutions The good news is that the alarm industry is aware of these issues and is working with cable operators to solve them. On March 3, leading alarm panel manufacturers, alarm companies, and the National Burglar and Fire Alarm Association met with several MSOs at CableLabs to discuss recommendations for interfacing alarm systems to VoIP. As a result, the NBFAA published an Industry Affairs Update report for distribution to its membership, which summarized these issues and others and made recommendations for the future. In addition to backfeeding and signal format, the report points out reliability issues, such as possible inconsistencies in the amount of battery backup time required by an operator and that required by UL-NFPA standards, and the possibility that an MTA could provide dial tone even if a network connection to the central alarm site was not available. It concedes, however, that VoIP is here to stay not only as cable’s telephony standard, but also as a transmission protocol for segments of the public switched telephone network (PSTN). Accordingly, it concludes that there will be many different implementations of VoIP that could adversely affect alarm transmission. In that light, it recommends a commitment to inform alarm subscribers of the issues with VoIP, to revise programming of systems to include periodic test messages to determine connectivity, to monitor error message patterns that might indicate a VoIP-related problem, and most important, to shift to IP technology for alarm messages. Maintaining ongoing dialog and information exchange between the cable telecommunications and alarm industries are obvious keys to meeting future security needs of mutual cable and alarm subscribers. Along those lines, I recommend checking out the NBFAA’s www.alarm.org site on a regular basis. Also, for those interested in the details of the various alarm signaling formats, some good references are available in vendor bulletins and installation manuals, such as those found at www.centralone.com/bulletins/BULL1031.TXT and www.alarmeengros.com/installation15P.pdf. Justin J. Junkus is president of KnowledgeLink and telephony editor for Communications Technology. Reach him at [email protected].