{"id":2964,"date":"2023-08-03T14:13:12","date_gmt":"2023-08-03T14:13:12","guid":{"rendered":"https:\/\/www.avire-global.com\/articles\/?p=2964"},"modified":"2023-09-13T07:35:17","modified_gmt":"2023-09-13T07:35:17","slug":"emergency-phone-universal-p100-protocol","status":"publish","type":"post","link":"https:\/\/www.avire-global.com\/articles\/emergency-phone-universal-p100-protocol\/","title":{"rendered":"Emergency phone: universal P100 protocol"},"content":{"rendered":"\n
Emergency lift phones<\/a> can use many different protocols to perform the mandatory 3-day test calls, however the P100 is the most popular open-source protocol. In this post we explain what protocols are and how they work.<\/p>\n\n\n\n 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 \u2013 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.<\/p>\n\n\n\n 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\u2019t then permit the transfer of much information from the emergency phone.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 centres, at least for data-only call types) it\u2019s also been adopted by other types of system including emergency phones.<\/p>\n\n\n\n P100 originated within the emergency phone industry and is now considered something of a \u201cstandard\u201d protocol for emergency phones which can be found supported by phones and receivers from many different manufacturers. It\u2019s slightly more complex than ContactID, allowing for more data to be sent from the phone to the receiver, but as with ContactID it\u2019s designed only for sending data to the receiver.<\/p>\n\n\n\n MEMCO is the AVIRE proprietary protocol, which provides full bidirectional data transfer capabilities between a Memcom phone<\/a> and the call centre.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n During a call, the emergency phone will almost always need to transmit at least some amount of information to the call recipient.<\/p>\n\n\n\n For an EN81-28 compliant<\/a> alarm call, the phone needs to send something that can be used to identify where the call is coming from.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n For the \u201cvoice-only\u201d guided protocol, all of this information is sent to the recipient using pre-recorded audio messages \u2013 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., \u201cfault code zero-two-six\u201d).<\/p>\n\n\n\n For the \u201cvoice+data\u201d protocols (Memcom<\/a> 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\u2019s 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\u2019s 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.<\/p>\n\n\n\n On Memcom there are no \u201cdata-only\u201d protocols \u2013 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The European Standard EN81-28 specifies that an emergency phone call must call out every 3 days to place a test call to verify it\u2019s in working order, and that test call has to be placed to a receiver software that will log the results.<\/p>\n\n\n\n Most manufacturers of emergency phones have developed receiver software that can receive and record the outcome of the test calls.<\/p>\n\n\n\n The first thing a receiver will check is whether the call was placed \u2013 if not, it will register that there is a problem with the hardware or the communication link to the phone (e.g., the telephone line).<\/p>\n\n\n\n If the call does go through correctly, it will then check each step of the call handling protocol that emergency telephones follow:<\/p>\n\n\n\n Each autodialler manufacturer uses its own protocol so the average call centre can end up handling multiple protocols and therefore require multiple receivers. This can be a problem as the record of the calls can then be split amongst several receivers, and in some cases, additional dedicated hardware may be necessary (i.e., a dedicated modem, mini server, etc.) which makes the average install base more expensive and difficult to monitor.<\/p>\n\n\n\n The emergency telephone uses the voice channel to broadcast DTMF on order to send information. This works well over copper telephone lines, which were designed for analogue signalling, though there is an expense to the owner of the autodialler as each call is charged as a voice call.<\/p>\n\n\n\n As we move into a fibre line network (aka the Digital Switch) that is built to transmit voice and data, rather than only voice, DTMF audio transmissions will face new challenges as fibre networks may not support DTMF at all!<\/p>\n\n\n\n The most common option installers will choose is to install a GSM<\/a> so the emergency telephone can work over the mobile network.<\/p>\n\n\n\n However, it\u2019s not as simple as just plugging in any GSM as the following issues of P100 DTMF transmission over a fibre line may still occur:<\/p>\n\n\n\n In other words: if you push DTMF signals into a mobile network it may present problems and trying to solve this with any 2G gateway may still present a drop in the performance of the calls.<\/p>\n\n\n\n Luckily not all GSMs were born the same.<\/p>\n\n\n\n Currently, not all lift phones are set up to transmit digital data, but this can be easily solved by adding a Digital Communication Platform (DCP)<\/a> to the emergency communication chain.<\/p>\n\n\n\n As most European manufacturers support P100 as an option for their emergency phones, the DCP (aside from supporting both the MEMCO and MK proprietary protocols) can act as an interpreter for any emergency telephone that uses the P100 protocol and will then be able to transmit either analogue audio or digital data (via a SIM card<\/a>).<\/p>\n\n\n\n To explain the analogue compatibility feature of the DCP based on P100: the DCP intercepts DTMF tones generated by the emergency telephone, reads, and converts them into data. In this way, the smaller, local loop (the connection between phone and GSM), remains analogue whilst the bulk of the communication is transformed into data, increasing its reliability.<\/p>\n\n\n\n DTMF to data conversion is a feature unique to MEMCO\u2019s DCP. The average GSM doesn\u2019t offer this capability.<\/p>\n\n\n\nWhat do protocols do?<\/h2>\n\n\n\n
Types of protocols<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
What information is transmitted?<\/h2>\n\n\n\n
What are test (P100) calls and how do they work?<\/h2>\n\n\n\n
\n
New challenges to P100<\/h2>\n\n\n\n
\n
<\/figure>\n\n\n\n
The digital solution \u2013 signal transmission<\/h2>\n\n\n\n
The digital solution \u2013 monitoring and reporting<\/h2>\n\n\n\n