# An Approach to Designing Critical Railway Voice Communication
## 4 FRMCS Common Functions as RESTful Service Blocks
### FRMCS Critical Support Application API
The feature is required when users with ongoing voice communication, e.g., shunting team members, need to join another user, e.g., a controller. Upon application triggering, the FRMCS system automatically routes the invitation to the desired user(s). The status of the invitation (e.g., pending, rejected) is presented to the inviting user. The invitation is presented to the receiving user(s), along with the inviting user's functional identity, location, and description of the incoming call. A user receiving the invitation who is not involved in another call can accept the invitation and join the ongoing call, and in this case, all users involved are notified about the new call participant(s). A user receiving an invitation who is already involved in another call has the choice to leave or terminate the current call and connect to the incoming call related to the invitation or merge the two calls. A user can reject or ignore the invitation and the inviting user is notified. An FRMCS  
Figure 6: Structure of resource URIs related to the QoS class negotiation function. Figure 7: Structure of resource URIs related to assured voice communications. user involved in a call can use the Invite-a-user messaging (IUM) service to invite another FRMCS user to join the ongoing call. Figure 8 depicts the structure of the resource URIs of the IUM service. Table 2 provides an overview of the defined resources supported by the IUM service and the applicable HTTP methods. The service clients communicate with the IUM service over the service API to invite users to join an existing ongoing call and receive information about the invitation status. The IUM API supports both invitation requests and subscriptions. Another feature of critical voice communications is multiuser talker control. This function allows for the control and restriction of simultaneous talkers' numbers, the configuration of the initial prioritization and permission to talk, the ability to request permission to talk, and the granting/revoking of permission to talk by an entitled call participant. The functionality of multiuser talker control can also be synthesized as a Multiuser Talker Control (MUTC) service. Figure 9 shows the overall communications between entities involved in multiuser voice communication for three use cases. The first use case is related to the change in the number of simultaneous talkers, where the MUTC service can revoke the permission to talk in case the number of active talkers is higher than the allowed number. The second use case illustrates an automatic permission decision made by the MUTC service. In the third use case, the entitled call participant makes the decision about the permission to talk. \begin{table}
\begin{tabular}{c c c} \hline
**Resource Name** & **Resource URI** & **HTTP Methods** & **Description** \\ \hline  & & GET & Retrieves the list of all invitations to users \\ All invitations to join a call & /invitationsToJoin & & to join an ongoing call. \\ Individual invitation to join & /invitationsToJoin/ & & \\ a call & invitationToJoinID & & \\ A list of subscriptions to & & & \\ notifications about the & /invitationSubscriptions & & to notifications about the invitation status \\ invitation status & & & \\  & & POST & \\  & & GET & \\ Individual subscription to & /invitationSubscriptions/ & & \\ notifications about the & /invitationSubscriptionID & & \\ invitation status & & & \\  & & DELETE & \\ \hline \end{tabular}
\end{table} 
Table 2: IUM service resources and methods. Figure 8: Resource URI structure of the IUM service. Figure 10 shows the URI structure of resources related to multiuser talker control. The resources represent calls with active multiuser talker control and subscriptions for notifications about requests to talk and the need to select talkers. More information about the MUTC service can be found in [33]. The support applications designed as RESTful services can be used as service bricks that constitute the logic of critical communication applications.