In order for an emergency phone to communicate successfully with the recipient of the call (be it an alarm call, a scheduled test call, or an ad-hoc technical fault/event reporting call), it needs to know in what format that call should be placed – this is defined by selecting from one of the available call protocols on the device, and the chosen protocol must match whatever the recipient is expecting to receive.
The most basic of the protocols are voice-only, which allow them to be used with recipients answering the calls on a standard phone handset, but which don’t then permit the transfer of much information from the emergency phone.
As the protocols increase in complexity, they gain the ability to transfer data in one or both directions during certain points in the call and, depending on the type of call will then also have the ability to switch into voice mode.
ContactID originated in the security industry as a lightweight data protocol used by intruder and fire alarm control panels for sending system status updates to a remote monitoring centre, and due to the ease of implementation (and compatibility with existing call centers, at least for data-only call types) it’s also been adopted by other types of system including emergency phones.
P100 originated within the emergency phone industry and is now considered something of a “standard” protocol for emergency phones which can be found supported by phones and receivers from many different manufacturers. It’s slightly more complex than ContactID, allowing for more data to be sent from the phone to the receiver, but as with ContactID it’s designed only for sending data to the receiver.
Memco is the Avire proprietary protocol, which provides full bidirectional data transfer capabilities between a Memcom phone and the call center.
All these protocols rely on the use of audible tones (DTMF or similar) to transfer their data, as they all originated in the days when emergency phones were expected to be connected directly to a landline.
During a call, the emergency phone will almost always need to transmit at least some amount of information to the call recipient.
For an EN81-28 compliant alarm call, the phone needs to send something that can be used to identify where the call is coming from.
During a technical fault call, there will also need to be some additional information indicating the type of fault (usually these will be the status of the battery, the speaker, and/or the microphone).
For the “voice-only” guided protocol, all of this information is sent to the recipient using pre-recorded audio messages – phone identification uses the location message which the installer should have recorded during the system setup, event/fault types use factory-preset recordings to build up a fault/event type code message (e.g., “fault code zero-two-six”).
For the “voice+data” protocols (Memcom uses ContactID, P100 and the proprietary Memco protocols), this information is sent as data using DTMF tones at the start of the call which the call centre system can easily decode/log, and if it’s an alarm call then the phone switches into live voice mode for the two-way conversation part of the call, whereas for test and tech event calls there’s no need to enter voice mode and so the call ends once all the information has been exchanged. With these protocols, additional information may then also be sent during the data part of the call to enhance the call handling process.
On Memcom there are no “data-only” protocols – every protocol can handle every type of call. The type of call is what determines whether the phone needs to send only information or both information and voice. The choice of protocol merely then determines how the information part of the call is transmitted.
In the event of a Memco alarm call, in addition to the phone identification information, information about the health of the phone, as well as which alarm push was activated to place the call is also sent.