• 5.6.1. Support and Scenarios for Call Analysis with GlobalCall

5.6. Call Progress and Call Analysis

Call analysis consists of both pre-connect and post-connect information about the progress of the call. Pre-connect call progress determines the status of the call connection, that is, busy, no dial tone, no ringback, etc. Post-connect call analysis, which is also known as "media type detection," determines the destination party's media type, that is, answering machine, fax, modem, voice, etc.

NOTES:

1. In GlobalCall terminology, the term call analysis is used interchangeably with the term call progress.

2. The information in this section also applies to DI products, which are considered to use CAS protocols.

There are two methods available for Call Analysis in R4 on DM3: the GlobalCall method and the dx_dial( ) method.

The GlobalCall media detection method is especially useful for performing post-connect call analysis. When activated by setting the GCPR_MEDIADETECT parameter to GCPV_ENABLE for a particular channel, post-connect call analysis is performed as part of the gc_MakeCall( ) function's operation. The gc_MakeCall( ) function is used to place a call, the signal detector analyzes the incoming signals to perform call progress analysis.

After the normal gc_MakeCall( ) processing finishes and GCEV_CONNECTED event is sent, call analysis runs and generates a GCEV_MEDIADETECTED event that tells the application the result of the analysis (for example, FAX, PVD, or PAMD is detected).

The outcome of the analysis determines the events generated and the action that can be taken as follows:

• If the call is successful, gc_MakeCall( ) finishes and a GCEV_CONNECTED event is sent, call analysis runs, and generates a GCEV_MEDIADETECTED event. The gc_ResultValue( ) and gc_GetCallInfo( ) functions can then be used to get more information about the type of media detected, such as voice, answering machine, and fax. See Table 11 for details on the information being detected.
• If the call is not successful--for example, there is no ringback--a GCEV_DISCONNECTED event is generated and the gc_ResultValue( ) function can be used to retrieve the reason for the failure. See Appendix B GlobalCall Error Code and Result Value Summary in the GlobalCall API Software Reference manual and the gcerr.h file for more information.

NOTE:

The information above applies when using gc_MakeCall( ) in asynchronous or synchronous mode. However, in synchronous mode, since the gc_MakeCall( ) function must complete, the GCEV_MEDIADETECTED event is generated after the call is connected.

GCPR_MEDIADETECT parameter settings actually allow the application to specify whether pre- or post-connect call analysis or both should be activated. This method for achieving this is shown in the following table:

Table 10. GCPR_MEDIADETECT Settings

GCPR_MEDIADETECT	ISDN Result (Fixed Routing Only)	CAS Result
GCPV_DISABLE (Default)	No call progress	Pre-connect call progress only
GCPV_ENABLE	Full call progress	Full call progress

As can be seen in this table, the default behavior (GCPR_MEDIADETECT=GCPV_DISABLE) disables media detection for ISDN, but it actually activates pre-connect call progress for CAS protocols. To enable full call progress analysis for either ISDN or CAS, set the GCPR_MEDIADETECT parameter to GCPV_ENABLE for the respective channel. ISDN support is provided in fixed routing configurations only.

NOTE:

For this GlobalCall media detection to work, a voice device must be attached to the line device and properly routed. Failure to do so will cause subsequent outgoing call attempts to fail.

5.6.1. Support and Scenarios for Call Analysis with GlobalCall

Table 11 explains call analysis support via the GlobalCall interface. The table applies to DM3 CAS protocols with flexible routing clusters, providing a voice device is attached to the DTI device. The table also applies to any fixed routing configuration regardless of the protocol. DM3 CAS protocols include the PDK protocols; however, check on a protocol-by-protocol basis, as some might not support CA at all.

Table 11. CA Support in Fixed Routing and Flexible Routing with CAS

CA Feature	GC Support in R4 on DM3	How Obtained/Notes
Busy	Ö	Upon DISCONNECT event, call gc_ResultValue( ).
No Ringback	None
SIT	Ö	Upon DISCONNECT event, call gc_ResultValue( ).
No answer	Ö	Upon DISCONNECT event, call gc_ResultValue( ).
Cadence break	None	GCCT_CAD is not a supported connect type returned by gc_GetCallInfo( ).
Discarded	None	GCCT_DISCARDED is not a supported connect type returned by gc_GetCallInfo( ).
NA	Ö	Use GCPR_MEDIADETECT parameter. Upon MEDIADETECTED event, call gc_GetCallInfo( ).
Unknown	Ö	Use GCPR_MEDIADETECT parameter. Upon MEDIADETECTED event, call gc_GetCallInfo( ).
PVD	Ö	Use GCPR_MEDIADETECT parameter. Upon MEDIADETECTED event, call gc_GetCallInfo( ).
PAMD	Ö	Use GCPR_MEDIADETECT parameter. Upon MEDIADETECTED event, call gc_GetCallInfo( ).
FAX	Ö	Use GCPR_MEDIADETECT parameter. Upon MEDIADETECTED event, call gc_GetCallInfo( ).
In progress	Ö	Use GCPR_MEDIADETECT parameter. Upon MEDIADETECTED event, call gc_GetCallInfo( ).

Note that the Call Analysis timeout parameters values apply, and they are configurable by the host. However, they apply only to post-connect Call Analysis and are not used until the call moves from an initiated to proceeding, alerting, or connected state. The parameters are CaSignalTimeout, CaAnswerTimeout and CaPvdTimeout; their values are found in the CHP section of the configuration file.

The following configurable parameters are used in pre-connect Call Progress:

• StartTimeout: Set at the Initiation of a new call (outbound). Reset (disabled) after detection of a wink. This timer is set again for each wink expected (that is, if multiple winks are used, such as after dialing). If this timer expires, the call fails.
• AnswerTimeout: Set after detection of the last wink, with time to wait for the call to be answered. If timer expires, call fails. Timer is reset once the call is answered.

This functionality is determined by the protocol, and there are several configurable protocol timers that determine these values. See the DM3 Configuration File Reference for details on setting any of the above parameters.

Another option for call analysis is provided by the voice API, which provides post-connect call analysis on DM3 boards through the dx_dial( ) function. Because there currently is no alerting event to invoke dx_dial( ) under CAS, your application must wait for the connected event. Note that the GlobalCall and the dx_dial( ) methods are mutually exclusive, so you must choose one or the other.

With ISDN in flexible routing configurations, the dx_dial( ) method for call analysis must be used, and both pre-connect call progress and post-connect call analysis are available. See Section 4.6. Voice API Call Progress Analysis Support for details on dx_dial( ) support.

Click here to contact Dialogic Customer Engineering