NOTIFeye
Technical underpinnings of the mass notification system
NOTIFeye
»
TECHNOLOGY
Designed for flexibility, resilience, and performance
Runs as a service on Linux, on-premise or in the cloud
Flexible interfaces offers sockets, web sockets, and ReST, with native JSON data structures for all in and out
Push and pull (publish-subscribe) triggers to send notifications
One-way and two-way alerts to automate not just notifications but also capture response data from recipients
Interfaces to online services and local communication devices to support continued operations during physical disasters
Block Diagram
Major Modules
The Trigger Interface module is responsible for receiving alerts from various endpoints. The alerts can arrive unsolicited (push to NOTIFeye) or solicited (poll external systems / devices or subscribe to triggers from those endpoints). All alerts are challenged for security, and then handed to the Rules Processor module. All communications with trigger endpoints are logged.
The Rules Processor module is responsible for receiving approved notification requests and retrieving their associated templates. The templates dictate the rules which must be applied, which affect target selection, sequencing of notifications, and conditions which determine steps taken. The Rules Processor sends individual notifications to the Alert Interface module to perform the communications.
The Alert Interface module is responsible for transmitting messages to various endpoints. The message can be in textual form or sound form depending on the endpoint, with automatic text-to-speech conversion when necessary. The Alert Interface module is also responsible for receiving responses from (two-way) endpoints, and storing that data for later tabulation. The stored data will include responses from endpoints which support delivery and/or read status confirmations, as well as responses to message which request feedback.
The Scheduler module is responsible for scheduling and resuming in-progress rules which have been suspended based on time of day or date. This allows rules to defer transmission of notifications based on various criteria, on a per-user and per-endpoint basis.
The Security Controller module is responsible for enforcing security policies for all connections, users, roles, endpoints and devices. As well, the Security Controller logs threats and attempted breaches for subsequent audit and review. In the even of ongoing attack, the Security Controller will also block endpoints / users / connections.
The Report Processor module is responsible for generating reports on-demand, and based on predefined schedules. All reports are stored in a database in JSON format, for subsequent retrieval and formatting by external systems. NOTIFeye bundles commonly used reports, and Telium can create customized reports for customers.
The Management Controller module is responsible for managing user accounts and attributes, enabling/disabling endpoints, and controlling operations of the NOTIFeye system. All management functionality is accessible through API’s, and also through a command line interface (for core configuration / diagnostics).
Trigger Endpoints
Web (push)
A web trigger endpoint is a remote system which connects to NOTIFeye using typical web protocols like ReST or WebSockets. Message are pushed from the remote system and contain JSON formatted data, providing all parameters required by the specified template.
Systems (push / pull)
A system trigger endpoint is a remote system which connects to NOTIFeye using TCP sockets. Messages are pushed from the remote system and contain JSON or key-value pair formatted data, providing all parameters required by the specified template. Alternatively, messages can be pulled from the remote system using a publish-subscribe mechanism such as MQTT.
E-Mail (push)
An e-mail trigger endpoint is a remote system which connects to NOTIFeye using the SMTP protocol. Messages are pushed from the remote system and contain JSON or key-value pair formatted data in the body, providing all parameters required by the specified template.
Device (push)
A device trigger endpoint is a remote piece of hardware which connects to NOTIFeye using a digital or analog input signal. Requests are pushed from the remote device as momentary open/closed contacts, serial data, or other similar mechanism. Each device endpoint is associated with a specific template, which is prepopulated with with all required parameters ; device endpoints may optionally include template data based on the connection type.
Phone (push)
An phone trigger endpoint is a telephone connected to NOTIFeye using analog (POTS), SIP, or H.323. Each phone endpoint is associated with a specific template, which is prepopulated with with all of the required parameters based on the phone extension; phone endpoints may optionally provide additional template data based on DTMF / IVR menus.
SMS (push)
An SMS trigger endpoint is a remote text device / system which connects to NOTIFeye over the PSTN SMS network. Messages are pushed from the remote device / system and contain JSON or key-value pair formatted data in the body, providing all parameters required by the specified template. Optionally, the receiving number can be used to select a template and/or provide fixed parameters.
Peer-To-Peer (pull)
A peer-to-peer trigger endpoint is a communication device which connects to NOTIFeye using Meshtastic or Reticulum protocols. Messages are received via a dedicated communication device after NOTIFeye joins the mesh network. Messages can arrive in JSON or key-value pair formatted data, providing all parameters required by the specified template.
Alert Endpoints
Web (1-way)
A web alert endpoint is a remote system to which NOTIFeye connects using typical web protocols like ReST or WebSockets. Messages are pushed to the remote system and contain JSON formatted data, providing all information specified by the template.
SMS (1-way)
An SMS alert endpoint is a remote text device / system which NOTIFYeye connects to over the local cell network, or internet based service, to deliver an SMS message. Messages are sent in plain format, providing all information specified by the template.
Systems (1-way/2-way)
A system alert endpoint is a remote system which NOTIFeye connects to using TCP sockets or MQTT. Messages to the remote endpoint can contain JSON or key-value pair formatted data, in the format specified by the template. As well, response messages can be received from the remote system confirmed delivery or read receipts, or to provide an informational response.
E-Mail (1-way/2-way)
An e-mail endpoint is a remote device which NOTIFeye connects to (indirectly) using the SMTP protocol. Messages are sent to remote system and contain body data in the format specified by template. Delivery and read receipts can be received from the remote endpoint, as well as information prompted for in the original email.
Signage (1-way)
An signage alert endpoint is a sign that NOTIFeye connects to using a variety of digital protocols, to display a message. Each signage endpoint is associated with a specific (or shared) template, which is populated with the parameters specified in the template.
Phone (1-way)
An phone alert endpoint is a telephone NOTIFeye connects to using analog (POTS), SIP, or H.323. Each phone endpoint (extension) is associated with a specific (or shared) template, which is populated with the parameters specified in the template. Phone endpoints may optionally include receipt (answer) confirmation, or information gathered via DTMF / IVR menus. Messages delivered to phone endpoints are pre-recorded messages, or text-to-speech generated messages.
Radio (1-way)
An radio alert endpoint is a device on an RF network NOTIFeye connects to using text messaging (e.g. P25 SDM) or audio (e.g. P25 voice or FM voice). Messages are sent over the RF network as broadcasts or directed to Talkgroups, as specified in the template. RF endpoints may optionally include receipt confirmation if provided by SDM.
Social Media (1-way)
An social media alert endpoint is a service that NOTIFeye connects to over the internet. Each social media message contains all data specified in the template, and is sent in the format required of the particular social media outlet. The message is subsequently presented on the social media platform.
Peer-To-Peer (2-way)
A peer-to-peer endpoint is a communication device on a mesh network that NOTIFeye connects to using the Meshtastic or Reticulum protocols. Messages are sent via a local communication device after NOTIFeye joins the mesh network. Messages are formatted and populated using fields specified by the associated template.