Typically, from the time an alarm panel is activated, it takes between 10 and 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 what happened to the speed advantage IP is supposed to offer?
Well, using the above as an example, it has been wasted waiting for the panel to go off hook, the telephone line to settle and the telephone number to be dialed – even though it never gets used. Programming a short or empty telephone number is one way to improve this situation but 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 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, but the price tag of such systems remains well out of the reach of the vast majority of 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 centre. Using motion detection also means there would have to be some way of arming and disarming the cameras so that they did not send images of people 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 triggering 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 centre 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 – providing 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 centre as they are not reliant on a specific server application.
In preparation for viewing and recording images from the protected premises, the monitoring centre database stores various camera-related parameters alongside well-known alarm parameters like 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 centre maintains a database of custom commands, which can be built up over time to support any brand of camera used by its 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 10 seconds of footage prior to the alarm and 20 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 centre.
His account number at the monitoring centre is 1234 and he has requested that, in the event of an alarm, 10 snapshot images be recorded at two second intervals. This information should be entered into the database at the monitoring centre 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, 10 times, to Mr. Smith’s camera at two second interval:
http://mrsmith.dyndns.org:800/CamImage.jpg?UserName=abc&PassWord=xyz
The end result is that 10 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 (ISP) 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 updating the DNS database to reflect the change. In this way, even though a domain name’s IP address will often change, 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 set up 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 centre 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 centre
Much to the dismay of alarm installers and monitoring centres alike, the luxury of “any panel, any receiver and any monitoring centre” 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 distributor’s, 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 centre that have installed their brand of IP receiver.
Whilst this may be a little inconvenient for the installer, spare a thought for monitoring centres which are faced with purchasing IP receivers from each and every one of the manufacturers for fear of losing their subscribers to competitors.
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, and any monitoring centre”.
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 centre’s investment in existing equipment.
Steve Nutt is UK director of IP Alarms.
