Chapter 5 A Client-Side Design for PoC Service
5.2 Implementation of PoC Client
The PoC client architecture proposed in this chapter is illustrated in Figure 5-2. The details are given in the following subsections.
5.2.1 User Interface Module
A user interacts with the PoC system through the User Interface module (Figure 5-2 (1)).
Figure 5-2. PoC Client Architecture
This module consists of four main window dialogs. The Login dialog (Figure 5-3(1) and Figure 5-4 (a)) is popped up after the PoC client program is executed. It waits for the user to input the SIP URI (for the PoC client) and the password, and then executes the SIP registration procedure. After the user is authenticated, the PoC client enters the standby mode, and the Phone dialog (Figure 5-3 (2) and Figure 5-4 (b)) is activated. The Phone dialog alerts the user when an incoming call arrives. If the user misses the call, the Phone dialog shows the missed call information on the user interface. The user can change the presence status through the Phone dialog. After closing the Phone dialog, the user can select to open the Main dialog (Figure 5-3 (3) and Figure 5-4 (d)) or the Taskbar Status Area icon (Figure 5-3 (4) and Figure 5-4 (c)). In the Taskbar Status Area icon mode, when a call arrives or a call is missed, a message window is popped up to notify the user. The Main dialog contains 5 pages. The Personal Information page (Figure 5-3 (5)) presents the user's personal information. The Phone Book page (Figure 5-3 (6) and Figure 5-4 (d)) shows the PoC group information and VoIP contact list. The Configuration page (Figure 5-3 (7)) allows the user to set the ringing tone, the IP address of GLMS, and network configuration. The Call Record page (Figure 5-3 (8)) provides the call history information. The PoC/VoIP Call page (Figure 5-3 (9)) is created when a call is established.
This page presents the call information, and allows the PoC user to request the floor.
Figure 5-3. Functionalities of the User Interface
Figure 5-4. The User Interface
5.2.2 Call Control Module
The Call Control module (Figure 5-2 (3)) instructs other PoC client modules to handle the call related activities according to the presence status of the user and the preference types
of other call parties. Figure 5-5 illustrates the state diagram for the call control finite state machine (FSM) maintained by the Call Control module. The states are described below (where the term "user" represents this PoC client).
Figure 5-5. State Diagram of the Call Control FSM
Init: The FSM waits for SIP registration.
Standby: The FSM waits for an incoming/outgoing call.
SendInvite: The user requests an outgoing call.
RingBack: The other call party is ringing.
CancelCall: The user cancels the call.
Accepted: The outgoing call is accepted by the other call party.
Rejected: The outgoing call is rejected by the other call party.
RecvInvite: An incoming call arrives.
Ringing: The PoC client is playing the ringing tone to notify the user of the incoming call.
Cancelled: The incoming call is cancelled by the other call party.
AcceptCall: The user accepts the incoming call.
RejectCall: The user rejects the incoming call.
CallNotEstablished: The call is not established.
CallEstablished: The call is established, and the conversation begins.
SendBye: The user requests to disconnect the call.
RecvBye: The other call party requests to disconnect the call.
CallDisconnected: The call is disconnected.
Details of the state transitions will be given in Section 5.3.
5.2.3 Floor Control Module
When a PoC call party obtains the “floor”, he/she has the right to speak at that moment. To obtain the floor, the PoC client needs to send a floor request to the PoC server and wait for a positive response. In addition, the PoC server broadcasts the floor status to the call parties (e.g., someone has obtained the floor). The floor-related functionalities are implemented in the Floor Control module (Figure 5-2 (4)). This module maintains an FSM with the state transition diagram illustrated in Figure 5-6. When a PoC call is established, the Call Control module issues a StartFloorReq command to activate the floor control FSM (transition 1 in Figure 5-6). Details of other state transitions are described in Section 5.3.
The states are described as follows.
Init: A PoC call is activated. The user is waiting for a floor control signal from the PoC server.
Free: No call party has the floor. The user is free to request the floor.
ReqPending: Floor request has been sent to the PoC server. The user is waiting for the response.
Owner: The user obtains the floor.
Figure 5-6. State Diagram of the Floor Control FSM
Reserved: Some other call party obtains the floor.
RelPending: Floor release request has been sent to the PoC server. The user is waiting for the response.
5.2.4 Other PoC Client Modules
The GLMS Access, the Multimedia Control, the SIP Core, and the RTP Core modules are described in this subsection.
z The GLMS Access module (Figure 5-2 (2)) is responsible for retrieving the user's information from the GLMS.
z The Multimedia Control module (Figure 5-2 (5)) plays the ringing tone, the ringback tone, or the busy tone to notify the user of various call states. After a call is established, this module plays the received voice data from other call parties and
records the user's voice when the user is permitted to speak.
z The SIP Core module (Figure 5-2 (6)) supports SIP communication with other network entities in the PoC system (e.g., GLMS and PoC servers). This module is invoked by three PoC client modules for SIP communication.
(1)
The GLMS Access module interacts with the GLMS through the SIP MESSAGE method.(2)
The Floor Control module (Figure 5-2 (4)) exchanges the floor control signals with the PoC server by using the SIP INFO method.(3)
The Call Control module (Figure 5-2 (3)) executes the call setup or disconnection procedures following the standard SIP VoIP protocol.In our implementation, the eXosip library [51][52] is utilized for SIP protocol support, and newly added functionalities (e.g., SIP mobility) are also
incorporated.
z The RTP Core module (Figure 5-2 (7)) builds a RTP session between the PoC client and the RTP proxy (for a PoC call), or another call party (for a VoIP call). The RTP Core module is implemented based on the oRTP library [43].
In the proposed PoC client architecture, the GLMS Access module and the Floor Control module are specifically designed for PoC service. Other modules are used in both PoC and VoIP services.