7.2.  Inbound IP Call

• 7.2.1.  Init State
• 7.2.2.  Null State
• 7.2.3.  Offered State
• 7.2.4.  Connected_Wait_Sig State
• 7.2.5.  Disconnected State
• 7.2.6.  Released State
• 7.2.7.  Stop_Connection State

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

7.2.1.  Init State

The application waits for a GCEV_UNBLOCKED event in the IPTMAIL_INIT state. Upon receiving this event, the application calls gc_GetXmitSlot(VoiceH) to get the transmit time slot (Xmitslot) for the IP devices and saves it in the AppSession.ipParams structure.

The application then calls gc_WaitCall( ) to set the conditions for processing an inbound call.

If the application receives GCEV_TASKFAIL, GCEV_BLOCKED, or GCEV_OPENEX_FAIL, it calls endApplication( ) to gracefully shut down the application.

If the application receives GCEV_OPENEX, it does nothing so as to avoid causing an error.

7.2.2.  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, gets the protocol name, 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 calls endApplication( ) to gracefully shut down the application.

7.2.3.  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, unroutes the call if needed, and calls gc_DropCall( ). 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, unroutes the call if needed, and calls gc_DropCall( ). The call state transitions to IPTMAIL_DISCONNECTED.

7.2.4.  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, it determines 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 time-out or a non-enabled digit), the application replays the Main menu.

The application can also receive a GCEV_DISCONNECTED event. It calls an internal function DisconnectCall( ), which calls dx_stopch( ) to prevent further playing, unroutes the clusters, and calls gc_DropCall( ). The call state transitions to IPTMAIL_DISCONNECTED.

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

7.2.5.  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( ) in asynchronous mode. The call state transitions to IPTMAIL_RELEASED.

If the Player or Recorder hasn'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( ).

7.2.6.  Released State

The application waits for a GCEV_RELEASECALL event. When it receives this event, it sends IPTResetSession( ) and the call state transitions to IPTMAIL_NULL.

If, for any reason, the call should fail, the application receives a GCEV_TASKFAIL event. The application calls endApplication( ) to gracefully shut down the application.

7.2.7.  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 Telecom Support Resources