{"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

What do protocols do?<\/h2>\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

Types of protocols<\/h2>\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

\"\"<\/figure>\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

What information is transmitted?<\/h2>\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

What are test (P100) calls and how do they work?<\/h2>\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