56 Global Call API for HMP on Windows Programming Guide — August 2006
Call State Models
The following sections describe the asynchronous outbound call processes, as shown in Figure 11,
“Basic Asynchronous Outbound Call State Diagram”, on page 54.
3.4.2.2 Channel Initialization
To establish calls, the following conditions must be met:
The condition of the line device must be unblocked. When a channel is initially opened, the
initial condition of a line device is blocked. A “blocking” condition on a line device is
indicated by the reception of a GCEV_BLOCKED event and an “unblocking” condition on a
line device is indicated by the reception of a GCEV_UNBLOCKED event. The
GCEV_BLOCKED and GCEV_UNBLOCKED events are sent as unsolicited events to the
application in response to blocking alarms. (For more information on blocking alarms and the
GCEV_BLOCKED and GCEV_UNBLOCKED events, see Section4.3, “Blocked and
Unblocked Event Handling”). When the condition of the line device is unblocked, the line
device is ready for establishing calls.
The call state of the channel must be in the Null state. This is the initial call state of a line
device when it is first opened. This state is also reached when a call is released or after the
channel is reset by issuing the gc_ResetLineDev() function.
If the above conditions are met, the application is ready to make outbound calls.
3.4.2.3 Call Dialing
To initiate an outbound call using the asynchronous mode, the application issues a gc_MakeCall()
function that requests an outgoing call to be made on a specific line device. The gc_MakeCall( )
function returns immediately. and the call state transitions to the Dialing state. The
GCEV_DIALING event is generated (if enabled) to indicate that the call has transitioned to the
Dialing state. A CRN is assigned to the call being established on that line device. If the
gc_MakeCall( ) function fails, the line device remains in the Null state. In this state, dialing
information is sent to the remote side.
3.4.2.4 Call Proceeding
In the Dialing state, the remote side may indicate that all the information was received and the call
is proceeding. In this case, the GCEV_PROCEEDING event is generated and the call transitions to
the Proceeding state. The remote side may either accept or answer the call.
3.4.2.5 Call Alerting
If the remote end is not ready to answer the call, a GCEV_ALERTING event is generated. This
event indicates that the called party has accepted but not answered the call and that the network is
waiting for the called party to complete the connection. At this stage, the remote side is typically
ringing. This GCEV_ALERTING event changes the call state to the Alerting state.
3.4.2.6 Call Connected
When the called party immediately accepts the call, such as a call directed to a FAX or voice
messaging system, a GCEV_CONNECTED event is generated to indicate that the connection was