(Page 1 of 1 in this chapter)


Chapter 4

AG ISDN Call Control


4.1 Introduction
4.2 Call Control Operations Supported By AG ISDN
4.3 Call Control API Summary
4.3.1 Call Control Functions and Solicited Events
4.3.2 Unsolicited Events
4.4 Establishing Inbound Calls
4.4.1 Retrieving Call Information
4.4.2 Answering the Call
4.4.3 Rejecting the Call
4.4.4 Accepting the Call without Answering
4.5 Establishing Outbound Calls
4.5.1 Initiating an Outbound Call
4.5.2 Outbound Call Events
4.6 Releasing a Call
4.6.1 Network-Initiated Call Release
4.6.2 Application-Initiated Call Release
4.7 Blocking and Unblocking Calls
4.7.1 Blocking Calls
4.7.2 Unblocking Calls
4.8 Using Extended Arguments
4.8.1 Receiving User-to-User Information (UUI)

4.1 Introduction

This chapter:

4.2 Call Control Operations Supported By AG ISDN

AG ISDN for Natural Call Control supports the following call control operations:

Operation

Supported?

For more information, see...

Receiving inbound calls

Yes

Section 4.4 of this manual.

Placing outbound calls

Yes

Section 4.5 of this manual.

Releasing calls

Yes

Section 4.6 of this manual.

Call blocking

Yes

Section 4.7 of this manual

Call transfer

No

N/A

4.3 Call Control API Summary

The following section summarizes the CT Access functions needed to perform call control. For most of these function calls, one or more events are expected in response to the command. These events are also described in this section.

Note: For detailed documentation of the functions, parameters and events, see the ADI Service Function Reference Manual.

There are two types of CT Access events associated with call control operations:

The eventmask parameter in the ADI_CALLCTL_PARMS structure dictates whether certain informational call control events are generated. For detailed information about this structure refer to the ADI Service Function Reference Manual.

4.3.1 Call Control Functions and Solicited Events

The following table lists call control-related functions and associated events. For detailed documentation of the functions, parameters and events, refer to the ADI Service Function Reference Manual.
Function

Description/Associated Events

adiAcceptCall

Directs the TCP to accept an incoming call without answering it. The application can then perform other operations before answering or rejecting the call. The application can accept a call using any of the following methods:

· ADI_ACCEPT_PLAY_RING

· ADI_ACCEPT_QUIET

· ADI_ACCEPT_USER_AUDIO

Associated Events:

· ADIEVN_ACCEPTING_CALL: The TCP is accepting the call, using the specified method. A PROGRESS message is sent to the network.

· ADIEVN_CALL_DISCONNECTED: A DISCONNECT message was received from the network, indicating that the remote party has hung up. The event value field contains the reason.

· ADIEVN_REJECTING_CALL: The application failed to invoke adiAnswerCall, adiAcceptCall or adiRejectCall within the period specified in the protocol's ADI.ISD.waitforpctime parameter. The call is automatically rejected. The event value field contains ADI_REJ_HOST_TIMEOUT. In this situation, a tone is played to the network.

adiAnswerCall

Directs the TCP to answer a call after a specified number of rings.

Associated Events:

· ADIEVN_ANSWERING_CALL: The TCP is answering. First an ALERT message is sent to the network. Then the TCP plays the number of rings specified in the adiAnswerCall call. Then a CONNECT message is sent to the network.

· ADIEVN_CALL_CONNECTED: The CONNECT message was acknowledged by the network, and the connection is established.

· ADIEVN_CALL_DISCONNECTED: A DISCONNECT message was received from the network, indicating that the remote party has hung up. The event value field contains the reason.

· ADIEVN_REJECTING_CALL: The application failed to invoke either adiAnswerCall, adiAcceptCall or adiRejectCall within the period specified in the protocol's ADI.ISD.waitforpctime parameter. The call is automatically rejected. The event value field contains ADI_REJ_HOST_TIMEOUT. In this situation, a tone is played to the network.

adiBlockCalls

Requests the TCP to block all incoming calls. The line remains in the blocked state until adiUnBlockCalls is called.

Associated Events:

· ADIEVN_CALLS_BLOCKED: Returns when request has been granted.

· ADIEVN_CALL_DISCONNECTED: A DISCONNECT message was received from the network, indicating that the remote party has hung up. The event value field contains the reason.

adiGetCallStatus

Retrieves incoming digits and other call status information.

Associated Events:

· ADIEVN_CALL_DISCONNECTED: A DISCONNECT message was received from the network, indicating that the remote party has hung up. The event value field contains the reason.

adiPlaceCall

Directs the TCP to place a call to a specified number, using call placement parameters from the ADI_PLACECALL_PARMS structure.

Associated Events:

· ADIEVN_PLACING_CALL: This informational event is generated after the TCP has seized the trunk, and an acknowledgement has been received from the network. (This implies that glare has been resolved.) The network is sent a SETUP message.

The event also indicates that a B channel has been chosen for the call. This is useful when the TCP is running in Non-Exclusive Mode (see Chapter 5). The stream and timeslot for this channel can be determined by calling adiGetCallStatus.

· ADIEVN_CALL_PROCEEDING: This low-level event is enabled only if the ADI_CC_REPTPROCEEDING bit is set in the ADI_CALLCTL_ PARMS eventmask passed to adiStartProtocol (see the source code for isdnchan.c for an example). This event follows ADIEVN_PLACING_CALL.

· ADIEVN_REMOTE_ALERTING: This low-level event is enabled only if the ADI_CC_REPTALERTING bit is set in the ADI_CALLCTL_PARMS eventmask passed to adiStartProtocol (see the source code for isdnchan.c for an example of this). It means that the network has sent an ALERTING message, indicating that the remote party is being alerted of the call, or that a ring tone has been detected.

· ADIEVN_REMOTE_ANSWERED: This low-level event is enabled only if the ADI_CC_REPTANSWERED bit is set in the ADI_CALLCTL_PARMS eventmask passed to adiStartProtocol (see isdnchan.c for an example of this). It means that the network has sent a CONNECT message, indicating that the remote party has answered.

· ADIEVN_CALL_CONNECTED: The call fits the connection criteria specified in the connectmask parameter in the ADI_PLACECALL_ PARMS structure. Usually, this is when a CONNECT message is received by the network; however, it could be due to other factors, depending on the connection criteria specified. The application can now play and record voice files, generate and detect DTMF tones, etc. The event value field contains the condition that satisfied the connection criteria.

· ADIEVN_CALL_DISCONNECTED: The call is disconnected, because:

A release event was received from the network, or

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

The call fits the disconnection criteria specified in the disconnectmask parameter in the ADI_PLACECALL_PARMS structure. By default, this is when a DISCONNECT message is received by the network. The event value field contains the condition that fit the disconnection criteria.

· ADIEVN_INCOMING_CALL: A call is arriving on the B channel. Call placement is aborted. This message occurs when a SETUP message is received.

adiRejectCall

Directs the TCP to reject an incoming call using one of the following methods:

· ADI_REJ_PLAY_BUSY

· ADI_REJ_PLAY_REORDER

· ADI_REJ_USER_AUDIO

· ADI_REJ_PLAY_RINGTONE

· ADI_REJ_FORCE_IMMEDIATE

Associated Events:

· ADIEVN_REJECTING_CALL: The reject sequence has started, or the application has failed to invoke adiAnswerCall, adiAcceptCall or adiRejectCall within the period specified in the protocol's ADI.ISD.waitforpctime parameter. The event value field contains the rejection method code, or ADI_REJ_HOST_TIMEOUT if the host timed out.

· ADIEVN_CALL_DISCONNECTED: The remote party has hung up. Either a DISCONNECT or a RELEASE message has been received from the network.

adiReleaseCall

Directs the TCP to perform one of the following actions: initiate connection teardown, abandon call placement, or acknowledge a network disconnect event.

Associated Events:

· ADIEVN_CALL_RELEASED: The call has been released. A DISCONNECT message was sent to the network, and a RELEASE was received.

· ADIEVN_CALL_DISCONNECTED: A disconnect occurred while the release is taking place. This means that a DISCONNECT message has been received from the network. A RELEASE is sent in response, terminating the call.

adiSetExtendedArgs

Sets new arguments for the call control function that immediately follows it.

Associated Events:

· ADIEVN_EXT_ARGS_SET: The arguments are set.

adiStartProtocol

Starts a TCP.

Associated Events:

· ADIEVN_STARTPROTOCOL_DONE: The function has finished. The event value field indicates if the TCP started successfully. CTA_REASON_ FINISHED means a successful completion. Any other value implies an error.

adiStopProtocol

Stops the TCP.

Associated Events:

ADIEVN_STOPPROTOCOL_DONE: Indicates that the TCP has been halted. The value field is set to CTA_REASON_FINISHED.

adiUnBlockCalls

Requests the TCP to stop blocking calls.

Associated Events:

· ADIEVN_CALLS_UNBLOCKED: The request to unblock the line is granted.

4.3.2 Unsolicited Events

The following is a list of call-control-related unsolicited events:

4.4 Establishing Inbound Calls

This section describes how a typical AG ISDN call control application receives and processes calls, once it has been initialized as described in Chapter 3.

The following is a summary of the steps to establishing an inbound call:

  1. The network offers the call.

    
    
  2. The application takes one of the following actions:
    Action

    What Happens

    It accepts and answers the call, by invoking adiAnswerCall.

    The TCP plays a ring tone for a specified amount of time, and then the call is connected.

    It rejects the call, by invoking adiRejectCall.

    The TCP plays a tone until the network times out and the call is cleared. It is also possible for the application to play a message instead of playing a tone.

    It accepts the call without answering, by invoking adiAcceptCall.

    The TCP accepts the call, and optionally plays a ring tone or other audio. The application can then invoke adiAnswerCall or adiRejectCall as needed.

Figure 11 is a state diagram for inbound calls. The sequence diagrams on the following pages can be correlated with this diagram to gain a comprehensive understanding of the inbound call states and events.

Figure 11. Inbound Call State Diagram

4.4.1 Retrieving Call Information

When the network first sends a SETUP message, the TCP handles the setup of an incoming call, and collects incoming digits (including ANI and subaddress digits), and other setup information. When all initial phases of call setup are complete, and the digits and other setup information are available, an ADIEVN_INCOMING_ CALL event is generated.

The application can call adiGetCallStatus to retrieve the digits and other information. The call status information is stored in the ADI_CALL_STATUS data structure, shown on the next page:

#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) */
INT32 reason; /* Reason for going back to IDLE state */
char calledaddr [ADI_MAX_DIGITS+1]; /*DNIS info, called no. */
/* (null-terminated string) */
char callingaddr[ADI_MAX_DIGITS+1]; /*ANI info, calling no. */
/* (null-terminated string) */
char callingname[ADI_MAX_CNAME+1]; /* Calling party name */
DWORD pendingcommand; /* Current unacknowledged command */
char usercategory; /* User category of the calling party */
char tollcategory; /* Toll category (generally 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 of */
/* called number (if supported) */
char callednumtype; /* Q.931 number type of */
/* called number (if supported) */
char callingnumplan; /* Q.931 numbering plan ID of */
/* calling number (if supported) */
char callingnumtype; /* Q.931 number type of */
/* calling number (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 no. info */
char redirectingplan; /* Q.931 numbering plan ID of */
/* redirecting number (if supported) */
char redirectingtype; /* Q.931 number type of */
/* redirecting number (if supported) */
char redirectingpres; /* Redirecting number presentation */
/* indicator */
char redirectingscreen; /* Q.931 redirecting number screen */
/* indicator */
char redirectingreason; /* Q.931 reason for redirection */
char originalcalledaddr [ADI_MAX_DIGITS+1]; /* (For future use) */
char UUI[132]; /* User-to-user information */
/* (132 chars max) */
} ADI_CALL_STATUS;
The ADI_CALL_STATUS structure contains the following fields:
Field

Description

size

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

state

Current call control state. Values applicable to AG ISDN are:

· ADI_CC_STATE_STOPPED

· ADI_CC_STATE_IDLE

· ADI_CC_STATE_INCOMING_CALL

· ADI_CC_STATE_ANSWERING_CALL

· ADI_CC_STATE_ACCEPTING_CALL

· ADI_CC_STATE_PLACING_CALL

· ADI_CC_STATE_DISCONNECTED

· ADI_CC_STATE_CONNECTED

· ADI_CC_STATE_REJECTING_CALL

· ADI_CC_STATE_OUT_OF_SERVICE

reason

Reason for the last disconnect (return to Idle state). reason is 0 if the application initiated the disconnect. Otherwise, reason is the value received in the ADIEVN_CALL_DISCONNECTED event.

calledaddr

For inbound calls, the called party address.

For AG ISDN, the digits are formatted as follows:

d1dn * s1sn

where:

· d1dn are the digits, and

· s1sn are the subaddress digits, if available. If no subaddress is available, the * and s digits do not appear in the string.

callingaddr

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

For AG ISDN, the digits are formatted as follows:

a1an * t1tn

where:

· a1an are the ANI digits, and

· t1tn are the subaddress digits, if available. If no subaddress is available, the * and s digits do not appear in the string.

callingname

Calling party name. Always 0 for AG ISDN.

pendingcommand

The last call control command issued that has not yet been acknowledged by the TCP. This field is set when a call control command is sent to the AG board. The field is cleared on the next event that causes a transition to a new call state.

Values applicable to AG ISDN are:

0 No command pending.

1 ADI_PENDCMD_PLACE_CALL

2 ADI_PENDCMD_ANSWER_CALL

3 ADI_PENDCMD_REJECT_CALL

4 ADI_PENDCMD_RELEASE_CALL

usercategory

For AG ISDN, this field is always 0.

tollcategory

For AG ISDN, this field is always 0.

stream

This field and timeslot together indicate the MVIP address of the B channel. Use if the TCP is in Non-Exclusive Mode (see Chapter 5).

timeslot

This field and stream together indicate the MVIP address of the B channel. Use if the TCP is in Non-Exclusive Mode (see Chapter 5).

billingrate

Billing rate of call.

callednumplan

Q.931 numbering plan ID of called address, if supported.
Default: 0 (unknown)

callednumtype

Q.931 type of called address (if supported).

callingnumplan

Q.931 numbering plan ID of calling address, if supported.
Default: 0 (unknown)

callingnumtype

Q.931 type of calling address (if supported).

callingpres

Presentation indicator for calling address. Used with Q.931 and certain digital CAS protocols.

callingscreen

Q.931 screening indicator.

progressdescr

Progress description in progress message.

releasecause

Cause for call release.

redirectingaddr

The redirecting address.

redirectingplan

Q.931 numbering plan ID of redirecting address (if supported).

redirectingtype

Q.931 type of redirecting address (if supported).

redirectingpres

Presentation indicator for redirecting address.

redirectingscreen

Redirecting number screen indicator.

redirectingreason

Reason for redirection.

originalcalledaddr

Reserved for future use.

UUI

User-to-user information (Up to 132 characters.)

4.4.2 Answering the Call

To answer the call, the application calls the function adiAnswerCall. You can specify 0 or more ring tones to play before answering the call.

The following events are associated with this function:

Figure 12 is a sequence diagram for answering an inbound call. This diagram depict the normal exchange of commands and events between the network, the channelizer, the TCP, CT Access, and the application.

Figure 12. Sequence Diagram for Answering Inbound Call

4.4.3 Rejecting the Call

To reject the call, the application can call adiRejectCall. The following rejection methods are possible for AG ISDN:

The following events are associated with this function:

Figure 13 illustrates rejection of an inbound call:

Figure 13. Sequence Diagram for Rejecting Inbound Call

4.4.4 Accepting the Call without Answering

An application can accept an inbound call without answering, by calling adiAcceptCall. In response to this function call, the TCP sends a PROGRESS message on the trunk. 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:

Figure 14 illustrates accepting an inbound call and then rejecting it:

Figure 14. Sequence Diagram for Accepting and then Rejecting Inbound Call


Figure 15 illustrates accepting an inbound call and then answering it:

Figure 15. Sequence Diagram for Accepting and then Answering Inbound Call

4.5 Establishing Outbound Calls

This section describes how a typical AG ISDN call control application places calls, once it has been initialized as described in Chapter 3.

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 causes a SETUP message to be sent to the network. This message contains all of the information necessary to place the call.

    
    When the network has accepted the call, it sends a call processing message.
  3. The TCP generates an ADIEVN_PLACING_CALL event. The TCP then waits for the remote party to accept or reject the call.

    
    
  4. If the call request is rejected by the network (e.g., a DISCONNECT message from the network or busy or reorder signal detected), the TCP abandons call placement.

    
    
  5. If a network connection is established, CT Access generates a "call connected" or "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 16 is a state diagram for placing outbound calls. This diagram can be correlated with the sequence diagram in Figure 17 to gain an understanding of outbound call states and events.

Figure 16. Outbound Call State Diagram


Figure 17 is a sequence diagram depicting, at several levels, the command and event interchange for placing an outbound call. Note that depending upon the switch variant, some of these intermediate messages may not occur, or may occur in a different order than shown here.

Figure 17. Sequence Diagram for Outbound Call

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

The AG ISDN TCP expects the digit string to be formatted as follows:

# a1an * s1sn # d1dn * t1tn

where:

4.5.2 Outbound Call Events

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

  • ADIEVN_INCOMING_CALL: A call is coming in on the B channel. The call placement is aborted. This message results from the receipt of a SETUP message.

  • 4.6 Releasing a Call

    In order for CT Access to release a call, both the application and the network must actively release it. The network can disconnect at any time, regardless of the call control state.

    After the call is released by both the network and the application, CT Access generates a call released event (ADIEVN_CALL_RELEASED). Once the call is released, no more DSP-related events will be generated on the CTA context, and the application is eligible to receive and place new calls.

    The next two sections present procedures for both network- and application-initiated call releases.

    4.6.1 Network-Initiated Call Release

    To release a call in response to a network disconnect:

    1. The network sends a DISCONNECT message.

      
      
    2. All active operations that use DSP resources are terminated, and their DONE events are generated.

      
      
    3. The TCP causes CT Access to generate a call disconnected event, ADIEVN_CALL_DISCONNECTED.

      
      Note:  After the ADIEVN_CALL_DISCONNECTED event, CT Access will not allow DSP-related operations to be started on the CTA context until the CTA context re-enters the Connected state.
      
      
    4. In response to ADIEVN_CALL_DISCONNECTED, the application invokes adiReleaseCall.

      
      
    5. The TCP responds by sending a RELEASE message to the network.

      
      
    6. The network responds with RELEASE COMPLETE.

      
      
    7. CT Access generates a call released event, ADIEVN_CALL_RELEASED.

      
      
    8. When the application processes the event, its internal state is reset to idle.

    The application is now eligible to place and receive new calls.

    Figure 18 is a sequence diagram depicting the command and event interchange for a network-initiated release:

    Figure 18. Sequence Diagram for Network-Initiated Release

    4.6.2 Application-Initiated Call Release

    Application-initiated call release is a one-step process. To release a call from within an application:

    1. The application invokes adiReleaseCall.

      
      All active operations that use DSP resources are terminated, and their DONE events are generated, in the following manner:
      
      a.	 In response to adiReleaseCall, the TCP sends a DISCONNECT message to the network.

      b. When the network responds with a RELEASE message, the ISDN protocol stack (channelizer level) responds with a RELEASE COMPLETE message, and causes the TCP to cause CT Access to generate a call released event, ADIEVN_CALL_RELEASED.

      c. When CT Access processes the event, its internal call state is reset to idle.

      d. After the application calls adiReleaseCall, CT Access will not allow DSP-related operations to be started on the CTA context until the port re-enters the Connected state.

    The application is now eligible to place and receive new calls.

    Figure 19 is a sequence diagram depicting the command and event interchange for an application-initiated release:

    Figure 19. Sequence Diagram for Application-Initiated Release

    4.7 Blocking and Unblocking Calls

    The ADI service provides the capability for the application to block incoming calls and prevent placement of outbound calls. While calls are being blocked, no call control events are generated.

    4.7.1 Blocking Calls

    The application blocks calls by invoking adiBlockCalls from any call control state. Blocking only takes effect in the call Idle state. If the call control state is not Idle, blocking is deferred until the call is released. When the ADI service begins blocking calls, the application will no longer receive any call control events or be allowed to place any outbound calls.

    AG ISDN software supports only the "reject all incoming calls" blocking method. The TCP behaves as though the application has pre-responded to each call with an adiRejectCall.

    To specify this blocking mode, set the blockmode field to 0 in the ADI_CALLCTL_PARMS passed to adiStartProtocol. Call blocking method 1 is not supported.

    When the ADI service begins blocking calls, the ADIEVN_CALLS_BLOCKED event is generated.

    4.7.2 Unblocking Calls

    To unblock calls, invoke adiUnBlockCalls.

    When adiUnBlockCalls is executed, the ADIEVN_CALLS_UNBLOCKED event is generated, the call control state returns to Idle, and new calls may be established.

    4.8 Using Extended Arguments

    An application can send various types of ISDN-specific information during certain call control operations. This information includes address information, user-to-user information (UUI), and other values.

    The information is sent in extended argument structures. An application can send extended arguments during the following operations:

    In each case, the information is sent when the function call is made.

    To specify the information to be sent, the application calls adiSetExtendedArgs, presenting the information in one of the data structures specified below:

    /* Supplementary services accept call extensions:              */
    typedef struct
    {
    DWORD size; /* Size of structure */
    char uui [132]; /* User-to-user info (132 chars max) */
    WORD cause; /* Cause */
    WORD progressdescriptor; /* Progress descriptor */
    } ISDNACCEPTCALL_EXTARGS;
    /* Supplementary services answer call extensions: */
    typedef struct
    {
    DWORD size; /* Size of structure */
    char uui [132]; /* User-to-user info (132 chars max) */
    } ISDNANSWERCALL_EXTARGS;
    /* Supplementary services called number extensions: */
    typedef struct
    {
    char plan; /* Called numbering plan */
    char type; /* Called number type */
    char pad[2]; /* Pad */
    } ISDN_CALLEDNUMBER;
    /* Supplementary services calling number extensions: */
    typedef struct
    {
    char digits[33]; /* Calling address (33 char max) */
    char plan; /* Calling numbering plan */
    char type; /* Calling number type */
    char screen; /* Calling no. screening indicator */
    char presentation; /* Calling number presentation */
    char pad[3]; /* Pad */
    } ISDN_CALLINGNUMBER;
    /* Supplementary services place call extensions: */
    typedef struct
    {
    DWORD size; /* Size of structure */
    char uui [132]; /* User-to-user info (132 chars max) */
    ISDN_CALLEDNUMBER callednumber; /* Called address */
    ISDN_CALLINGNUMBER callingnumber; /* Calling address */
    ISDN_REDIRECTINGNUMBER redirectingnumber;/*Redirecting addr*/
    WORD service; /* Service */
    WORD nsf_service_feature; /* NSF service feature */
    } ISDNPLACECALL_EXTARGS;
    /* Supplementary services redirecting number extensions: */
    typedef struct
    {
    char digits[33]; /* Redirecting address (33 char max) */
    char plan; /* Redirecting numbering plan */
    char type; /* Redirecting number type */
    char screen; /* Redir no. screening indicator */
    char presentation; /* Redirecting number presentation */
    char reason; /* Reason for redirection */
    char pad[3]; /* Pad */
    } ISDN_REDIRECTINGNUMBER;
    /* Supplementary services reject call extensions: */
    typedef struct
    {
    DWORD size; /* Size of structure */
    char uui [132]; /* User-to-user info (132 chars max) */
    WORD cause; /* Cause */
    } ISDNREJECTCALL_EXTARGS;
    /* Supplementary services release call extensions: */
    typedef struct
    {
    DWORD size; /* Size of structure */
    char uui [132]; /* User-to-user info (132 chars max) */
    WORD cause; /* Cause */
    } ISDNRELEASECALL_EXTARGS;
    The information is sent when the next call to adiAcceptCall, adiAnswerCall, adiRejectCall, or adiReleaseCall is made, depending upon which data structure is filled. The call control function will get the new arguments from the data structure, pass them to the board, and clear the pointer to the arguments structure.

    For more information about extended call control arguments, see your ADI Service Function Reference Manual.

    4.8.1 Receiving User-to-User Information (UUI)

    User-to-user information (UUI) may be presented to the application at any time during a call. When user-to-user information is received, an ADIEVN_STATUS_UPDATE event is generated. The value field contains CALL_STATUS_UUI.

    The UUI information is available in the ADI_CALL_STATUS structure. (See Section 4.4.1 for a listing of this structure.) It can be retrieved using the adiGetCallStatus function.

    Only text UUI is supported.



    (Page 1 of 1 in this chapter)


    tech_support@nmss.com
    Copyright © 1998, Natural MicroSystems, Inc. All rights reserved.