Submission by Steve Nut, IP Alarms Ltd – PART 2 Can Be Read HERE
Alarm Installers Guide to IP Signaling – Part 1
An Overview of Alarm Signaling over PSTN(POTS)
Many installers will already know the intricacies of how an alarm panel, digital communicator or digital dialer communicates with an alarm receiver at a Monitoring Centre. However, there are likely many more that do not know – so here goes.
Without focusing on a specific alarm protocol, here is what should happen when most popular DTMF protocols are used.
When an alarm event occurs, the panel will go off hook and “grab” the phone line. The panel will dial the DTMF digits of the pre programmed primary telephone number and wait until the alarm receiver answers the call. Upon answering the call, the receiver will play what is known as a handshake. This would normally be either a single high pitched tone or two very rapid, short, high pitched tones.
When the panel hears the handshake, it will start to send its first message as a series of DTMF tones. These tones are detected by the alarm receiver and checked at the end of each sequence. If the message is valid, the receiver will play what is known as a kiss-off tone. This is usually a single high pitched tone of up to one second in length.
On hearing the kiss-off tone, the panel either sends the next signal in the queue, or it hangs up – happy in the knowledge that its message has been sent and accepted.
Enter Global Voice over IP and 21CN in the UK
After decades of signaling alarms over PSTN, the major Telco’s recently started to tell us that VoIP will increasingly replace circuit switched communications as the preferred method of communication. Rollout of British Telecom’s 21CN has proved this to be the case in the UK and there are many similar projects underway throughout the world. The days of the Plain Old Telephone System (POTS) seem to be numbered.
Back in the late nineties, VoIP started to gain popularity in many countries and by the year 2000 accounted for over 3% of all voice traffic in the USA. Due to the increased availability of broadband and FTTH (Fiber) services, VoIP has experienced phenomenal growth since then and it is forecasted that consumer VoIP will reach more than 37 million subscribers in the US by 2011. Many in the security industry thought that the analogue terminal adapters (ATA’s) used by the VoIP world would provide a quick, low cost method of signaling alarms over the internet. After all, if two people could talk over the internet using ATA’s in the same way as they talk over a traditional phone line, then surely an alarm panel should be able to talk to an alarm receiver in much the same way as it has always done.
Unfortunately, even after a certain amount of success in some tests, this has proved not to be the case. Somewhere between converting analogue into digital, traveling over the wire and converting digital back to analogue, things like noise and latency are introduced and along with other audio problems associated with VoIP networks, can cause alarm communications to fail. There is however an alternative method of using ATA’s to bypass these problems and we will come back to this in Part 2.
The Challenge for Security Equipment Manufacturers
Due to the sheer volume of monitored alarms that are in service worldwide over PSTN as described, and coupled with the reluctance of end users to change their alarm control panels, manufacturers and developers of IP equipment and software are faced with the unenviable task of providing us with devices and services that maintain compatibility with existing panels, yet communicate over an entirely different network – the internet.
Dialer Capture and I/O Devices
There are many commercial devices available today that can either capture the DTMF tones sent out by alarm panels or provide inputs that detect changes from alarm panel outputs. Some devices also support FSK (SIA) and pulse protocols. The resulting signals can be reliably and securely transmitted to a Monitoring Centre over the internet.
So, what does an alarm installer need to know in order to confidently install such a device?
Connecting the device to a Modem/Router
Some installers may think that a modem is the same as a router, and often they do come together in the same casing as a combined Modem/Router. Although it is not essential to have an in-depth knowledge of either device, it is important to know that they are indeed different.
A modem is responsible for negotiating and maintaining a connection to the internet via the service provider network. This would normally be DSL or cable, and as far as the IP device is concerned, there is no difference between the two types of network.
To overcome the problem of the limited number of public IP addresses that are available, versus the massive number of network devices being produced, each requiring it’s own IP address, a router uses a technology known as network address translation (NAT) so that it can have one public IP address and allocate many internal IP addresses to computers or other devices on the internal network.
NAT routers come with the additional benefit of providing computer users with protection from malicious activity from outside the network, however, for the purposes of alarm signaling this very same feature prevents our IP devices from having true end-to-end connectivity. The initiation of connections from outside the network, or the use of certain internet protocols such as UDP, can be disrupted.
Getting back to basics, and in summary, a modem connects one network device or computer to the internet. A router connects a modem to several computers or network devices and allows them all to share one internet connection.
If your customer has a separate modem and router, you will connect into a free port on the router. If they have a combined unit, then it will normally have four or more ports that you can connect into.
What about Firewalls?
Some residential class modem/routers will also have a built-in firewall and some larger commercial systems will have a separate hardware firewall – possibly complete with a protective network administrator who will decide who does, and does not get to connect to “his” firewall. Basically, a firewall has the job of following a set of rules and closely inspecting packets that travel through the network. In a residential environment, these rules are generally not too restrictive, however, in a commercial environment where the network administrator has done his job correctly and your IP device uses the UDP protocol, responses from the server may be blocked.
On routers with built-in firewalls, watch out for SPI – Stateful Packet Inspection. Disabling it will solve the problem for your IP device, but will decrease the security level for other computers and devices on the network.
Potential Connection Issues
When you connect a panel up to a Monitoring Centre via PSTN – do you make it company policy to insist the customer orders a block terminal from the Telco, or do you wait until you get on site, dig into the telephone system to figure it out and then wire into it yourself?
Your answer to the above question will probably determine your expectations and the demands placed on the customer regarding their network equipment. If you do not impose any compatibility requirements, then there will certainly be occasions where you arrive on site only to find that there is no available port for you to connect your IP device into. In some countries, internet service providers ship a USB modem that allows a single computer to connect to the internet. This type of modem does not have anywhere for you to connect your IP device, leaving you with no alternative but to ask your customer to upgrade their network equipment.
If your customer does have a suitable device, and even if there is a spare port, the router or firewall may have been configured in such a way that it is not possible for your device to function correctly.
DHCP. An Installer’s Best Friend.
As previously mentioned, every device on a network requires an IP address in order for it to function correctly. So just where do you get this IP address from?
Luckily for Alarm Installers, the vast majority of networks will contain a device acting as a DHCP server. This DHCP server will dynamically allocate an IP address to your IP device when you plug it into a spare port. Most routers and server computers can be configured as DHCP servers.
Sometimes you may come across networks that do not use DHCP. In this case, you will have to ask the network administrator to manually allocate an IP address for your device. When you use a fixed or static IP address in this way, you will also have to enter a Gateway and Subnet Mask – again provided by the administrator. If there is no administrator, or if you are in a residential environment, then you will either have to find the person that setup the router or figure it out for yourself.
User Interface
Your IP device will most likely come with a web browser interface that allows you to enter configuration settings such as network settings, alarm protocols and the like. Others may come with a Windows interface and a null modem cable connection between a computer and the device, or an interactive voice recognition menu that allows programming via a telephone handset.
If the device has a web browser interface, you will normally have an option to allow access to the built-in web server on the device from outside of the network. This is where your company has to make a very important decision on the subject of routers and port forwarding.
Company Policy on Routers and Port Forwarding
Let’s just say that the public IP address of the customer router is 60.61.62.63 and the customer has 3 computers, plus your IP device on the internal network. If someone were to type the public IP address into a browser on a computer at your office, then without any port forwarding in place, the request would hit the customer’s router and promptly be rejected. This is because the router has no way of knowing if your office computer wants to communicate with one of the 3 computers, or with the IP device.
So, how can someone at your office connect to the built-in web server on your IP device in order to program it remotely?
The way to allow external access to the IP device is to use port forwarding. Let’s say that the internal IP address of your IP device is 192.168.0.5 and it has defaulted to port 80. Change the port number on the IP device to say 8080, log into the router and port forward port 8080 to 192.168.0.5
Basically, what you are telling the router to do here is to send any external traffic it receives on port 8080 over to your IP device. So back at the office, if someone were to type 60.61.62.63:8080 into the URL bar of a browser, they should now see the default web page of the IP device. Now that wasn’t too difficult was it? – So, what was that important decision that you had to make?
Well, what you have just done is to allow uninvited traffic from absolutely anyone outside of the network to pass straight through the customer’s router and onto the inside of the network. Remember your best friend DHCP? Well this is where it might turn around and bite you, as the next time the customer power cycles the router, DHCP could re-allocate all internal devices with different IP addresses and the port forwarding that you put in place might now point directly into one of the customer’s computers and all of its files. Guess who is going to get blamed if the customer gets hacked or hit with a virus?
If you are new to IP and networking, then think very carefully about your company policy on port forwarding and whether or not you should adjust any settings in the Customer’s router. You should also consider situations where DHCP is not available by default.
If you are network savvy, then correctly setting up an IP device with a fixed IP, adjusting port forwarding and firewall settings will be just as easy as programming your favorite alarm control panel.
More on Routers and Port Forwarding
Unfortunately for installers new to IP, the requirement for port forwarding may not always end being as simple as allowing remote access to the web interface of your chosen IP device. The vast majority of manufacturers use UDP as their transport protocol of choice for both polling and alarm signals. As mentioned earlier, NAT routers can make life quite difficult for UDP and, although there are no issues with sending out packets, without the help of port forwarding it is not always possible to get responses back through to the IP device.
You might be thinking “well that’s OK – as long as the signal reaches the Monitoring Centre”. The problem with that is the panel is expecting a kiss-off from the receiver. If it doesn’t receive a kiss-off, it will keep retrying the first signal in its buffer until it finally gives up. As well as receiving duplicates of the first signal, the Monitoring Centre will never receive the second or any subsequent signals that may be stored in the panel’s buffer and this is clearly unacceptable.
Most manufacturers of devices that use UDP suggest using port forwarding to overcome this issue. If you decide to adopt a policy of port forwarding, you will need a sound knowledge of networking and some disclaimers in place to cover you in the event of a security breach.
Multiple Routers
In apartments, complexes and buildings where there is a communal router providing internet access to multiple dwellings, it is quite common for a tenant to have a secondary router to allow the connection of more than one computer or network device of their own. This makes it very difficult for IP devices using UDP, as now the response packets have to negotiate two NAT routers instead of one. It is unlikely that an installer will be allowed to make changes to the communal router in an attempt to resolve the issue with port forwarding.
Your only alternative here is to use an IP device that communicates via the TCP or HTTP protocols. Without getting too technical for now, both TCP and HTTP are connection based. They can easily navigate their way through two or more routers, make a connection to the server, send their data, receive a response, disconnect and then kiss-off the panel based on the response.
Polling and Heartbeats
One of the benefits of IP Signaling is line supervision. This is possible through the use of polling or heartbeats. Polling is initiated from the Monitoring Centre server where every remote device is sent a message to which it should respond. The alternative method is for each remote device to send a heartbeat message to the server at an agreed interval. Either way, the Monitoring Centre is able to detect when a device is not responding and an alert is raised accordingly.
As heartbeats are initiated from inside the Customer network, there is no need for port forwarding. If your chosen IP device uses server based polling then you should find out from the manufacturer if there is a requirement for opening ports as this will affect your company policy on Routers.
Remote Kiss-off versus Store and Forward
Where an IP device emulates the communication of an alarm signal over PSTN and it relies on a response from the server before sending a kiss-off to the alarm panel, it is said to be using a method known as Remote Kiss-off. In order to do this successfully, the IP device needs to transmit the signal to the Monitoring Centre server, receive a response and generate a kiss-off tone, all within 1.25 seconds. This may not sound like much time, but a normal round trip over IP only takes between 100 and 500 milliseconds. This time can be faster or slower depending on network conditions and some devices have algorithms in place to compensate for slow network speeds.
Some IP devices prefer to take signals from the alarm panel and kiss them off immediately at the end of each signal before attempting to forward the signals on to the Monitoring Centre server. They store all the signals in a buffer on the IP device and later forward them on to the Monitoring Centre – hence the term Store and Forward. In effect, the IP device takes on the responsibility of making sure that the signals get through to their final destination.
Both methodologies work well, however, there have been arguments for and against both, so if you think you may prefer one method over the other, you should seek further information from the manufacturer.
How to avoid problems with NAT, Port Forwarding and Firewalls
In simple terms, if you are confident about your networking abilities and the Customer equipment allows, then you should be able to use any IP device. If you are new to networking, or do not want the headache or risk of dealing with NAT routers, then you should consider using an IP device that communicates via HTTP.
Unfortunately for some, this decision will be out of their control as somewhere in the dark corridors of time, the US security industry powers that be, decided that UDP should be the approved transport protocol for signaling alarms over IP. This article has already pointed out several reasons why this decision may have been made in haste and could affect the future of IP signaling in North America. Alarm installers who have to use UDP devices will learn to work around the associated problems. The aim of part 1 of this article was to bring these problems to your attention early on so that you have an opportunity to prepare in advance.
In part 2, we will move on to upload/download, two-way voice and seamless integration of alarm systems with IP cameras to provide video verification and off-site recording.
Be the first to comment on "White Paper on IP Signaling Alarms"