(Page 1 of 1 in this chapter) Version

Chapter 4

Basic Call Control

4.1 Introduction
4.2 Responding to Inbound Calls
4.2.1 Inbound Call Sequence
4.2.2 Seizure
4.2.3 Getting Call Address Information (Caller ID)
4.2.4 Overlapped Receiving of Digits
4.2.5 The Incoming Call State
4.2.6 Accepting Inbound Calls
4.2.7 Answering Inbound Calls
4.2.8 Rejecting Inbound Calls
4.2.9 Setting Billing
4.3 Establishing Outbound Calls
4.3.1 Outbound Call Sequence
4.3.2 Placing an Outbound Call
4.3.3 Call Control Mask Parameters (ADIMGR NCC Implementation)
4.3.4 Overlap Sending of Digits
4.3.5 The Placing Call State
4.3.6 The Proceeding Call State
4.3.7 Billing Indications
4.4 The Connected Call State
4.5 Disconnecting and Releasing a Call
4.5.1 Call Disconnection
4.5.2 Call Release

4.1 Introduction

This chapter describes the NCC service basic call control functions. These functions manage telephone network signaling, and the procedures required for establishing and maintaining calls.

There are two methods for establishing calls - answering inbound calls and placing outbound calls. In either case, the NCC service and the application exchange commands and events to advance to the call-connected state. Eventually, the NCC service and the application cooperatively release the call.

The NCC service basic call control functions manage:

The following NCC functions enable these services:

If you want to...

 Then use...

Accept an incoming call without answering or rejecting it

 nccAcceptCall

Answer an incoming call

 nccAnswerCall

Reject an incoming call

 nccRejectCall

Place an outbound call

 nccPlaceCall

Send address digits in overlapped sending mode

 nccSendDigits

Disconnect a call

 nccDisconnectCall

Release a call's resources and destroy the call handle

 nccReleaseCall

4.2 Responding to Inbound Calls

This section describes how to retrieve and process inbound calls offered by the telephone network. It also summarizes inbound call control functions and events.

4.2.1 Inbound Call Sequence

Once a protocol is started on a line context with nccStartProtocol, the protocol is eligible to receive incoming calls.

An inbound call is established in the following way:

  1. The telephone network offers the call. This causes a call state transition to the Seizure call state. CT Access generates an NCCEVN_SEIZURE_DETECTED event indicating transition to the Seizure call state. The call is assigned a call handle, to be used for all future activity with this call.

    

  2. The call is delivered from the network to the NCC service. This causes a call state transition to the Incoming call state. CT Access generates an NCCEVN_INCOMING_CALL event.
    

    
Depending upon the setting of the NCC.START.overlappedreceiving parameter, the transition to the Incoming call state may be preceded by an interval in which one or more digits (caller ID, etc.) are received from the network. For more information, see Section 4.2.4.
    

  3. The application decides whether to answer or reject the call, using the nccAnswerCall, or nccRejectCall functions. 
    

    
With some protocols, the application can accept a call immediately without answering or rejecting it, using the nccAcceptCall function. This allows the application to perform media functions (such as playing a voice file) before connecting (or rejecting) the call.
    
To help determine what to do with a call, the application may invoke nccGetCallStatus to retrieve the incoming address (caller ID) or other information. For more information, see Section 4.2.3.
    

  4. The NCC service performs network procedures to execute the application's decision, and returns appropriate events:
    

      

    • If the application does not respond to the NCCEVN_INCOMING_CALL 
event, the call is rejected.

      

      

    • If the application accepts the call, the NCC service generates 
NCCEVN_ACCEPTING_CALL. The event value field contains the 
acceptance method. The call state changes to Accepting. From this state, 
the application can answer or reject the call. (Note that this state may 
not be valid, depending upon the protocol.)

      

      

    • If the application answers the call, the NCC service generates 
NCCEVN_ANSWERING_CALL. The call state changes to Answering.

      

      

    • If the application rejects the call, the NCC service generates 
NCCEVN_REJECTING_CALL. The call state changes to Rejecting.

      

      

    • If the call is successfully established, the NCC service generates NCCEVN_CALL_CONNECTED. The call state changes to Connected.
      

      

    • If the connection is unsuccessful, or the application successfully rejected the call, the NCC service generates NCCEVN_CALL_DISCONNECTED. The call state changes to Disconnected. The application can then release the call with nccReleaseCall.
      

    


    Figure 4 contains two protocol timing sequence diagrams: one for answering an inbound call, and one for rejecting an inbound call. The diagrams depict the normal exchange of commands and events between the NCC service and the application. Optional events are shown with a dashed line.
    




    Figure 4.	 Inbound Call Sequence
    

    

    Figure 5 contains the same sequence diagrams as Figure 4, except the application accepts the call before answering or rejecting it:
    




    Figure 5.	 Inbound Call Sequence (Including nccAcceptCall)
    

    

    

    4.2.2	 Seizure
    

    


    When the line is first seized by the network, the NCC service delivers NCCEVN_SEIZURE_DETECTED to the application. The event contains a call handle to identify the call for subsequent call-based functions. 
    


    If this is the first call on the line, the line state changes from Idle to Active. The initial call state is Seizure.
    


    The application can retrieve the associated line handle (ctahd) by invoking nccGetCallStatus. (See Chapter 6.)
    

    

    

    4.2.3	 Getting Call Address Information (Caller ID)
    

    


    Most protocols support caller ID: the ability of the called party to determine the address (and sometimes other information) of the calling party. Often, the caller ID service is available from the telephone company on a subscription basis only.
    


    The application can call nccQueryCapability to determine if a protocol supports caller ID.
    


    The NCCEVN_INCOMING_CALL event indicates that the protocol has received all calling party information necessary to set up the call. To retrieve caller ID (and other information), invoke nccGetCallStatus with a call handle. Information is returned in the NCC_CALL_STATUS structure:
    

    typedef struct
{
 DWORD size;         /* No of bytes written to by callstatus    */
     DWORD state;        /* Current call state                      */
     char calledaddr [NCC_MAX_DIGITS+1]; /* Called number address   */
     char callingaddr[NCC_MAX_DIGITS+1]; /* Calling number address  */
     char callingname[NCC_MAX_CALLING_NAME]; /* Calling name info   */
     DWORD pendingcmd;   /* Last command not ack'ed by board        */
     DWORD held;         /* Non--zero value when call is held       */
     DWORD direction;    /* Indicates inbound or outbound call      */
     CTAHD linehd;       /* Line handle on which call resides       */
    } NCC_CALL_STATUS;    


    

    The structure contains the following fields: 

    


    
 Field 
    

    		
 Description
    


    
 size
    

    		
 Number of bytes written at the address pointed to by callstatus. 
    


    
 state
    

    		
 Current call state. Possible state values are:
    

 NCC_CALLSTATE_INVALID
    

 NCC_CALLSTATE_SEIZURE
    

 NCC_CALLSTATE_RECEIVING_DIGITS
    

 NCC_CALLSTATE_INCOMING
    

 NCC_CALLSTATE_ACCEPTING
    

 NCC_CALLSTATE_ANSWERING
    

 NCC_CALLSTATE_REJECTING
    

 NCC_CALLSTATE_CONNECTED
    

 NCC_CALLSTATE_DISCONNECTED
    

 NCC_CALLSTATE_OUTBOUND_INITIATED
    

 NCC_CALLSTATE_PLACING
    

 NCC_CALLSTATE_PROCEEDING
    


    
 calledaddr
    

    		
 (Inbound calls) The address of the requested number if provided (e.g., DNIS, DID).
    


    
 callingaddr
    

    		
 (Inbound calls) The address of the caller, if provided (e.g., caller ID, ANI).
    


    
 callingname
    

    		
 (Inbound calls) The name information of the caller, if provided.
    


    
 pendingcmd
    

    		
 The last call control command issued that has not yet been acknowledged by the AG board. This field is set when a call control command is sent to the board, and cleared on the next event that corresponds the acknowledgment of the pending command.
    

 Possible pendingcmd values are:
    

 (0) No command pending.
    

 NCC_PENDINGCMD_ACCEPT_CALL
    

 NCC_PENDINGCMD_ANSWER_CALL
    

 NCC_PENDINGCMD_AUTOMATIC_TRANSFER
    

 NCC_PENDINGCMD_DISCONNECT_CALL
    

 NCC_PENDINGCMD_HOLD_CALL
    

 NCC_PENDINGCMD_PLACE_CALL
    

 NCC_PENDINGCMD_REJECT_CALL
    

 NCC_PENDINGCMD_RETRIEVE_CALL
    

 NCC_PENDINGCMD_SET_BILLING
    

 NCC_PENDINGCMD_TRANSFER_CALL
    

 NCC_PENDINGCMD_RELEASE_CALL
    


    
 held
    

    		
 Set to non-zero value when a call is held.
    


    
 direction
    

    		
 Indicates inbound or outbound call. Possible values:
    

 NCC_CALL_INBOUND
    

 NCC_CALL_OUTBOUND
    


    
 linehd
    

    		
 Line (context) handle on which the call resides.
    



    


    

    

    

    


    Because the data is stored in this structure on a call-by-call basis, applications must analyze the call status of every incoming call to retrieve call information.
    


    Protocol-specific parameters determine how many digits to receive, how to interpret incoming digits, etc. For details, see your protocol documentation.
    

    

    

    4.2.4	 Overlapped Receiving of Digits
    

    


    Some protocols support overlapped receiving of digits: the application receives an event as each digit comes in. The application can examine each digit to determine  what to do with the call earlier in the call setup process.
    


    The NCC.START.overlappedreceiving parameter in the NCC_START_PARMS structure (referenced in the initial invocation of nccStartProtocol) determines whether the protocol will accept digits in overlapped receiving mode or not.
    


    If the protocol will accept digits in this mode, the application may receive NCCEVN_RECEIVED_DIGIT while the protocol is in the Seizure state. The event value field contains a digit received from the network. At this point, the protocol enters the Receiving Digits call state. It remains in this state until all digits have been received. As each digit is received, a new NCCEVN_RECEIVED_DIGIT is generated with the digit. Receipt of NCCEVN_INCOMING_CALL indicates that all digits have been received, and the protocol has entered Incoming call state. The complete set of digits is then available in the NCC_CALL_STATUS structure.
    


    The application can accept, answer, or reject the call at any time (with nccAcceptCall, nccAnswerCall, or nccRejectCall) while receiving digits. 
    

    

    

    4.2.5	 The Incoming Call State
    

    


    Receipt of the NCCEVN_INCOMING_CALL event indicates that the incoming call has been detected by NCC, and all necessary call information has been gathered. The call is in the Incoming call state.
    


    At this point, the application decides whether to accept, answer or reject the call (with nccAcceptCall, nccAnswerCall or nccRejectCall). The application can also choose to ignore the call completely. If the call is ignored for a certain interval, the call is automatically rejected. (The NCC.START.waitforPCtime parameter determines this interval.)
    

    

    

    4.2.6	 Accepting Inbound Calls
    

    


    Once the call is in the Incoming or Receiving Digits call states (NCCEVN_INCOMING_CALL or NCCEVN_RECEIVED_DIGIT has been received), the application can accept the call without committing to answer it, by invoking nccAcceptCall. This places the call in the Accepting call state, where it has been accepted, but has been neither answered nor rejected. This state allows applications to perform media functions (such as playing a voice file) before connecting the call. 
    

Note:  Not all protocols support the nccAcceptCall function and Accepting call state. The application can call nccQueryCapability to determine whether the protocol supports this capability.


    With most protocols, arguments passed to nccAcceptCall can cause a ring tone or user audio to be played when the call enters the state. (The application can call nccQueryCapability to determine if the protocol supports these arguments.) The acceptance method to use is specified in the method argument in the function call. Here is a list of valid values: 

    


    
 Method
    

    		
 Action
    


    
 NCC_ACCEPT_PLAY_RING
    

    		
 Play ring tone.
    


    
 NCC_ACCEPT_PLAY_SILENT
    

    		
 Play nothing.
    


    
 NCC_ACCEPT_USER_AUDIO
    

    		
 Allow the application to generate tones and perform voice playback functions.
    



    


    

    

    

    


    When the call enters the Accepting state, the application receives an NCCEVN_ACCEPTING_CALL event. The event value field contains the acceptance method. The call will remain in the Accepting state until the application invokes nccAnswerCall or nccRejectCall. Receipt of NCCEVN_ANSWERING_CALL or NCCEVN_REJECTING_CALL indicates that the call has been answered or rejected, or that the telephone network has timed out. The call is no longer in the Accepting Call state.
    


    The application may receive NCCEVN_CALL_DISCONNECTED while the call is in the Accepting Call state. This event indicates that the remote party has hung up. The event value field contains the reason. The application should then invoke nccReleaseCall to release the call.
    


    If the remote party disconnects while the application is accepting the call, the application receives an NCCEVN_CALL_DISCONNECTED event. In this case, NCCEVN_ACCEPTING_CALL will not be delivered.
    

    

    

    4.2.7	 Answering Inbound Calls
    

    


    To answer a call, an application invokes nccAnswerCall. You can specify a number of ring tones for nccAnswerCall to play before answering the call.
    

Note:  Any ring tones generated prior to calling nccAnswerCall do not count towards the number of ring tones specified with nccAnswerCall.


    When a nccAnswerCall is invoked, the application receives NCCEVN_ANSWERING_CALL. The call is now in the Answering call state. The call remains in this state while the NCC service attempts to answer the call and establish a connection. Subsequent receipt of NCCEVN_CALL_CONNECTED means that the call connection attempt was successful, and the call is now in the Connected state. NCCEVN_CALL_DISCONNECTED indicates that the call answering attempt was unsuccessful, and the call is in the Disconnected state.
    


    If the remote party disconnects while the application is answering the call, the application receives NCCEVN_CALL_DISCONNECTED. In this case, NCCEVN_ANSWERING_CALL will not be delivered.
    

    

    

    4.2.8	 Rejecting Inbound Calls
    

    


    To reject a call, an application invokes nccRejectCall. With most protocols, the application can also specify a method to be used to reject the call. The following is a list of valid methods: 

    


    
 Method
    

    		
 Description
    


    
 NCC_REJECT_PLAY_RINGTONE
    

    		
 Play a ring tone until the remote party disconnects.
    


    
 NCC_REJECT_PLAY_BUSY
    

    		
 Send a backward tone or signal to indicate that the call is busy.
    


    
 NCC_REJECT_PLAY_REORDER
    

    		
 Send a reorder tone. Reorder usually means that the number is incorrectly formatted, or is not allocated.
    


    
 NCC_REJECT_USER_AUDIO
    

    		
 The application generates a recorded message, or a Special Information Tone. If the remote party hangs up, the protocol interrupts the application tone or voice file.
    



    


    

    

    

    


    When a nccRejectCall is invoked, the application receives NCCEVN_REJECTING_CALL. The call is now in the Rejecting call state. The call remains in this state while the NCC service attempts to reject the call. Subsequent receipt of NCCEVN_CALL_DISCONNECTED indicates that the call rejection was successful. The application should now invoke nccReleaseCall to release the call.
    


    If the remote party disconnects while the application rejects the call, the application receives an NCCEVN_CALL_DISCONNECTED event. In this case, NCCEVN_REJECTING_CALL will not be delivered.
    

    

    

    4.2.9	 Setting Billing
    

    


    In any incoming call state, the application can invoke nccSetBilling to set the billing information relative to the incoming call. The event NCCEVN_BILLING_SET indicates that the billing information was successfully sent to the network. The value field contains the billing rate setting.
    


    Billing setting is not supported by all protocols. NCC_CAP_SET_BILLING in the capabilitymask returned by nccQueryCapability indicates if the current protocol supports the ability to set the billing for a call.
    

    

    

    4.3	 Establishing Outbound Calls
    

    


    This section describes how an application places calls, and describes the functions and events associated with the outbound call process.
    

    

    

    4.3.1	 Outbound Call Sequence
    

    


    Once a protocol is started on a line context with nccStartProtocol, the application can place outbound calls. An outbound call is established in the following way:
    

      


    1. The application invokes nccPlaceCall.
      

      
When this occurs, the call enters Outbound Initiated call state.
      

    2. The protocol checks whether a call collision (glare) situation exists for this call (i.e., on two-way trunks, the outgoing call is colliding with an incoming call on the same line). 
      

      
If glare exists, the call is released and NCCEVN_CALL_RELEASED is returned to the application. Otherwise:
      

    3. The protocol seizes the line, creates a call handle for the call, and generates an NCCEVN_PLACING_CALL event. 
      

      
When this event occurs, the line changes to Active line state. The call enters Placing call state.
      

    4. NCC initiates dialing, using the string specified with nccPlaceCall.
      

      
If the protocol supports overlap sending of digits, the application can send additional digits and characters using the nccSendDigits function. (The NCC_CAP_OVERLAPPED_SENDING bit in the capabilitymask returned by nccQueryCapability indicates if the protocol supports this feature.)
      

    5. When the switch has accepted the call setup request and is in the process of attempting to ring the receiving end, NCCEVN_CALL_PROCEEDING is returned to the application. The call is now in the Proceeding call state. Call progress analysis has begun.
      

      

    6. When the protocol senses that the remote party is alerting (e.g., ringing), NCCEVN_REMOTE_ALERTING is returned to the application. When the protocol senses that the remote party is answering the call, NCCEVN_REMOTE_ANSWERED is returned to the application.
      

      
Note:  NCCEVN_REMOTE_ALERTING is generated only if the NCC_REPORT_ALERTING bit is set in the NCC.START.eventmask parameter. NCCEVN_REMOTE_ANSWERED is generated only if the NCC_REPORT_ANSWERED bit is set. For details, see Appendix D. 


    7. If a network connection is established, NCC generates an NCCEVN_CALL_CONNECTED or NCCEVN_CALL_DISCONNECTED event depending upon protocol-specific connectmask and disconnectmask parameters.
      

    


    Figure 6 is a sequence diagram depicting the command and event interchange for placing an outbound call. Optional events are shown with a dashed line.
    




    Figure 6.	 Outbound Call Sequence
    

    

    

    4.3.2	 Placing an Outbound Call
    

    


    To place an outbound call, the application invokes nccPlaceCall. Included with this function call is a variety of information, including:
    

    

    Depending on the protocol, the addresses can be phone number digit strings, IP addresses, or endpoint names. This information can be sent all at once, or, if the protocol supports overlap sending, part of the information can be sent with nccPlaceCall, and more can be sent later using nccSendDigits, when the call reaches the Placing call state (see Section 4.3.4).
    


    Invocation of nccPlaceCall changes the call state to Outbound Initiated. The call remains in the state until NCCEVN_PLACING_CALL occurs, indicating that the line is seized and glare is resolved.
    


    If the application receives NCCEVN_CALL_RELEASED (with an NCC_RELEASED_GLARE reason code) instead of NCCEVN_PLACING_CALL, the line was seized for an incoming call before glare was resolved, and the protocol has released the outgoing call. The application should immediately abandon outbound call placement and handle the incoming call, when the NCCEVN_SEIZURE_DETECTED event for the new call arrives.
    

    

    

    4.3.3	 Call Control Mask Parameters (ADIMGR NCC Implementation)
    

    


    This section describes the call control connectmask and disconnectmask parameters in the NCC_X_ADI_PLACECALL_PARMS structure. These parameters provide the criteria according to which the NCC service decides to connect or disconnect a successfully placed call. These criteria are protocol-specific. The NCC_X_ADI_PLACECALL_PARMS structure is passed to the NCC service when the call is placed with nccPlaceCall.
    

Note:  Different implementations of NCC may provide this functionality in other ways. This section describes how this functionality is provided in the ADIMGR NCC implementation.


    For more information about the connectmask or disconnectmask for the protocol you are using, see your protocol-specific documentation.
    

    

    

     Connectmask
    

    


    The NCC_X_ADI_PLACECALL_PARMS connectmask dictates which call progress analysis event causes the NCC service to change the call state from Proceeding to Connected.
    


    Each of the bits in the connectmask parameter represents a particular condition. If the bit is enabled (set) and the condition described occurs, the call is connected. When the call is connected, the NCC service generates an NCCEVN_CALL_CONNECTED event. The event's value field indicates the reason for the transition to the Connected call state.
    

    

    

     Disconnectmask
    

    


    The NCC_X_ADI_PLACECALL_PARMS disconnectmask parameter dictates which call progress analysis events cause the NCC service to change the call state from  Proceeding to Disconnected.
    


    Each of the bits in the disconnectmask parameter represents a particular condition. If the bit is enabled (set) and the condition described occurs, the NCCEVN_CALL_DISCONNECTED event is generated.
    

Note:  The connectmask takes precedence. If a condition is selected in both the connectmask and disconnectmask, a call will be connected if that condition occurs.

    

    

    4.3.4	 Overlap Sending of Digits
    

    


    Some signaling protocols (ISDN for example) support overlap sending of digits: the sending of address information in multiple bursts, rather than all at once. The application can call nccQueryCapability to determine if the protocol supports this feature. 
    


    The application supplies the first digit or digits when invoking nccPlaceCall.  When the application enters the Placing call state (see Section 4.3.5), it invokes the nccSendDigits function repeatedly to send additional segments of the digit string, in order. If the digit string sent by an invocation of either function is not the final one, the final character in the string should be a "~". This signifies to the protocol that more digits will follow. The final digit string should not include the final "~" character. (See Figure 7.)
    

   nccPlaceCall   172~
      nccSendDigits   57924~
      nccSendDigits   5~
      nccSendDigits   28
    

   Final digit string: 17257924528
    


    Figure 7.	 Overlap Sending of Digits
    

    

    

    4.3.5	 The Placing Call State
    

    


    If the application receives NCCEVN_PLACING_CALL while the call is in the Outbound Initiated call state, the protocol has successfully seized the line and resolved glare. The call advances to the Placing call state. The call remains in this state until an event occurs indicating a state change:
    

    

    If the protocol supports overlap sending of digits, the application should send the remaining digit strings (using nccSendDigits) while the call is in the Placing call state. For more information, see Section 4.3.4.
    

    

    

    4.3.6	 The Proceeding Call State
    

    


    When the switch has accepted the call set up request, and is in the process of attempting to ring the receiving end, the application receives NCCEVN_CALL_PROCEEDING. Call progress analysis is begun. The call state changes to Proceeding.
    


    If the call meets other connection criteria specified in this mask, the application receives NCCEVN_CALL_CONNECTED, and the call enters the Connected call state. If the call does not meet the connection criteria or meets the disconnectmask criteria, the application receives NCCEVN_CALL_DISCONNECTED, and the call proceeds to the Disconnected call state. In either case, the event's value field contains the reason for connection or disconnection.
    


    The application may receive NCCEVN_BILLING_INDICATION while in the Proceeding call state. This event indicates that a billing indication has arrived. Depending upon the protocol, this indication may be a billing pulse or some more complex indication (ISDN, SS7). In some cases, the value field of this event contains the billing units charged. No state transition occurs with this event. (The application can invoke nccQueryCapability to determine if the protocol supports billing indications.)
    


    The NCC.START.eventmask parameter (see Appendix D) controls whether two other events appear during the Proceeding call state:
    

    

    NCCEVN_REMOTE_ALERTING is generated only if the NCC_REPORT_ALERTING bit is set in the NCC.START.eventmask parameter. NCCEVN_REMOTE_ANSWERED is generated only if the NCC_REPORT_ANSWERED bit is set. For details, see Appendix D. 
    

    

    

    4.3.7	 Billing Indications
    

    


    In any outbound call state, the application may receive an NCCEVN_BILLING_INDICATION event. This event indicates that a billing indication has arrived. Depending upon the protocol, this indication may be a billing pulse or some more complex indication (ISDN, SS7). In some cases, the value field of this event contains the billing units charged. No state transition occurs with this event.
    


    NCCEVN_BILLING_INDICATION is generated only if the NCC_REPORT_BILLING bit is set in the NCC.START.eventmask parameter. 
    

    

    

    4.4	 The Connected Call State
    

    


    In the Connected call state, a connection exists between the calling parties. The application may now invoke other telephony services suitable for completing its tasks (e.g., DTMF, MF, playing/recording, etc.) until a disconnect occurs. The application can also transfer the call (see Section 5.3).
    


    The call reaches the Connected call state when either of the following occurs:
    

    

    When the call reaches the Connected call state, NCCEVN_CALL_CONNECTED is returned to the application. The event value field contains the reason for connection. The call remains in this state until the application calls a function that changes the state, or receives an event indicating a state change.
    


    The application may receive NCCEVN_BILLING_INDICATION while in the  Connected call state. This event indicates that a billing indication has arrived. Depending upon the protocol, this indication may be a billing pulse or some more complex indication (ISDN, SS7). In some cases, the value field of this event contains the billing units charged. No state transition occurs with this event. (The application can call nccQueryCapability to determine if the protocol supports billing indications.)
    


    The NCC.START.eventmask bit (see Appendix D) controls whether two other events appear during the Connected call state. These events are only relevant if the call is outbound, the NCC_CON_ON_CALL_PROCEEDING bit is set in the NCC_PLACECALL_PARMS connectmask passed with nccPlaceCall, and the remote end has not yet answered:
    

    

    

    4.5	 Disconnecting and Releasing a Call
    

    


    When a call is torn down, it passes through two stages:
    

    

    The following sections describe how a call is disconnected and released. 
    

    

    

    4.5.1	 Call Disconnection
    

    


    A call can be disconnected in any of the following ways:
    

    

    After the call is disconnected, the NCC service generates NCCEVN_CALL_DISCONNECTED. The call is now in the Disconnected state. It is no longer active.
    


    In this state, no connection exists between the local party and remote party. However, the call still exists logically; for example, the application can still invoke nccGetCallStatus to get information about the call, or send protocol-specific call messages with nccSendCallMessage. With some protocols, the call can still be placed on hold (the application can invoke nccQueryCapability to determine if the protocol supports this feature).
    

    

    

    4.5.2	 Call Release
    

    


    Once a call is in the Disconnected state, the application can invoke nccReleaseCall to release resources associated with the call, and destroy the call handle. The call no longer exists in any state.
    


    When the call is released, NCCEVN_CALL_RELEASED is passed to the application. All internal resources allocated to the call are released. After the application receives this event, no more DSP-related events will be generated for this call handle. Also, the application can no longer retrieve call status information using nccGetCallStatus or nccGetExtendedCallStatus.
    


    An outbound call may also be released if a glare (call collision) situation is detected while the call is in Outbound Initiated call state. In this case, the event value field will contain NCC_RELEASED_GLARE.
    


    If no other calls exist on the line after a call is released, the line state falls back to Idle.
    

    

    


    
 
    (Page 1 of 1 in this chapter)  Version
    


    
 



    
tech_support@nmss.com

    

Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.