Previous PageTable Of Contents../index.htmlIndexNext Page



5.9. ISDN Feature Implementation and Support

The following information describes the implementation of ISDN-specific features using R4 for DM3 and any feature limitations.

For applications that use ISDN protocols, a pointer to a MAKECALL_BLK data structure, defined in the cclib.h header file, can be provided in the cclib field of the GC_MAKECALL_BLK data structure. The following parameters in the MAKECALL_BLK data structure are not supported :

The destination_number_type and origination_number_type parameters support the following values only:

NOTE:
If a GC_MAKECALL_BLK structure is not specified, the default values are taken from the FCD (Feature Configuration Description) file; see the DM3 Configuration File Reference.

See the GlobalCall ISDN Technology User's Guide for more information.

NOTE:
Neither the gc_MakeCall( ) function nor the gc_SetParm( ) function can be used to modify these parameters.

The gc_GetNetCRV( ) function is supported, but must be manually enabled for use.

In Linux, to enable this function, add CC.NetCRV Support = 1 in /usr/dialogic/cfg/cheetah.cfg. To subsequently disable this function, remove this line from the .cfg file.

In Windows, to enable this function, set parameter NetCRV Support to 1 in Key HKEY_LOCAL_MACHINE\SOFTWARE\Dialogic\Cheetah\CC. To subsequently disable this function, set this parameter to 0.

For applications that use ISDN protocols, the gc_SndMsg( ) function supports only the following values for the msg_type parameter

See the GlobalCall ISDN Technology User's Guide for more information.

The Send Any IE (Info Element) and Send Any Message features, provided by the gc_SetInfoElement( ) and gc_SndMsg( ) functions, are supported by all call control functions, except gc_ReleaseCall( ). The Receive Any IE and Receive Any Message features are supported in R4 on DM3 in the same manner as in R4 on earlier-generation products.

To activate overlap send and prevent the automatic sending of a Sending Complete IE within the SETUP message, the following modifications should be made to the config file for the desired outbound protocol variant requiring overlap send support. The CalledNumberCount parameter, which has a default value of zero, should be set to a large positive value. For example, in the ISDN Protocol Variant Definitions section of the configuration file being used, change:

NOTE:
You can have more than one CalledNumberCount setting per board, in order to do so, please create a new Variant Define and apply that define using the defineBSet command in the respective TSC section.

See the DM3 Configuration File Reference for more information on how to perform the changes outlined above.

A gc_MakeCall( ) function call that specifies fewer digits than the CalledNumberCount results in the sending of a SETUP message that does not contain a Sending Complete IE. If more digits are specified, the Sending Complete IE is included in the SETUP message.

The function gc_SendMoreInfo( ) is not supported, so to send extra digits, the application should wait for the GCEV_SETUP_ACK event, which indicates the inbound side acknowledges the SETUP message, construct an IE block containing the digits to be sent, and then call gc_SndMsg(GlobalCallDeviceHandle, CRN, SndMsg_Information, &IEBlock) to send the digits. Even after sending a number of digits greater than CalledNumberCount, the Sending Complete IE is not sent automatically.

The following is an example of how to send extra digits using overlap send:

NOTE:
Any changes to the CONFIG file for a particular protocol requires the regeneration of the FCD file and the subsequent downloading of the firmware to the boards. The FCDGEN tool, available in the dialogic\bin directory, is used to convert a CONFIG file to an FCD file.

R4 on DM3 supports direct layer 2 access on a per trunk basis. Direct layer 2 access is enabled by including the following command in the appropriate [CSS.x] section of the config file, where x identifies a specific trunk (span):

If this command is not included, direct layer 2 access is disabled. Also, using a 0 instead of a 1 in the command above disables direct layer 2 access.

NOTE:
Any changes to the CONFIG file for a particular protocol requires the regeneration of the FCD file and the subsequent downloading of the firmware to the boards. The FCDGEN tool, available in the dialogic\bin directory, is used to convert a CONFIG file to an FCD file. For more information, see the DM3 Configuration File Reference.

GlobalCall supports direct layer 2 access using the gc_GetFrame( ) and gc_SndFrame( ) functions.

In R4 on DM3, a GCEV_D_CHAN_STATUS event is always generated once the board device is initialized and the initial D channel status is known. The resulting value associated with the event indicates this initial D channel status. Any subsequent change in the D channel status is also notified by means of GCEV_D_CHAN_STATUS event. In R4 on earlier-generation boards, when the initial D channel status was UP, no initial event was generated. In R4 on DM3, an initial event is always generated, regardless of the initial status of the D channel.

On download, by default both the trunk and channels are out of service. When the first gc_Open( ) or gc_OpenEx( ) is executed on a device, the trunk (D channel) and the channel (B channel) associated with the device are placed into service (trunk in service, channel idle). Although the channel is IDLE, calls cannot be received/processed until gc_WaitCall( ) is issued. When the application uses gc_Close( ) to close the channel, the channel returns to out of service, but the trunk remains in service.

The application should use the gc_ResultValue( ) function to find the reason (UP or DOWN) associated with the GCEV_D_CHAN_STATUS event. A reason of UP indicates that the D channel is active and the gc_GetFrame( ) and gc_SndFrame( ) functions can be used to get or send frames respectively. The gc_GetLinedevState( ) function can be used to retrieve the status of the line device.

See the GlobalCall API Software Reference for more information.

Regarding B channel state, the initial channel state (in service or out of service) is controlled by a CHP parameter (parameter 0x1311) in the CONFIG file. By default, all channels are out of service when a system is initialized. Thereafter, when the application issues gc_WaitCall( ) the channel (line device) is placed into service. If gc_ResetLineDev( ) is subsequently issued, the channel is placed out of service until the application issues gc_WaitCall( ) again.

Also on the channel devices, if gc_WaitCall( ) is not issued but gc_MakeCall( ) is issued, the channel is placed into service for the duration of the call. Once the call is released, the channel is once again out of service.


Previous PageTable Of ContentsTop Of PageIndexNext Page

Click here to contact Dialogic Customer Engineering

Copyright 2002, Intel Corporation
All rights reserved
This page generated February, 2002