(Page 1 of 1 in this chapter)

Chapter 7

Performing Digital CAS Call Control

7.1 Introduction
7.2 Responding to Inbound Calls
7.2.1 Inbound Call Sequence and Events
7.2.2 Retrieving Incoming Digits
7.2.3 Accepting Inbound Calls
7.2.4 Answering Inbound Calls
7.2.5 Rejecting Inbound Calls
7.3 Placing Outbound Calls
7.3.1 Initiating an Outbound Call
7.4 The ADI_CALL_STATUS Structure
7.5 Blocking and Unblocking Calls
7.5.1 Blocking Calls
7.5.2 Unblocking Calls
7.6 Gateway Application Call Control
7.6.1 Accepting Calls
7.6.2 Rejecting Calls

7.1 Introduction

This chapter describes how to:

7.2 Responding to Inbound Calls

This section describes how to accept, answer, reject, and retrieve digits from inbound calls. It also provides a summary of inbound call control functions and events.

Note: Certain protocol behavior is determined by parameters loaded from the TCP's country-specific parameter file. Refer to Section 5.2 for instructions about loading parameter files, or to Appendix C for a complete list of editable parameters for each TCP.

7.2.1 Inbound Call Sequence and Events

Once a TCP is started on a CTA context with adiStartProtocol, the TCP is eligible to receive incoming calls. The network offers the call and then the application takes one of the following actions:

Figure 2 provides sequence diagrams for answering inbound calls, and for rejecting inbound calls. The diagrams show the normal exchange of commands and events between the API and application. Informational events are shown as dashed lines (adiAcceptCall is optional).

Figure 2. Inbound Call Sequence Diagram



After the TCP detects an incoming call, CT Access generates these events: 





 Event



 Description




 ADIEVN_SEIZURE_DETECTED



 The line has been seized by an external entity for an incoming call, and the call setup process has begun (only appears if enabled).




 ADIEVN_INCOMING_DIGIT



 A single digit has been received. This event is returned after each digit is received only if the TCP is set up to report incoming digits individually as they arrive (as described in Section 7.2.2). The digit appears in the value field of the event.




 ADIEVN_INCOMING_CALL



 The TCP has handled the setup of an incoming call. The TCP then waits for the application to decide if the call should be answered or rejected.
















Figure 3 shows the ADI service state diagram for receiving inbound calls. For more information about ADI service call control, refer to the ADI Service Developer's Manual.


 



Figure 3.	 Inbound Call State Machine






7.2.2	 Retrieving Incoming Digits





Applications can retrieve incoming digits in two ways:




Refer to the following sections for more information about retrieving digits.


 


 Retrieving All Digits at Once



Once the ADIEVN_INCOMING_CALL event is received, incoming digits are available on the digit queue. The application can call adiGetCallStatus to retrieve these digits. 



The received digits are stored in the ADI_CALL_STATUS data structure shown below: 


#define ADI_MAX_DIGITS 31
#define ADI_MAX_CNAME 31
typedef struct
{                              /* Used by adiGetCallStatus                */
    DWORD size ;               /* Size returned by adiGetCallStatus       */
    DWORD state;               /* Call states(ADI_CC_STATE_xxx below)     */
    INT32 reason;              /* Reason of going back to IDLE state      */
    char  calledaddr [ADI_MAX_DIGITS+1]; /* DNIS info(null term string)   */
    char  callingaddr[ADI_MAX_DIGITS+1]; /* ANI info (null term string)   */
    char  callingname[ADI_MAX_CNAME+1];  /* Calling party name            */
    DWORD pendingcommand;     /* Current unack'ed command (see above)     */
    char  usercategory;       /* The type of the calling party            */
    char  tollcategory;       /* (generally the same as usercategory)     */
    BYTE  stream;             /* MVIP address of B channel                */
    BYTE  timeslot;           /* MVIP address of B channel                */
    
    WORD  billingrate;         /* billing rate of call                      */
    char  callednumplan;        /* Q.931 numbering plan ID if supported      */
    char  callednumtype;        /* Q.931 number type if supported            */
    char  callingnumplan;        /* Q.931 numbering plan ID if supported      */
    char  callingnumtype;        /* Q.931 number type if supported            */
    char  callingpres;        /* Caller ID presentation indicator          */
    char  callingscreen;         /* Q.931 ANI screening indicator             */
    char  progressdescr;         /* progress descriptor                       */
    char  releasecause;         /* Cause for call release                    */
    char  redirectingaddr[ADI_MAX_DIGITS+1];  /* redirecting number info  */
    char  redirectingplan;        /* Q.931 numbering plan ID if supported      */
    char  redirectingtype;        /* Q.931 number type if supported            */
    char  redirectingpres;         /* redirecting number pres. indicator       */
    char  redirectingscreen;        /* Q.931 redirecting number screen ind.    */
    char  redirectingreason;        /* Q.931 reason for redirection            */
    char  originalcalledaddr [ADI_MAX_DIGITS+1]; /* *for future use*      */
    char  UUI[132];         /*   user to user information                */
} ADI_CALL_STATUS;









7.2.3	 Accepting Inbound Calls 





An application can accept an inbound call without committing to answer the call, by calling adiAcceptCall. In response to this function, the TCP accepts the call by sending a specific tone or digital signal to the network. It also performs the media operations requested with adiAcceptCall. No further action is taken until the application calls adiAnswerCall or adiRejectCall, or the remote party disconnects. 



The function call specifies what the TCP should do while accepting the call. The following actions are available:




The following events are associated with adiAcceptCall:


  





 Event



 Description




 ADIEVN_ACCEPTING_CALL



 The TCP has accepted the call, and is waiting for further instructions from the application.




 ADIEVN_CALL_DISCONNECTED



 The remote party hung up while the ring tone was being sent.




 ADIEVN_REJECTING_CALL



 The application called adiAnswerCall at the same time as the protocol's timer to wait for this command to arrive expired. This timer has typically a value of several seconds, but the application can sometimes take that long to process an incoming call event in loaded systems. The event value field contains ADI_REJ_HOST_TIMEOUT. The call is automatically rejected, and a busy tone is played. (The timeout and default tone used are governed by parameters).



















7.2.4	 Answering Inbound Calls





To answer calls, applications use adiAnswerCall. You can specify a number of ring tones for adiAnswerCall to play before answering the call.



The following events are associated with adiAnswerCall:


  





 Event



 Description




 ADIEVN_ANSWERING_CALL



 The TCP is answering.




 ADIEVN_CALL_CONNECTED



 The telephone network connection is established.




 ADIEVN_CALL_DISCONNECTED



 The remote party hung up while the ring tone was being sent.




 ADIEVN_REJECTING_CALL



 The application called adiAnswerCall at the same time as the protocol's timer to wait for this command to arrive expired. This timer has typically a value of several seconds, but the application can sometimes take that long to process an incoming call event in loaded systems. The event value field contains ADI_REJ_HOST_TIMEOUT. The call is automatically rejected, and a busy tone is played. (The timeout and default tone used are governed by parameters).















 






7.2.5	 Rejecting Inbound Calls





To reject the call, applications use adiRejectCall. You can specify any of the following methods with adiRejectCall for digital CAS TCPs:


  





 Method



 Description




 ADI_REJ_PLAY_BUSY



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




 ADI_REJ_PLAY_REORDER



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




 ADI_REJ_USER_AUDIO



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




 ADI_REJ_PLAY_RINGTONE



 Plays a ring tone until the remote party disconnects.
















adiRejectCall returns the following events:


  





 Event



 Description




 ADIEVN_REJECTING_CALL



 Acknowledges that adiRejectCall has been issued. A busy or reorder tone is sent, and the TCP waits for the calling side to clear forward (hang up). In this case the event value field contains the rejection method.


 This may also mean that the application has failed to invoke either adiAnswerCall or adiRejectCall within the period specified in the protocol's parameters. In this case the event value field contains ADI_REJ_HOST_TIMEOUT and the call is automatically rejected.




 ADIEVN_CALL_DISCONNECTED



 The calling side hung up, or the remote party disconnected while the application was rejecting the call (in the second case ADIEVN_REJECTING_CALL is not returned). The value field contains the reason ADI_DIS_REMOTE_ABANDONED.






















7.3	 Placing Outbound Calls





This section describes how a typical CAS protocol call control application places calls and describes the functions and events associated with the outbound call process.


Note:  Certain protocol behavior is determined by parameters loaded from the TCP's country-specific parameter file. Refer to Section 5.2, Loading Country-Specific Parameters for instructions about loading parameter files, or to Appendix C for a complete list of editable parameters for each TCP.


Once a TCP is started on the CTA context with adiStartProtocol, the application can place outgoing calls. Outbound calls are established as follows:


    


  1. The application invokes adiPlaceCall.
    

    

  2. The TCP seizes the line and generates a ADIEVN_PLACING_CALL event. This event guarantees that call collision will not occur for this call.
    

    

  3. The TCP performs all operations necessary for call setup, dialing the requested number.
    

    

  4. If the call request is rejected by the network, the TCP abandons call placement and returns ADIEVN_CALL_DISCONNECTED indicating the reason for the rejection in the value field.
    

    

  5. If a network connection is established, CT Access generates a ADIEVN_CALL_CONNECTED or ADIEVN_CALL_DISCONNECTED event depending upon the events received in conjunction with the call connectmask and disconnectmask parameters set by the application in the ADI_PLACECALL_PARMS structure.
    

    
 
    




Figure 4 shows an ADI service state diagram for placing outbound calls. This diagram, combined with the sequence diagram in Figure 5, provides a comprehensive reference of the outbound call states and events described in the following section. For more information about ADI service call control, refer to the ADI Service Developer's Manual.


 



Figure 4.	 Outbound Call State Machine



 




Figure 5 is a sequence diagram depicting, at several levels, the command and event interchange for placing an outbound call. 


Note:  Depending on the eventmask and connectmask values, some of these intermediate messages may not occur, or may occur in a different order than shown here.

 



Figure 5.	 Placing Outbound Calls






7.3.1	 Initiating an Outbound Call





To initiate an outbound call, the application calls adiPlaceCall. This function tells the TCP to deliver a digit string to the network switch. The function arguments include a pointer to an ADI_PLACECALL_PARMS structure (set the pointer to NULL to use default parameter values). This structure includes the call control connectmask and disconnectmask parameters, which determine under what conditions the TCP will connect or abandon a call. (For more information about call control connectmask and disconnectmask parameters, see the ADI Service Developer's Manual.)



For information about the string formatting expected by each TCP, refer to Appendix C.


 Call Set Up Events



The following events are returned while the call is being set up:


  





 Event



 Description




 ADIEVN_PLACING_CALL



 This event is generated after the TCP has seized the trunk, and an acknowledgment has been received from the network. (This implies that glare has been resolved and call collision will not occur.)




 ADIEVN_CALL_PROCEEDING



 All of the dialed digits have been offered to the telephone network (all of the digits have been dialed and, if necessary, acknowledged by the remote party).


 This is a low-level event enabled only if the ADI_CC_REPTPROCEEDING bit is set in the ADI_CALLCTRL_PARMS eventmask passed to adiStartProtocol (see the source code of inoutcta.c for an example).




 ADIEVN_REMOTE_ALERTING



 The remote party is ringing.


 This is a low-level event enabled only if the ADI_CC_REPTALERTING bit is set in the ADI_CALLCTRL_PARMS eventmask passed to adiStartProtocol (see the source code of inoutcta.c for an example).




 ADIEVN_REMOTE_ANSWERED



 The remote party has answered. If the application is performing call progress detection, this indicates voice. If call progress detection is not enabled, this indicates signal.


 This is a low-level event enabled only if the ADI_CC_REPTANSWERED bit is set in the ADI_CALLCTRL_PARMS eventmask passed to adiStartProtocol (see the source code of inoutcta.c for an example).




 ADIEVN_CALL_CONNECTED



 The call has reached a stage that satisfies the connectmask requirements set in the ADIPLACECALL_PARMS structure.




 ADIEVN_STATUSINFO_UPDATE



 If enabled and protocol supports billing information transmission.




 ADIEVN_CALL_DISCONNECTED



 This event indicates that the call is disconnected, for one of the following reasons:


·	 A clear-back event has been received from the network


·	 A busy, reorder, ring-no-answer, or Special Information Tone (SIT) has been detected


·	 The call fits the disconnection criteria specified in the disconnectmask parameter in the ADI_PLACECALL_PARMS structure. The event value field contains the condition that fit the disconnection criteria. (For more information about the connectmask and disconnectmask parameters, see the ADI Service Developer's Manual.)















Note:  Different TCPs expect the digit string to be formatted in different ways. If the PSTN requires ANI digits, the application must insert separators symbols (#) to signify ANI digits from DID digits. Refer to Appendix C for more information about digit string formatting according to protocol. 

 






7.4	 The ADI_CALL_STATUS Structure





When applications retrieve incoming call information, the received information is stored in the ADI_CALL_STATUS data structure shown below: 


#define ADI_MAX_DIGITS 31
#define ADI_MAX_CNAME 31
typedef struct
{           /* Used by adiGetCallStatus                    */
  DWORD size ;        /* Size returned by adiGetCallStatus   */
  DWORD state;         /* Call states(ADI_CC_STATE_xxx below) */ 
  INT32 reason;        /* Reason for returning to IDLE state  */
  char  calledaddr [ADI_MAX_DIGITS+1]; 
          /* DNIS info (null term string                */
  char  callingaddr[ADI_MAX_DIGITS+1]; 
          /* ANI info (null term string)                */
  char  callingname[ADI_MAX_CNAME+1];  
          /* Calling party name                                 */
  DWORD pendingcommand ;        /* Current unack'ed command(see above)*/
  char  usercategory;        /* The type of the calling party            */
  char  tollcategory;         /* (generally the same as usercategory*/
  BYTE  stream;         /* MVIP address of B channel                     */
  BYTE  timeslot;         /* MVIP address of B channel                    */
  WORD  billingrate;         /* billing rate of call                              */
  char  callednumplan;        /* Numbering plan ID if supported          */
  char  callednumtype;        /* Number type if supported                      */
  char  callingnumplan;        /* Numbering plan ID if supported          */
  char  callingnumtype;        /* Number type if supported                      */
  char  callingpres;        /* Caller ID presentation indicator      */
  char  callingscreen;         /* ANI screening indicator                        */
  char  progressdescr;         /* Progress descriptor                                */
  char  releasecause;         /* Cause for call release                          */
  char  redirectingaddr[ADI_MAX_DIGITS+1]; 
          /* Redirecting number info                        */
  char  redirectingplan;        /* Numbering plan ID if supported          */
  char  redirectingtype;        /* Number type if supported                      */
  char  redirectingpres;         /* Redirecting number pres. indicator  */
  char  redirectingscreen;        /* Redirecting number screen ind.          */
  char  redirectingreason;        /* Reason for redirection                          */
  char  originalcalledaddr [ADI_MAX_DIGITS+1];
          /* Original called number                          */
  char  origcalledplan;        /* Numbering plan ID if supported          */
  char  origcalledtype;        /* Number type if supported                      */
  char  origcalledpres;        /* Orig. called number pres. indicator*/
  char  origcalledscreen;        /* Redirecting number screen ind.          */
  char  origcalledreason;        /* Reason for redirection                          */                                                        char  UUI[132];           /* User to user information                      */
} ADI_CALL_STATUS;

 




The ADI_CALL_STATUS structure contains the following fields: 





 Field



 Protocols that use the field



 Description






size





 all



 Number of bytes written at the address pointed to by the status argument in adiGetCallStatus.






state





 all



 Current ADI call control state (refer to the ADI Service Developer's Manual for more details about call control).






reason





 all



 ADI service specific reason for the last disconnect. This will be zero if the application initiated the disconnect. Otherwise, it is the value received in the event ADIEVN_DISCONNECTED.






calledaddr





 all



 For inbound calls, the called party address. Refer to Appendix B and Appendix C for TCP-specific formats.






callingaddr





 MFC


 EAM



 R15


 ISDN



 For inbound calls, the calling party address - the Automatic Number Identification (ANI) digits, or Caller ID. 






callingname





 Calling party name, if supported.






pendingcommand





 all



 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 causes a transition to a new call state.


 Possible values include:


 Value    Description


    0         No command pending.


    1        ADI_PENDCMD_PLACE_CALL


    2        ADI_PENDCMD_ANSWER_CALL


    3        ADI_PENDCMD_REJECT_CALL


    4        ADI_PENDCMD_RELEASE_CALL


    5        ADI_PENDCMD_TRANSFER_CALL


    6        ADI_PENDCMD_PLACE_SECOND


    7        ADI_PENDCMD_RELEASE_SECOND






usercategory





 MFC


 EAM


 R15



 Either the type of the calling party (e.g normal subscriber, operator, pay phone, etc.), or the type of call (protocol-specific).






tollcategory





 MFC


 EAM



 Generally the same as usercategory, if supported; it might be different for certain countries using the MFC-R2 protocol.






stream





 ISDN



 An MVIP-90 stream for AG-T1/E1boards, and an MVIP-95 stream for AG Quad T1/E1 boards.






timeslot





 ISDN



 This field and stream together indicate the MVIP address of the B channel for an ISDN call. 






billingrate





 MFC


 EAM



 Indication if the current call is billed or free (for CAS protocols, the actual cost of an outbound call is calculated by counting billing pulses, if the network offers this service).






callednumplan





 ISDN



 Numbering plan ID of called address. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x0       unknown numbering plan


 0x1       ISDN/telephony numbering plan


 0x3       data numbering plan


 0x4       telex numbering plan


 0x8       national standard numbering plan


 0x9       private numbering plan






callingnumtype





 ISDN



 Numbering type of calling address. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x0       unknown


 0x1       international number


 0x2        national number


 0x3       network-specific number


 0x4      subscriber number


 0x6       abbreviated number






callingpres





 ISDN


 MFC 


 EAM



 Caller ID (or ANI) presentation indicator. Possible values are those stated in ITU's Q.931 recommendation (borrowed by non-ISDN protocols):


 Value    Description


 0x0        presentation allowed


 0x1        presentation restricted


 0x2        calling number not available due to interworking






callingscreen





 ISDN



 ANI screening indicator. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x0   calling number user-provided, not screened


 0x1      calling number user-provided, verified and
              passed


 0x2       calling number user-provided, verified and
              failed


 0x3       network provided 




 progressdescr



 ISDN



 Progress descriptor. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x1       call not end-to-end ISDN, call progress information may be available in-band


 0x2       destination address is non-ISDN


 0x3       origination address is non-ISDN


 0x4       call has returned to ISDN


 0x8       in-band call progress information available




 releasecause



 ISDN



 Cause for call release. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x1     call forwarding busy or DTE busy


 0x2      call forwarding no reply


 0x9     called DTE out of order


 0xf     call forwarding unconditional or systematic
              call redirection


 0xa     call forwarding by called DTE






redirectingaddress





 ISDN



 Redirecting number information (if the call has been redirected from another terminal).






redirectingplan





 ISDN



 Numbering plan ID. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x0       unknown numbering plan


 0x1       ISDN/telephony numbering plan


 0x3       data numbering plan


 0x4       telex numbering plan


 0x8       national standard numbering plan


 0x9       private numbering plan






redirectingtype





 ISDN



 Number type, if supported. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x0       unknown


 0x1       international number


 0x2       national number


 0x3       network-specific number


 0x4       subscriber number


 0x6       abbreviated number






redirectingpres





 ISDN



 Redirecting number presentation indicator. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x0        presentation allowed


 0x1        presentation restricted






redirectingscreen





 ISDN



 Redirecting number screen indicator. Possible values are those stated in ITU's Q.931 recommendation:


 Value    Description


 0x0       redirecting number user-provided, not
               screened


 0x1       redirecting number user-provided, verified
               and passed


 0x2       redirecting number user-provided, verified
               and failed


 0x3       network provided






redirectingreason





 ISDN



 Reason for redirection. ITU's Q.931 recommendation lists many possible values, the most likely are:


 Value    Description


 0x11     user busy


 0x12     no user responding


 0x13     no answer from user






originalcalladdress





 ISDN



 Originally called number. This is the address the call was originally for, before it was first redirected.






origcalledplan





 ISDN



 Originally called number numbering plan ID. Not defined in ITU's Q.931 recommendation (variant-dependent).






origcalledtype





 ISDN



 Originally called number type. Not defined in ITU's Q.931 recommendation (variant-dependent).






origcalledpres





 ISDN



 Originally called number presentation indicator. Not defined in ITU's Q.931 recommendation (variant-dependent).






origcalledscreen





 ISDN



 Originally called number screen indicator. Not defined in ITU's Q.931 recommendation (variant-dependent).






origcalledreason





 ISDN



 Reason for redirection. Not defined in ITU's Q.931 recommendation (variant-dependent).






UUI





 ISDN



 User-to-user information. A text field that a terminal can send to another in ISDN attached to a number of messages or with a message of its own.















Note:  Most of these fields are not guaranteed to be filled during call setup. The values of these fields depends on the information associated with the incoming call, and on the protocol used to set up the call.

 






7.5	 Blocking and Unblocking Calls





CT Access provides the capability for applications to block and unblock calls on incoming or two way trunks. While calls are being blocked, no call control events are generated. This section describes how to block and unblock calls.






7.5.1	 Blocking Calls





Applications block calls by invoking adiBlockCalls. This function can be called at any time. It directs the protocol to block all incoming calls until adiUnBlockCalls is called. When the calls are blocked on the CTA context, an ADIEVN_CALLS_BLOCKED event is generated.



The application will not receive any call control events regarding the CTA context until it unblocks the CTA context. In addition, the application cannot place any outbound calls on the CTA context.



Although the application can call adiBlockCalls during any call control state, blocking only takes effect when the CTA context is in an idle state. If the context has an active call when the function is invoked, blocking is deferred until the call is released. 


Note:  Blocking a line is a valid action only when the trunk is capable of receiving calls (inbound only or two-way trunk).

 Blocking Methods



The method used to block incoming calls is determined by the blockmode field in the ADICALLCTL_PARMS structure passed to adiStartProtocol. Two blocking methods are supported by digital CAS TCPs:


  





 Method



 Description




 ADI_CC_BLOCK_REJECTALL 



 The TCP behaves as though the application has responded to each call with an adiRejectCall. The TCP rejects the calls by signaling busy on the line (the actual signal used varies from protocol to protocol), until the application calls adiUnBlockCalls.




 ADI_CC_BLOCK_MAKEBUSY 



 The TCP signals the telephone network that the line is blocked by setting the signalling bits to "blocked" mode. This blocks the line and keeps it blocked until adiUnBlockCalls is called.



















7.5.2	 Unblocking Calls





To unblock calls, the application can call adiUnBlockCalls at any time. When this function is called, the ADIEVN_CALLS_UNBLOCKED event is generated, the context returns to the call control idle state, and new calls may be established.






7.6	 Gateway Application Call Control





Gateway applications perform call control for calls that must be switched between separate trunks. They perform a switch-like function such as directing inbound calls from the PSTN to appropriate addresses on an internal network (the application may also be embedded in the PSTN itself). Typically, these applications receive inbound calls, analyze the incoming addresses, and then place calls to the specified addresses.



Accepting and rejecting calls with gateway applications can pose problems because the decision to accept or reject an incoming call depends on the status of the associated outbound call. The sections that follow describe how to accept and reject incoming calls with gateway applications.


 






7.6.1	 Accepting Calls





A gateway switching application goes through the following phases when accepting a call:


    


  1. The inbound side of the application receives a call.
    

    

  2. The call is "put on hold" (by accepting the call with adiAcceptCall and outputting silence on the line) while the outbound side of the application dials the received address.
    

    

  3. When the outbound side of the application receives an indication that the called terminal is free and ringing, it connects the voice path so that the caller hears the ringing tone from the called equipment.
    

    

  4. When the outbound call is answered, the application also answers the inbound call with no rings. This instructs the TCP to send the answer signal to the network immediately. Both calls are now in a connected state.
    




Figure 6 shows how gateway applications accept inbound calls:


 



Figure 6.	 Accepting Inbound Calls with Gateway Applications






7.6.2	 Rejecting Calls 





When a gateway application places an outbound call (in response to inbound calls on another trunk) the call may be rejected for a variety of reasons. When this happens, the application must also reject the corresponding inbound call. Figure 7 shows how this process works:


 



Figure 7.	 Rejecting Calls with Gateway Applications




The way a gateway application rejects calls is very similar to the way it accepts calls. Initially, the TCP accepts the incoming call and puts it "on hold", by outputting silence on the line. However, when the outbound call is rejected, the application calls adiRejectCall. Immediately the TCP starts to perform the action requested by adiRejectCall. It can play busy tone, or let the application play a reject message. The TCP then relies on the caller side to tear down the connection. For more information, refer to the ADI Function Reference Manual





























 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



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