• 5.2.1. Null State
• 5.2.2. Offered State
• 5.2.3. Connected_Wait_Sig State
• 5.2.4. Disconnected State
• 5.2.5. Stop_Connection State

5.2. Inbound IP Call

The following state diagram describes the call states for an inbound call from the IP to the demo. Each state is represented by an ellipse containing the state name, the event(s) associated with that state, and the actions performed by the application. The states are connected with arrows indicating the valid state changes.

NOTE:

Due to space restrictions, the state name in the diagram is presented in shortened format. Each state name should be prefixed by IPTMAIL_.

Figure 3. State Diagram - Inbound IP Call

5.2.1. Null State

The application waits for a call event in the IPTMAIL_ NULL state.

When the application receives the event GCEV_OFFERED, it calls an internal function ipAnswerCall( ) which fills the gcParmBlk structure with coder information and sends gc_SetUserInfo( ) and gc_AnswerCall( ) to the firmware. The call state transitions to IPTMAIL_ OFFERED.

If, for any reason, the call should fail, the application receives a GCEV_TASKFAIL event. The application is ended and all channels are moved to the IPTMAIL_QUIT state.

5.2.2. Offered State

When the application receives a GCEV_ANSWERED event, it routes the IP and Voice devices to listen to each other, flushes the DTMF buffer, enables the DTMF tones used by the Main menu, and plays the Main menu. The call state transitions to IPTMAIL_ CONNECTED_WAIT_SIG.

If, for any reason, the function should fail, the application receives a GCEV_TASKFAIL event. It calls the internal function DisconnectCall which, in turn, stops the I/O operation if in process, calls gc_DropCall( ), and unRoutes the call, if needed. The call state transitions to IPTMAIL_ DISCONNECTED.

If, for any reason, the remote side should disconnect, the application receives a GCEV_DISCONNECTED event. It calls the internal function DisconnectCall which, in turn, stops the I/O operation if in process, calls gc_DropCall( ), and unRoutes the call, if needed. The call state transitions to IPTMAIL_ DISCONNECTED.

5.2.3. Connected_Wait_Sig State

The application waits for the user to make a selection from the Main menu:

• record a message ("1")
• listen to a message ("2")
• exit ("*")

When the application receives a TDX_PLAY event, itdetermines if the Player was stopped because it reached the end of data or a DTMF digit was detected. In the case of end of data (TM_EOD), the Player replays the menu. In the case of a digit (TM_MAXDTMF), the application sends dx_getdig( ) to retrieve the digit.

The application waits in the IPTMAIL_CONNECTED_WAIT_SIG_STATE until it receives a TDX_GETDIG event.

If the retrieved digit is "1", the application plays the Send_Message menu. The call state transitions to IPTMAIL_CONNECTED_REC_AND_SEND.

If the retrieved digit is "2", the application plays the Start_Listen menu. The call state transitions to IPTMAIL_CONNECTED_START_LISTEN.

If the retrieved digit is "*", the application plays the Thank_You menu and the call state transitions to IPTMAIL_STOP_CONNECTION.

If no digit was retrieved (due to timeout or a non-enabled digit), the application re-plays the Main menu.

The application can also receive a GCEV_DISCONNECTED event. It calls dx_stopch( ) to prevent further playing, unroutes the clusters, and calls gc_DropCall( ).

Once the call state transitions to IPTMAIL_CONNECTED_WAIT_SIG, the demo application begins to operate in voice-mail mode. See Chapter 6. Using the Voice Mail for a complete description of this part of the demo.

5.2.4. Disconnected State

The application waits for a GCEV_DROPCALL event. When it receives this event, it sends the ExtensionGetCallInfo( ) function to get the call duration time and RTCP information. This information is returned in the GCEV_EXTENSION event. When it receives this event, the application calls gc_ReleaseCall( ) and then calls IPTResetSession( ). The call state transitions to IPTMAIL_NULL and the channel may be reused.

If the Player or Recorder haven't yet been closed, the application waits for a TDX_PLAY or TDX_RECORD, closes the file and calls DisconnectCall( ) which in turn calls gc_DropCall( ).

5.2.5. Stop_Connection State

The application waits for a TDX_PLAY event. It requests the termination reason, closes the played file, unroutes the devices and calls gc_DropCall( ). The call state transitions to IPTMAIL_DISCONNECTED.

The application may receive a GCEV_DISCONNECTED event. It checks to see if the Player has stopped. If PlayerStopped = FALSE, it sends dx_stopch( ) and waits for TDX_PLAY and TM_EOD events. Upon receipt of these events, the application unroutes the clusters and calls gc_DropCall( ). The call state transitions to IPTMAIL_DISCONNECTED.

Click here to contact Dialogic Customer Engineering