In the Fire Alarm and Security industry, when a system goes into alarm or trouble, an event message has been traditionally sent to a monitoring station through a communicator attached to a Plain Old Telephone Service (POTS) line. Utilizing different frequencies and precise timings, communicators transmit information utilizing different protocols.
The most widely used protocol has been Ademco ContactID (CID). There are others, such as SIA, 3+1, and 4+2, but the focus of this article will be CID. Besides for implementation differences, technical issues of VoIP will be relevant to these other protocols.
As a whole, POTS has become increasingly rare in many businesses and homes. Many factors are contributing to this phenomenon; from legacy costs and upkeep of copper lines, convergence of internet, television, and telephone services, and customers looking to reduce monthly expenses.
Often times, customers change to a VoIP phone service without discusssing the implications with their monitoring service. No one solution can solve this issue but education and transparency can go a long way in avoiding unreliable signal transmissions.
The following is a Contact ID message. If a dialer were to call your phone, this is what you would hear.
The first two tones are the handshake tone from the Monitoring Station. The signal is sent to the alarm dialer to verify that the Monitoring Station is ready for the message.
If you grew up when the world still used Dial-Up Internet, the next portion is a familiar sound; dual-tone multi-frequency (DTMF) digits. DTMF uses a low and high frequency to transmit a hexadecimal digit (0-9, A-F). For example, the Digit '1' is represented by a low tone of 697hz and a high tone of 1209hz played simultaneously while the digit '8' uses a low tone of 852hz and a high tone of 1336hz. CID sends each digit in a 50 millisecond on/off burst.
This particular message is:
1234 18 1 110 01 015 1
A quick synopsis of this ContactID message:
To our ears, ContactID messages provides us with very little information. The signal is typically parsed at a communications receiver located in a central monitoring station. From here, staff are alerted to the signal where it is "translated" and the appropriate action can be taken based on the customer and signal type.
There are many standards of VoIP and most do account for DTMF signaling. Not all standards use the same codecs and protocols. In this context, codecs govern audio compression and quality while protocols refer to the rules on how computers communicate with one another.
When a VoIP call occurs, an analog audio wave is transformed into data packets that are represented by 1's and 0's, as dictated by the codec. These data packets are sent via an “audio stream” using the Real-Time Transport Protocol (RTP). RTP is the transmission protocol of choice when timing is favored over accuracy. This focus on timing may lead to dropped data packets which reveal themselves as jittery audio in a call or as a pixelated video during a live video stream. To facilitate a speedy transmission, VoIP uses a compression codec, such as G.729 or G.711, to decrease both the file size and bandwidth requirements.
One method of VoIP DTMF signaling is In-Band DTMF. In-Band DTMF will travel in the same audio stream as the voice data which brings about the first issue. The codec used for VoIP may introduce a compression algorithm to make the data smaller, particularly with the G.729 codec. G.729 is often called "lossy" because the compression used often cuts off certain parts of the audio wave, typically the extreme highs and lows of the wave. ContactID standards note, "Transmitters shall accept a frequency error of at least ± 5% to ensure back-compatibility with older receivers." With this compression, the signal may be out of specification and fail to be recognized or misread.
Another method for DTMF signaling is Out-of-Band DTMF. Out-of-Band DTMF eliminates the compression issue of In-Band DTMF by sending the signal “outside” the audio stream, bypassing any compression algorithm. This signaling method works well when using touch-tone features, such as accessing voicemail or selecting an option for tech support.
RFC 2833 is a document that lays the foundations for VoIP and how it handles Out-of-Band DTMF. This method of VoIP DTMF signaling meets all requirements for ContactID. The major issue with this method often falls outside the ability for any one group to correct.
If a customer site is using In-Band DTMF, a mid-point or end-point switch may detect this In-Band DTMF signal and automatically transform it to an Out-of-Band DTMF signal. This detection occurs nearly instantaneously but a small portion of the DTMF signal still “escapes”. This leads to an In-Band and Out-of-Band DTMF signal arriving at different times leading to interruptions of the signal.
The best solution for all parties is to avoid VoIP with alarm transmissions. Besides for a true POTS line, other alternatives include TCP/IP Communicators and Cellular Communicators. If VoIP cannot be avoided, extensive testing and verification should be practiced to avoid potential issues and liabilites.
Please Note: Although Cler Systems uses reasonable efforts to obtain information from reliable sources, Cler Systems makes no representations or warranties as to the accuracy, reliability or completeness of information contained on this site.