(Page 1 of 1 in this chapter)

Chapter 6

Performing AG CAS Call Control

6.1 Performing AG CAS Call Control
6.2 Responding to Inbound Calls
6.2.1 Inbound Call Sequence and Events
6.2.2 Retrieving Incoming Call Information
6.2.3 Accepting Inbound Calls
6.2.4 Answering Inbound Calls
6.2.5 Rejecting Inbound Calls
6.3 Placing Outbound Calls
6.3.1 Outbound Call Sequence and Events
6.3.2 Call Set Up Events
6.3.3 Placing Outbound Calls
6.3.4 Call Control Mask Parameters
6.4 The ADI_CALL_STATUS Structure
6.5 The Connected State
6.5.1 Transferring Calls on Loop Start Trunks
6.5.2 Disconnect on Loop Current Reversal on Loop Start Lines
6.5.3 Billing Pulses on Digital Trunks
6.6 Blocking and Unblocking Calls
6.6.1 Blocking Calls
6.6.2 Unblocking Calls
6.7 Gateway Application Call Control
6.7.1 Accepting Calls
6.7.2 Rejecting Calls

6.1 Performing AG CAS Call Control

This chapter describes:

6.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.

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

6.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.

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 the bit enabled).

On analog lines this event is reported after detecting the leading edge of the first ring.

ADIEVN_INCOMING_DIGIT

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

ADIEVN_INCOMING_CALL

 The TCP set up the incoming call. The TCP then waits for the application to decide if the call should be answered, accepted, or rejected.

On loop start lines this event is generated after a number if rings have been received, along with optional caller ID information.

The application may take one of the following actions:

  • Accept and answer the call, by invoking adiAnswerCall. The TCP plays the number of ring tones specified by the application, and then connects the call. 

    

  • Reject the call, by invoking adiRejectCall.

    

    
The TCP rejects the call in one of the following ways:
      

    • Plays a reject tone during register signaling (only available for certain 
digital protocols). The equipment placing the call should recognize the 
tone and abandon call set up. In addition, the TCP can play a busy tone 
or allow the application to play a voice file or a custom tone after 
playing the reject tone.

      

      

    • Send an out-of-band signal (only available for certain digital protocols). 
The party placing the call should recognize the signal and abandon call 
set up. In addition, the TCP can play a busy tone or allow the application 
to play a voice file (or custom tone) after sending the reject signal.

      

      

    • Continue playing the ring back tone until the calling party clears. This is 
the only possibility for loop start analog trunks, and is also an option for 
digital trunks (digital protocols only).

      

      

      Figure 3 shows a 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 States
      

      

      Figure 4 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. 
      

Note:  Informational events are shown as dashed lines. Optional commands/events ar shown as dotted lines.




      Figure 4.	 Inbound Call Sequence 
      

      • 

      

      6.2.2	 Retrieving Incoming Call Information
      

      


      This section describes how to retrieve incoming call information for incoming calls received on loop start and digital trunks.
      

 Analog Trunks
      


      Loop start trunks allow users to subscribe to caller ID service. Caller ID information transfer is performed by using modem tones on the line at different times during the call set up. Different protocols are used in different countries to transfer Caller ID information. 
      

Note:  Protocol parameters that control this behavior are set in the CAS protocol country-specific parameter file. These should not be modified.


      Refer to Appendix B for more information on Caller ID protocols and setup. Refer to Appendix C for information about the CID files supported for particular countries. 
      


      To retrieve caller ID data, respond to ADIEVN_INCOMING_CALL events by invoking adiGetCallStatus. Because the caller ID data is stored in the ADI_CALL_STATUS structure (on a call-by-call basis), applications must analyze the call status of every incoming call to retrieve caller ID information.
      

 Digital Trunks
      


      Applications using digital trunks can retrieve incoming digits in two ways:
      

      

      

      6.2.3	 Accepting Inbound Calls 
      

      


      To accept an inbound call without committing to answer the call, the application invokes adiAcceptCall. In response to this function (on digital trunks only), the TCP accepts the call by sending a specific tone or digital signal to the network. The TCP also performs the media operations requested with adiAcceptCall. No further action is taken until the application answers or rejects the call, or the remote party disconnects. 
      


      adiAcceptCall takes an argument that specifies what the TCP should do while accepting the call. The following actions are available:
      

 

      


      
 Method
      

      		
 Description
      


      
 ADI_ACCEPT_PLAY_RING
      

      		
 Play a ring tone (only option on loop start trunks).
      


      
 ADI_ACCEPT_QUIET
      

      		
 Accept the call, but do not play a tone or other audio.
      


      
 ADI_ACCEPT_USER_AUDIO
      

 
      

      		
 The application may generate a recorded message. If the remote party disconnects, the TCP interrupts message.
      



      


      

      

      

      

      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.
      


      
 ADIEVN_REJECTING_CALL
      (digital trunks only)
      

      		
 The protocol time expired before adiAcceptCall reached the TCP. 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.)
      



      


      

      

      


      

      

      6.2.4	 Answering Inbound Calls
      

      


      To answer calls, applications invoke 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.
      


      
 ADIEVN_REJECTING_CALL
      (digital trunks only)
      

      		
 The protocol time expired before adiAnswerCall reached the TCP. 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 are specified by parameters.)
      



      


      

      

      

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

      

      

      6.2.5	 Rejecting Inbound Calls
      

      


      To reject calls, applications invoke adiRejectCall. You can specify the following rejection methods with for CAS TCPs:
      

 

      


      
 Method
      

      		
 Description
      


      
 ADI_REJ_PLAY_RINGTONE
      

      		
 Plays a ring tone until the remote party disconnects.
      


      
 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. If the remote party hangs up, the TCP interrupts the application tone or voice file.
      



      


      

      

      

      

      


      The application receives the following events after calling adiRejectCall:
      

 

      


      
 Event
      

      		
 Description
      


      
 ADIEVN_REJECTING_CALL
      

      		
 Acknowledges that adiRejectCall has been received, and the specified action to reject the call has been initiated. 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 the application has failed to invoke either adiAnswerCall or adiRejectCall within the period specified in the protocol's parameters. The event value field contains ADI_REJ_HOST_TIMEOUT and the call is automatically rejected.
      


      
 ADIEVN_CALL_DISCONNECTED
      

      		
 The calling side hung up. In this case (a race condition) ADIEVN_REJECTING_CALL is not received. The value field contains ADI_DIS_REMOTE_ABANDONED.
      



      


      

      

      


      

      

      6.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 Chapter 4 for instructions about loading parameter files, or to Chapters 7 - 19 for a complete list of parameters for each TCP.

      

      

      6.3.1	 Outbound Call Sequence and Events
      

      


      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 (glare) will not occur for this call (i.e., on two way trunks the next event will not be an incoming call).
        

        

      3. The TCP performs all operations necessary to set up the call, and dial the requested number.
        

        

      4. If the call request is rejected by the network, the TCP abandons call placement and the application receives 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 5 shows the state diagram for placing outbound calls. This diagram, combined with the sequence diagram in Figure 6, 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 5.	 Outbound Call State Machine
      

      

      Figure 6 is a sequence diagram that shows, at several levels, the command and event interchange for placing an outbound call (ADIEVN_STATUS_INFO_UPDATE is not received in all protocols). 
      

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. 




      Figure 6.	 Placing Outbound Calls 
      

      

      

      6.3.2	 Call Set Up Events
      

      


      The following events are received 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.
      


      
 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.
      


      
 ADIEVN_REMOTE_ANSWERED
      

      		
 The remote party has picked up the phone.
      

 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.
      


      
 ADIEVN_CALL_CONNECTED
      

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


      
 ADIEVN_STATUSINFO_UPDATE
      (digital trunks only)
      

      		
 If enabled and protocol supports billing information transmission this event signals that the billing status of the call is known. The event's value field in this case equals CALL_STATUS_BILLINGRATE.
      


      
 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 has been detected.
      

·	 On loop start lines: A loop current reversal (if enabled) indicating that the remote disconnect event has been detected after the call was answered. 
      

·	 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.)
      



      


      

      

      


      

      

      6.3.3	 Placing Outbound Calls
      

      


      To place an outbound call, the application invokes adiPlaceCall which directs the TCP to seize the line and deliver a digit string to the network. 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. These parameters determine the conditions under which the TCP connects or abandons a call. For more information about call control connectmask and disconnectmask parameters, refer to the ADI Service Developer's Manual.
      

Note:  Different TCPs expect the digit string to be formatted in different ways. If the telephone network requires ANI digits, the application must insert separator symbols (#) to distinguish ANI digits from DID digits. Refer to Chapter 7 - 19 for more information about digit string formatting according to protocol.

      

      

      6.3.4	 Call Control Mask Parameters
      

      


      The application chooses the criteria by which the ADI service generates the connected events and disconnected events. The ADI_PLACECALL_PARMS structure contains the connectmask and disconnectmask parameters that dictate when the connected events and disconnected events are generated, thus terminating call progress analysis. Each bit in these masks corresponds to a telephone network or remote party event. If a condition is specified in both masks, connectmask takes precedence. 
      

 Connectmask
      


      In the ADI_PLACECALL_PARMS structure, the connectmask parameter specifies which call progress analysis event causes the ADI service to progress from the Placing Call state to the Call Connected state (as shown in Figure 5).
      


      Each of the following bits occupies a position in the connectmask parameter. If the bit is set and the condition described occurs, the ADIEVN_CALL_CONNECTED event is generated.
      

 

      


      
 Connect Mask Bit
      

      		
 Condition for ADIEVN_CALL_CONNECTED
      


      
 ADI_CON_ON_RING_QUIT
      

      		
 Ring tone stopped; no other events detected.
      


      
 ADI_CON_ON_SIGNAL
      

      		
 Out-of-band signaling indicates telephone network connection established.
      


      
 ADI_CON_ON_CED
      

      		
 Modem tone detected from remote station.
      


      
 ADI_CON_ON_VOICE_BEGIN
      

      		
 First detection of remote voice.
      


      
 ADI_CON_ON_VOICE_MEDIUM
      

      		
 Remote voice has lasted longer than the first time threshold.
      


      
 ADI_CON_ON_VOICE_LONG
      

      		
 Remote voice has lasted longer than the second time threshold.
      


      
 ADI_CON_ON_VOICE_EXTENDED
      

      		
 Remote voice has lasted longer than the third time threshold.
      


      
 ADI_CON_ON_DIALTONE
      

      		
 Dial tone was detected after placing the call.
      


      
 ADI_CON_ON_SIT
      

      		
 Special Information Tone (SIT) was received.
      


      
 ADI_CON_ON_CALL_PROCEEDING
      

      		
 Unconditional - connect immediately after dialing (no call progress analysis).
      



      


      

      

      

      

      The following two conditions, if satisfied, always generate an ADIEVN_CALL_CONNECTED event. These two conditions have no bit position in the connectmask. 
      

      

      You can override either of these conditions, by setting the corresponding bit within the disconnectmask, ADI_DIS_ON_VOICE_END or ADI_DIS_ON_TIMEOUT, respectively.
      


      Once one of the enabling conditions is satisfied, the call is connected. When the call is connected, the ADI service generates an ADIEVN_CALL_CONNECTED event. The event's value field indicates the reason for the transition to the Connected state.
      


      For more information about call progress events, refer to the ADI Service Developer's Manual.
      

 Connecting on Loop Current Reversal on Analog Lines
      


      Some analog networks signal that the called number has answered the call by reversing the tip and ring polarity on the access line. You can set the TCP to enable detection of the loop current reversal events by setting the reversalmode parameter. Refer to Chapter 7 for more information about loop start TCP-specific parameters. 
      


      If detection of loop current reversal on far-end answer is enabled, the TCP sends an ADIEVN_REMOTE_ANSWERED event to the application after the called number answers the call (this is indicated by a loop current reversal event). If the ADI_CON_ON_SIGNAL bit is set in the connectmask the call will progress to the Connected state. If the ADI_CON_ON_SIGNAL bit is not set, call progress analysis continues until one of the enabled connect conditions is satisfied. 
      

 

      


      


      Caution:
      

      

      


      Enable loop current reversal events only if the network provides this service. Otherwise, the TCP may behave incorrectly.
      

      

      


      


      

      

      

      
 Disconnectmask
      


      The disconnectmask parameter in the ADI_PLACECALL_PARMS structure determines which call progress analysis events cause the ADI service to progress from the Placing Call state to the Disconnected state.
      


      Each of the following bits occupies a position in the disconnectmask parameter. If the bit is set and the condition described occurs, the ADIEVN_CALL_DISCONNECTED event is generated.
      

 

      


      
 Disconnect Mask Bit
      

      		
 Condition for ADIEVN_CALL_DISCONNECTED
      


      
 ADI_DIS_ON_RING_QUIT
      

      		
 Ring tone stopped; no other events detected.
      


      
 ADI_DIS_ON_CED
      

      		
 Fax or modem tone detected from remote station.
      


      
 ADI_DIS_ON_VOICE_BEGIN
      

      		
 First detection of remote voice.
      


      
 ADI_DIS_ON_VOICE_MEDIUM
      

      		
 Remote voice has lasted longer than the first time threshold.
      


      
 ADI_DIS_ON_VOICE_LONG
      

      		
 Remote voice has lasted longer than the second time threshold.
      


      
 ADI_DIS_ON_VOICE_EXTENDED
      

      		
 Remote voice has lasted longer than the third time threshold.
      


      
 ADI_DIS_ON_VOICE_END
      

      		
 Remote party stopped speaking.
      


      
 ADI_DIS_ON_TIMEOUT
      

      		
 No events occur after the event ADIEVN_CALL_PROCEEDING.
      



      


      

      

      

      

      The following conditions, if satisfied, always generate a disconnected event. These conditions have no bit position in the disconnectmask. In effect, they are always turned on.
      

 

      


      
 Condition
      

      		
 Description
      


      
 Disconnect on busy
      

      		
 A busy signal has been detected.
      


      
 Disconnect on reorder
      

      		
 A reorder signal has been detected.
      


      
 Disconnect on no answer
      

      		
 The remote party did not answer.
      


      
 Disconnect on SIT
      

      		
 A Special Information Tone (SIT) has been detected. Note that if the connectmask parameter is set to connect on SIT, this disconnect reason is never activated.
      



      


      

      

      

      

      For more information on call progress analysis refer to the ADI Service Developer's Manual.
      

      

      

      6.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 except LPS
      

      		
 For inbound calls, the called party address.
      


      


      callingaddr
      

      

      		
 MFC
      

 LPS (with caller ID)
      

 EAM
      

 MFS
      

 R15
      

 ISDN
      

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


      


      callingname
      

      

      		
 LPS (with caller ID)
      

      		
 Calling party name, if supported (loop start lines with Caller ID only).
      


      


      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
      

 LPS (with caller ID)
      

 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 2000 and 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.


      

      

      

      6.5	 The Connected State
      

      


      This section describes some specific features of analog and digital trunks that are available while a call is in the Connected state.
      

      

      

      6.5.1	 Transferring Calls on Loop Start Trunks
      

      


      When a call is in the Connected state, it can be transferred from a first line to a second line through a Private Branch Exchange (PBX), Centrex, or Centrex-like exchange. 
      


      There are two methods for transferring calls:
      

      

      Both methods deliver a flash hook (or other configurable dialing sequence) to the first line and obtain a second line. After a recall dial tone is received from the line, the process for placing a second call is identical to that described in Section 6.3.
      


      For blind transfer, the condition on which to transfer a call is specified as an argument to adiTransferCall. Otherwise, call transfer operations use the same parameters as outbound call placement operations. These parameters are part of the ADI_PLACECALL_PARMS and ADI_CALLPROG_PARMS structures. For details about how to setup the protocol specific parameters refer to Chapter 7 - 19.
      


      The following call transfer events are generated by CT Access: 

      


      
 Call Transfer Event
      

      		
 Description
      


      
 ADIEVN_PLACING_CALL2
      

      		
 After delivering the flash hook (or other configurable dialing sequence) to the line and getting a recall dial tone, CT Access generates the placing second call event. The destination address for the third party is then delivered to the network.
      


      
 ADIEVN_CALL2_DISCONNECTED
      

      		
 If placement of the second call fails or if the third-party hangs up, the ADIEVN_CALL2_DISCONNECTED event is generated. The call returns to the Connected state for the first call. This event is also generated when the application releases the second call with                                adiReleaseSecondCall.
      


      
 ADIEVN_CALL2_CONNECTED
      

      		
 This event is generated if the second call is successfully established via adiPlaceSecondCall. The connection criteria and processing are identical to those when originating calls with adiPlaceCall.
      


      
 ADIEVN_CALL_DISCONNECTED
      

      		
 This event is generated when a blind transfer succeeds. It is also generated if the first line disconnects before CT Access generates the placing second call event. The call disconnected event disconnects the channel from both calls. The application must invoke adiReleaseCall to return to the Idle state.
      



      


      

      

      

      

 Using Supervised Transfer
      


      To perform a supervised transfer on loop start trunks:
      

        


      1. The application invokes adiPlaceSecondCall. 
        

          

        • CT Access obtains a second line and generates the 
ADIEVN_PLACING_CALL2 event. CT Access then delivers the second 
address to the line and starts monitoring the call.

          

          

        • If CT Access fails to establish the second call, a 
ADIEVN_CALL2_DISCONNECTED event is generated. The call control 
state changes back to the Connected state for the first line.

          

          

        • If the second call is successfully placed, CT Access generates a 
ADIEVN_CALL2_CONNECTED event. The application is now speaking 
to the third party (second line destination).

          

          

        • If the third party hangs up, CT Access generates a 
ADIEVN_CALL2_DISCONNECTED event, the call control state 
transitions back to the Connected state for the first line, and the 
application resumes speaking with the first party.

          

          

        • If the dial fails, CT Access generates a 
ADIEVN_CALL2_DISCONNECTED event, with reason 
ADI_DIS_DIAL_FAILURE (or ADI_DIS_NO_DIALTONE if dial tone was 
expected but not present). The call control state is returned to Connected 
for the first line. When returning to the Connected state, the second 
string specified by the connstring parameter is dialed.

          

          

        • The application can invoke adiReleaseSecondCall, which causes CT Access to deliver a flash hook to the line and generate an ADIEVN_CALL2_DISCONNECTED event. The call control state changes back to the Connected state for the first line.
          

          
Note:  Depending on the PBX or switch, this may result in a three-party conversation. 


        • The application can invoke adiReleaseCall, which causes CT Access to send an on-hook signal to the line interface. The ADIEVN_CALL_RELEASED event is generated and the call control state changes back to Idle. This completes the transfer.
          

        


        


        Figure 8 shows the CT Access state diagram for transferring calls. For more information about CT Access call control, refer to the ADI Service Developer's Manual.
        




        Figure 7.	 Supervised Call Transfer State Machine
        

        
 Using Blind Transfer
        

        

        A blind transfer initiates second call placement and then hangs up the line before the second call placement is resolved. The application specifies one of the following conditions, on which it disconnects from the switch, as an argument to adiTransferCall:
        

 

        


        
 Condition 
        

        		
 Description
        


        
 ADI_XFER_PROCEEDING
        

        		
 The second line's address is delivered to the switch and the transfer is completed as soon as the digit string is dialed.
        


        
 ADI_XFER_ALERTING
        

        		
 The transfer is completed as soon as the ring tone is received on the second line.
        


        
 ADI_XFER_CONNECTED
        

        		
 The transfer is completed as soon as the second line has been answered.
        



        


        

        

        

        

        To perform a blind transfer on a loop start trunk:
        

          


        1. The application invokes adiTransferCall.
          

          

        2. The ADI service obtains a second line and generates an ADIEVN_PLACING_CALL2 event. CT Access then delivers the second address to the PBX or switch.
          

          

        3. After the specified transfer condition has occurred CT Access generates the ADIEVN_CALL_DISCONNECTED event. The application must release the call (invoking adiReleaseCall) before new calls can be established. 
          

        


        If the condition specified in adiTransferCall does not occur, or the dial fails. CT Access generates an ADIEVN_CALL2_DISCONNECTED event, with the reason ADI_DIS_DIAL_FAILURE (or ADI_DIS_NO_DIALTONE if dial tone was expected but not present). The call control state is returned to Connected for the first line. This might occur, for example, if the second line is busy. When returning to the Connected state, the second string specified by the connstring parameter is dialed. 
        

        

        

        6.5.2	 Disconnect on Loop Current Reversal on Loop Start Lines
        

        


        Some networks reverse the tip and ring polarity on the line when the far-end party hangs up. You can enable detection of loop current reversal events indicating 
        far-end disconnects by setting the reversalmode parameter in the protocol parameter file. Refer to         Chapter 7 for more information about the parameter settings. 
        


        If detection of loop current reversal on far-end hang-up is enabled, the TCP will send the ADIEVN_CALL_DISCONNECTED event to the application after the called party hangs up. Then the application should call adiReleaseCall to return to the Idle state.
        


        If the loop current reversal is detected while in the Connected2 state, this indicates that the second called party has disconnected (see Figure 6). The TCP sends the ADIEVN_CALL2_DISCONNECTED event to the application and the call will return to the Connected state for the first call.
        

 

        


        


        Caution:
        

        

        


        Enable loop current reversal events only if the network provides this service. Otherwise the TCP may behave incorrectly.
        

        

        


        


        

        

        


        

        

        6.5.3	 Billing Pulses on Digital Trunks
        

        


        On certain kinds of digital trunks, and if the network provides this service, an outbound call receives billing pulses during the Connected state. These are brief variations in the state of the signaling bits, that signal that a unit of cost has been billed to the call. The actual price of a unit of cost changes from network to network, as does the frequency with which billing pulses are received.
        


        An application placing outbound calls can set the bit ADI_CC_REPTBILLING in the ADI.START.callctl.eventmask parameter to enable the reception of billing pulses events. These are presented as ADIEVN_BILLING_PULSE events by CT Access. The application can then count the events to calculate the cost of the call.
        

        

        

        6.6	 Blocking and Unblocking Calls
        

        


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

        

        

        6.6.1	 Blocking Calls
        

        


        Applications block calls by invoking adiBlockCalls. This function can be called at any time. It directs the TCP 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 CT Access 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 CT Access context has an active call when the function is invoked, blocking is deferred until the call is released. 
        

Note:  Since outbound-only trunks typically cannot be blocked, blocking a line is a valid action only when the trunk is capable of receiving calls (inbound-only or two-way trunks).

 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:
        

 

        


        
 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 
        

 (digital trunks only)
        

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



        


        

        

        


        

        

        6.6.2	 Unblocking Calls
        

        


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

        

        

        6.7	 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. However, the time available in the incoming call protocol to accept the call can be shorter than the setup time for the corresponding outgoing call.
        


        The sections that follow describe how to accept and reject incoming calls with gateway applications.
        

        

        

        6.7.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) and 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 8 shows how gateway applications accept inbound calls:
        




        Figure 8.	 Accepting Inbound Calls with Gateway Applications
        

        

        

        6.7.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 9 illustrates how this process works:
        




        Figure 9.	 Rejecting Calls with Gateway Applications
        

        

        The way a gateway application rejects calls is similar to the way it accepts calls. Initially, the TCP accepts the incoming call and puts it "on hold" by sending silence to the line. When the outbound call is rejected, the application calls adiRejectCall. The TCP immediately starts to perform the action requested by adiRejectCall. It can play a busy tone, or let the application play a reject message. Then TCP then relies on the caller side to tear down the connection.
        


        


        


        


        


        

        

        


        
 
    (Page 1 of 1 in this chapter)
        


        
 



        
tech_support@nmss.com

        

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