Remote Programming of Alarm Panels over IP

Our Cloud based Alarm Signaling Solutions support panel initiated, CallBack and Alarm Company initiated Upload/Download (UDL) calls over IP. All devices provisioned for use with our platform automatically include the ability to go into UDL Mode to allow remote programming of alarm panels (or other control equipment). This is a very important feature that has been overlooked by the majority of our competitors.

The Goal of Universal Upload/Download (UDL)

Alarm Companies worldwide have existing systems in place for remotely programming their alarm panels via upload/download software and modems over analog landline phone networks. Millions of Customer phone numbers are entered into UDL software databases and Alarm Company phone numbers are programmed into millions of alarm panels. The goal of IP Alarms was to migrate these systems from analog to IP without a requirement for Alarm Companies to make any hardware or software changes either at their offices or at the Customer premises. The solution had to allow an upload download session over IP from any make and model of alarm panel currently in use with its compatible UDL software and modem.

In order to accomplish this task, a method of mapping analog telephone numbers to digital IP phone numbers needed to be put in place. This was done by the use of something called a Uniform Resource Identifier (URI). It is a compact string of characters for uniquely identifying a physical resource. In our case, that physical resource is a Cisco VoIP adapter installed on a network at an Alarm Company office or at a Customers home or business premises.

RFC Reference: http://www.ietf.org/rfc/rfc2396.txt

Such a mapping allows an alarm panel to dial its existing UDL phone number and be connected to the Alarm Company over the Internet. It would also allow the UDL software and modem at the Alarm Company to dial an existing phone number entry, yet be connected to the Customer alarm panel via the Internet rather than over a POTS line. Obviously this has to be done without the use of a 3rd party VoIP provider network which would not work for reasons well documented, so where exactly does this mapping take place ?

The answer is that it takes place within a software component called a Virtual Receiver which runs on multiple servers within our AlarmCloud Platform. The primary job of each Virtual Receiver is to receive alarm signals from remote alarm panels utilizing regular 'off the shelf' Cisco/Linksys VoIP adapters for transmission over IP. An additional feature of the Virtual Receiver allows it to distinguish between alarm calls and UDL calls. When a UDL call is detected, the phone number to URI mapping is used to redirect the call to the correct recipient (panel).

Typical Upload/Download Scenario

To provide an overview of UDL support within the Cisco/Linksys Solution, we will use an example Alarm Company with two Customers. Customer 'A' allows the Alarm Company to dial in to program the panel but Customer 'B' only allows UDL to be initiated from the alarm panel end. It is presumed that both Customers have an IP Alarms provisioned Cisco device connected to their alarm panel and the Alarm Company have a Cisco SPA3102 provisioned for UDL.

Let's say that the Alarm Company have a phone entry of 1234567 in their UDL software for Customer A. The UDL Modem will be connected into the PHONE port of a Cisco SPA3102 rather than into a telephone wall socket. When the UDL modem goes off hook and dials 1234567, the call will automatically be sent over IP to the Virtual Receiver in the AlarmCloud platform - just as it would for all other phone numbers that are dialed for other Customers. The Virtual Receiver detects the call and searches for the 1234567 phone number in the analog to URI mapping table. If a mapping is found, the call is redirected to the URI of the Customers Cisco/Linksys device, the alarm panel will answer the call and a remote programming session can take place over IP without incurring any call costs.

So how does the Virtual Receiver keep track of client URI's if they do not have fixed IP addresses or dynamic domain names? Well, each client Cisco/Linksys device sends a heartbeat packet to the Virtual Receiver every 50 seconds. Most routers keep a 'pinhole' open for 1 minute, so this allows the AlarmCloud platform to contact client devices at any time. The Virtual Receiver stores the IP address and port number detected from the incoming packet in the mapping table and uses it as part of the URI. If the Customers IP address changes, the new IP address will be detected from the next heartbeat packet and the mapping will be updated accordingly.

Moving on to Customer 'B' who will only allow panel initiated calls. Let's say their panel is programmed with a UDL phone number of 4445555. This phone number has to be entered into the Linksys device during the provisioning process so that the Cisco/Linksys can recognise it as a UDL call. When the panel goes off hook and dials 4445555, the call will automatically be sent over IP to the Virtual Receiver. The Virtual Receiver detects the call and searches for the 4445555 UDL phone number in the Alarm Company table. If the number is found, the call is redirected to the URI of the Cisco SPA3102 device at the Alarm Company and the UDL software will answer the call. This process is fully transparent to both the calling and called adapters and the AlarmCloud Virtual Receiver does not take part in any of the calls once they are connected.

In both examples, calls will be logged by the Virtual Receiver for audit purposes.

Technical Requirements for Alarm Company Initiated Calls

If an Alarm Company requires the ability to initiate remote programming from their office, there is a requirement to port forward a range of ports in the Alarm Company router. This is usually simple process for most Alarm Companies and IP Alarms provide complete documentation and support. There is usually no requirement for port forwarding in the client router.

The usual technical challenges apply when trying to achieve a connection with a Client device and difficulty may be experienced with a small number of client routers. Where the client Cisco/Linksys device is behind a symmetric NAT router (approx 2% of cases) or where a firewall with SPI (stateful packet inspection) is getting in the way, the only solution is to port forward ports in the Client router.

Technical Requirements for CallBack and Alarm Panel Initiated Calls

There is a requirement to fix a static local IP address into the IP Alarms custom provisioned Cisco device and to port forwarding a range of ports in the client router. The Upload/Download telephone number in the Cisco/Linksys device defaults as 9997, but any phone number can be used as long as it is entered into the Downloader section of the AlarmCloud web platform. There is no requirement to forward ports if the alarm panel does not need to make outgoing calls.