White Paper on IP Signaling Alarms – Part 2

IP Alarms

Submission by Steve Nut, IP Alarms LtdPART 1 Can Be Read HERE

Alarm Installers Guide to IP Signaling – Part 2

We often hear that one of the great advantages of IP over PSTN is the increased speed of alarm signal transmission. Whilst this is partly true, alarm installers need to understand the different stages of an alarm signal transaction in order to take full advantage of this available speed.

Typically, from the time an alarm panel is activated, it takes approximately 10-15 seconds to dial the telephone number and send a DTMF or FSK signal over a PSTN line. When an IP dialer capture device is used, it listens for the telephone digits, ignores them, plays a handshake, takes the signal, plays a kiss-off and then transmits the signal over IP. Even though the actual transmission over IP might take only a couple of hundred milliseconds, the whole process takes approximately the same time as it does over PSTN. So where is the speed advantage in using IP ?

Well, using the above as an example, it has been wasted waiting for the panel to go off hook, waiting for the telephone line to settle and waiting for the telephone number to be dialed – even though it never gets used. Programming a short or empty telephone number is one way to improve on this situation, however, installers should also take advantage of any programmable outputs or relays on the panel where available.

Some IP devices have digital inputs that can be connected to alarm panel outputs (I/O). These panel outputs change state immediately upon activation of an alarm and in turn trigger the IP device inputs so that a signal is sent to the server without delay. Until such time that new alarm protocols are developed to take full advantage of IP and built directly into panels, using digital I/O offers the best solution for the retrofit market on systems where speed of transmission is important.

One area where the speed of transmission is critical is where alarm signaling is used to trigger the recording of images from IP cameras.

Using IP Signaling to integrate IP Cameras with Alarm Systems

Sophisticated CCTV cameras and transmission equipment were in use long before many of us had even heard of the Internet. Manufacturers were quick to update their products to take full advantage of IP, however, the price tag of such systems remains well out of the reach of the vast majority of both residential and small commercial Customers. So how can the alarm industry provide video verification services to this group of Customers at a more realistic cost?

The answer lies in the use of IP cameras. For alarm installers, their arrival is akin to the introduction of PIR detectors more than two decades ago and it won’t be long before it becomes routine to fit one in each protected area as one might do now with a PIR.

So what are our options for integrating IP cameras so that they become an integral part of a security alarm system?

Most cameras come with some form of built-in motion detection, however, the unpredictability of this technology prevents it from being used to trigger an alarm panel into calling a Monitoring Center. Using motion detection would also require that there be some way to arm and disarm the cameras so that they do not send images when people are legitimately moving around the protected premises. Due to the familiarity and simplicity of arming and disarming an alarm panel, one option is to have the panel trigger cameras only when it is armed. This way, images are only sent to the server in the event of an alarm activation.

This can be done by connecting a cable from the panel to the trigger input of the camera if it has one. The preferred method however, is to trigger and control the camera via software commands from the Monitoring Center server. The more expensive IP cameras provide a full range of software commands that allow control of pan, tilt, zoom, pre and post alarm triggering and other common features. Whilst lower cost cameras do not generally offer these features, the majority of them do support jpeg snapshots at various resolutions which provides the industry with a starting point for mainstream video verification.

Overview of Vendor Neutral Video Verification

The snapshot feature allows an installer to fit a camera from manufacturer X alongside one from manufacturer Y and Z. This provides great flexibility for the installer as they are not tied to a specific camera manufacturer. It is also ideal for the Monitoring Center as they are not reliant on a specific server application.

In preparation for viewing and recording images from the protected premises, the Monitoring Center database stores various camera related parameters alongside well known alarm parameters such as event definitions and zone lists.

Basic camera parameters determine what type of alarm events and which zone numbers should trigger the recording of individual cameras. They also specify the total number of images to be recorded and the time interval between them.

Each IP camera requires a slightly different software command to trigger it, so the Monitoring Center maintains a database of custom commands which they can build up over time to support any brand of camera used by their installers.

Every second counts in the triggering and recording of images from IP cameras. Remembering how long it takes to send an alarm signal using traditional protocols, starting a recording 10-15 seconds after an alarm event would almost certainly mean losing some of the most important footage.

There are different ways to overcome this depending on the available features of the alarm panel, the IP alarm device and the camera. A high spec camera would use a “pre-alarm” feature where it might send the server ten seconds of footage prior to the alarm and twenty seconds after it. Lower spec cameras would provide a snapshot command facility which can be triggered by the use of panel outputs and IP device inputs as already described.

The Snapshot Command in Action

As an example, we will say that Mr. Smith has an alarm system, an IP alarm transmitter and an IP camera installed at his home. The transmitter and camera are plugged into his router and connected via the internet to an IP enabled Monitoring Center.

His account number at the Monitoring Center is 1234 and he has requested that 10 snapshot images be recorded at 2 second intervals in the event of an alarm. This information should be entered into the database at the Monitoring Center and checked every time an alarm signal is received. Here are the database fields and data that might be used for Mr. Smith:

Account Number: 1234

Number of Snapshots: 10

Snapshot Interval: 2

Zones That Trigger: 2,3,4

Camera IP and Port: http://mrsmith.dyndns.org:800

Snapshot Command: /CamImage.jpg?UserName=abc&PassWord=xyz

When an alarm signal from account code 1234 is received, the server software checks the database to find that Mr. Smith has a camera and that images should be recorded on the server if the alarm was from zones 2,3 or 4 (zones 5,6,7 and 8 might be used to trigger a second camera). The software concatenates the IP address of the camera and the snapshot command together so that the following command is sent in a loop, ten times, to Mr. Smith’s camera at two second intervals…


The end result is that ten jpeg images are written onto the hard drive of the monitoring server and optionally displayed to an operator for further analysis.

Now let’s break down the snapshot command and consider the prerequisites of Mr. Smith’s network and camera setup in order for it to work correctly.

Firstly, you will notice that http://mrsmith.dyndns.org is used instead of an IP address. This tells us that Mr. Smith does not have a fixed IP address allocated to him by his internet service provider and that he has registered something called a dynamic domain name. Put simply, this is a method of keeping a domain name linked to a changing IP address. Typically, when a user connects to the Internet, the user’s ISP assigns an unused IP address from a pool of IP addresses, and this address is used only for the duration of that specific connection. A dynamic DNS service provider uses a special program that runs on the user’s computer (some IP cameras also support this), contacting the DNS service each time the IP address provided by the ISP changes and subsequently updating the DNS database to reflect the change. In this way, even though a domain name’s IP address will change often, we do not have to know the changed IP address in order to connect with Mr. Smith’s camera.

The :800 in the command lets us know that Mr. Smith’s router has been setup with port forwarding and that port 800 points to his camera. There is an IP alarm device that can overcome the requirement for port forwarding in order to trigger cameras, but generally speaking there is no way to get to Mr. Smith’s camera without port forwarding.

Each camera manufacturer has their own set of software commands for controlling cameras and the /CamImage.jpg? part of our example snapshot command is just one such variation.

Most snapshot commands contain a question mark and this tells the camera that a number of parameters will follow. These are normally used to set the resolution and compression of the image and to provide security credentials.

In summary, with the help of specialist software on the server at the Monitoring Center and an IP alarm adapter at the protected premises, low cost IP cameras can be easily integrated with alarm systems to provide basic video verification.

“Any Panel, Any Receiver, Any Monitoring Center”

Much to the dismay of Alarm installers and Monitoring Centers alike, the luxury of “any Panel, any Receiver and any Monitoring Center” has been taken away by the manufacturers of IP alarm adapters and receivers. For many years, installers have been able to pick their favorite panel or communicator off the shelf at the distributors, install and program it with a choice of protocols, connect it into a telephone line and have it monitored by any number of accommodating Monitoring Companies. Things are not nearly as flexible in the move to IP.

Each IP receiver manufacturer has designed their server equipment in such a way that it will only accept signals from their particular brand of panel or IP adapter at the client end. So, if you want to upgrade an alarm system using an IP adapter from a particular manufacturer, you will have to use the services of a Monitoring Center that have installed their brand of IP receiver.

Whilst this may be a little inconvenient for the installer, spare a thought for Monitoring Centers who are faced with purchasing IP receivers from each and every one of the manufacturers for fear of losing their subscribers to competing Monitoring Centers.

As well as doing their best to ensure that their panels only get connected to their own brand of IP receiver, many manufacturers also offer a “universal” device that will allow any brand of panel to communicate with their receiver. Unfortunately, these devices are only “universal” at the client end as they are still locked to a particular brand of IP receiver.

There is a definite requirement for the development of a truly universal IP alarm protocol so that the industry can return to the much fairer system of any panel, any receiver, any Monitoring Center.

In the meantime, there are a small number of universal IP devices on the market that will communicate with any analogue alarm receiver over IP to protect the Monitoring Center’s investment in existing equipment.

IP Alarms Ltd

Be the first to comment on "White Paper on IP Signaling Alarms – Part 2"

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.