Our application has evolved from the original App in the MCOP SDK, while still retaining backward compatibility. The new design chooses to mimic typical messaging apps so that it is intuitive and the users do not have to spend time learning how to use it.
Please note that we are not just creating yet another messaging App. Instead, we have made a lot of effort to enable the innovative features on the traditional MCPTT channel, so that the first responders can still feel that they are using their familiar and dedicated channel. Moreover, they can take advantage of the screen and data capabilities of smartphones to provide just the right functionality they need.
Here, we have 4 devices representing 4 users. From left to right, we have Alice, who is using the original App from MCOP SDK, Bob (firefighter), Charlie (EMT) and Ed (Commander) are using our application.
In the interface, we use intuitive aliases so that the first responders do not have to remember MCPTT IDs.
Just for demo purposes, at the bottom of each device, we visualize the audio input and output to help distinguish the messages from different devices when they are playing at the same time.
All the users are now in a group call, and Alice is going to push and talk. You can observe the microphone input on Alice and the speaker output on the other devices.
You can see that our application is compatible with MCOP, which means we are working on the dedicated MCPTT channel.
Similarly, when users push and talk using our application, the users on the original MCPTT will also receive the messages (see the videos below).
For each message received, our application performs speech-to-text in the cloud. If Bob did not hear the message clearly, he can look at the text. To make it easier for the users, we also put the sender and the length of each message at the top.
In addition to speech-to-text, we also store the message audio received. If the text is still not clear enough, Bob can replay the message by clicking the message body.
Since we store the messages, they will be available for future use, such as supervisory review, evidence, etc.
Let's assume that Charlie needs to focus a task now. He can click the "do-not-disturb" button on the bottom left.
When Alice speaks again, the message will be buffered on Charlie.
Although the message is buffered, our application still turns it into text so that Charlie can take a quick glance if he has time. The pending messages are marked in green.
Charlie can also allow some users to override the do-not-disturb mode by long-click the "do-not-disturb" button.
In the demo. we allow messages from emergency calls and Ed (Commander) to override the do-not-disturb mode. When Ed sends a message which asks the team members to evacuate, Charlie receives it.
When Charlie finishes his work, he can exit the do-not-disturb mode. The pending messages will be played one after another.
When a user is in a situation where it is difficult to speak, he can choose to send text messages via text-to-speech or SMS.
In text-to-speech, our application first synthesizes the text into speech and then sends the voice using MCOP. This solution is backward-compatible with the original MCOP.
To send an SMS message, the application delivers the text via our own (NGMCPTT) server. On receiving the text, the applications can synthesize the text into speech based on the network speed and cloud capacity. While this solution is not backward compatible, it saves a lot of network traffic since text messages are much smaller compared to voice messages, and faster to deliver. It is useful especially when the network connectivity is not good.
The comparison between the protocol exchange of text-to-speech (over MCOP) and SMS (in NG-MCPTT) is shown below:
Our application allows a user (Ed) to push and talk even when the channel is busy (occupied by Bob sending a long report). The application would buffer the message until when it can acquire the floor and send the message.
Compared to the first responders that use smartphones, dispatchers usually have devices with larger screens (e.g., tablets). On these devices, we take advantage of the extra screen space to show more information. In addition to the basic messaging features (on the right), we show the geo-location of the first responder units (in the middle), dynamic group management (on the top left), and unit affiliation management (on the bottom left).
The dispatcher can easily locate a unit by clicking the "locate" button next to each unit. The unit will be centered on the map even if the unit is not in the current view. Similarly, the dispatcher can also show the location of every unit in a group by clicking the "locate" button next to the group.
For units that are currently offline, we show the time and location of his/her last check-in.
We allow the dispatcher to dynamically create/delete groups, and affiliate/remove units to/from the groups. The first responders (including the dispatcher) can use the (new) groups to communicate.
Our application allows first responders to make normal and emergency calls in both private and group calls. The functionality is backward-compatible with the original MCOP.
We also allow users to dynamically upgrade/downgrade calls according to the situation. It is currently mimicked using our NG-MCPTT server.
We allow the incoming emergency call to override an ongoing normal call. However, if both the incoming and the ongoing calls are of the same priority, the incoming call will be hang up.
When a user can use fingerprint(s) to log into the device, we allow the user to use the same (set of) fingerprint(s) to login to the MCOP platform using the user ID set in the provisioning tool (the application will fill in the username and password automatically). This could save time for the first responders when entering the system.
We provide support for connected, intermittently-connected, and infrastructure-less environments, and allow smooth transition among these environments.