This section addresses the following programming considerations involved in using board functions:
8.3.1. Resource AssociationEach Dialogic ISDN API line device is implemented as an association of a network time slot device. The application uses cc_Open( ) to indicate to the driver which resources to use to control a specific line.
Each PRI structure is composed of one D channel and 23 (T1) or 30 (E1) B (bearer) channels. A PRI board device, such as dtiB1, is defined as a station and controls the D channel. A PRI time slot device, such dtiB1T1, is defined as a bearer channel under a station.
Each BRI structure is composed of one D channel and two B (bearer) channels. A BRI board device, such as briS1, is defined as a station and controls the D channel the same way as a PRI board device. A BRI time slot device, such as briS1T1, is defined as a bearer channel under a station and is handled the same way as a PRI line device.
8.3.2. MAKECALL Block Initialization and SettingsBecause ISDN services vary with switches and provisioning plans, a set of default standards cannot be set for the MAKECALL_BLK. Therefore, it is up to the user application to fill in the applicable MAKECALL_BLK values that apply to the particular provisioning.
The current ISDN Call Control library will check for the ISDN_NOTUSED (0xFF) define to determine
All of the bearer capability elements in the MAKECALL_BLK structure must be specified or the ISDN library will not properly fill in the ISDN_CMD messages to pass down to the firmware. It is suggested that the application first initialize the MAKECALL_BLK structure with a set of defaults prior to filling in settings pertaining to the particular ISDN service.
A sample MAKECALL_BLK initialization is shown below:
/* Initialize the MAKECALL block */
makecall_blk.isdn.BC_xfer_cap = BEAR_CAP_SPEECH;
makecall_blk.isdn.BC_xfer_mode = ISDN_ITM_CIRCUIT;
makecall_blk.isdn.BC_xfer_rate = BEAR_RATE_64KBPS;
makecall_blk.isdn.usrinfo_layer1_protocol = 0xFF;
makecall_blk.isdn.usr_rate = 0xFF;
makecall_blk.isdn.destination_number_type = 0xFF;
makecall_blk.isdn.destination_number_plan =0xFF;
makecall_blk.isdn.destination_sub_number_type = 0xFF;
makecall_blk.isdn.destination_sub_phone_number[0] = NULL;
makecall_blk.isdn.origination_number_type = 0xFF;
makecall_blk.isdn.origination_number_plan = 0xFF;
makecall_blk.isdn.origination_sub_number_type = 0xFF;
makecall_blk.isdn.origination_sub_phone_number[0] = NULL;
makecall_blk.isdn.origination_phone_number[0] = NULL;
makecall_blk.isdn.facility_feature_service = 0xFF;
makecall_blk.isdn.facility_coding_value = 0xFF;
makecall_blk.isdn.usrinfo_bufp = NULL;
makecall_blk.isdn.nsfc_bufp = NULL;
For more on the MAKECALL_BLK structure, see Section 6.8. MAKECALL_BLK and the cc_MakeCall( ) function description in Chapter5. ISDN Function Reference.
8.3.3. Information Element SettingsThe information elements (IEs) to be passed down to the network need to conform to the switch-specific recommendations. Use the assumptions listed below when setting IEs.
Assumption 1: The customer is responsible for providing variable length IEs in ascending order in the Public part, as shown in the following table.
Table 54. Variable Length IEs
Type of IE |
Value |
Network Specific Facilities |
0x20 |
Display |
0x28 |
Signal |
0x34 |
Assumption 2: A single byte IE (with the exception of a LOCKING Shift IE) can be placed anywhere in the message. This includes Type 1 (NON-LOCKING Shift) and Type 2 elements. The NON-LOCKING shift should cause the codeshift in the forward direction only. For example, when in codeset "3," the NON-LOCKING shift should add an element in codeset "4." The following tables show the settings for Type 1 and Type 2 IEs.
Table 55. NON-LOCKING Shift IEs - Type 1
Type of IE |
Value |
Codeset |
Network Specific Facilities |
0x20 |
0 |
Shift |
0x9E |
6 (NON-LOCKING) |
IPU |
0x76 |
6 |
Display |
0x28 |
0 |
Signal |
0x34 |
0 |
Table 56. Single Byte IEs - Type 2
Type of IE |
Value |
Codeset |
Network Specific Facilities |
0x20 |
0 |
Sending Complete |
0xA1 |
0 (Single Byte IE) |
Display |
0x28 |
0 |
Signal |
0x34 |
0 |
Assumption 3: A LOCKING Shift IE must be placed after all the IEs when a lower codeset is included. A NON-LOCKING Shift IE or another LOCKING Shift IE of a greater codeset value can follow the IE. The following tables provide two options for setting LOCKING Shift IEs.
Table 57. LOCKING Shift IEs - Option 1
Type of IE |
Value |
Codeset |
Network Specific Facilities |
0x20 |
0 |
Sending Complete |
0xA1 |
0 (Single Byte IE) |
Display |
0x28 |
0 |
Signal |
0x34 |
0 |
Shift |
0x94 |
4 (LOCKING) |
IPU |
0x76 |
4 |
Shift |
0x9E |
6 (NON-LOCKING) |
DDD |
0x55 |
6 |
SSS |
0x44 |
4 |
Shift |
0x97 |
7 (LOCKING) |
ABC |
0x77 |
7 |
DEF |
0x77 |
7 |
Table 58. LOCKING Shift IEs - Option 2
Type of IE |
Value |
Codeset |
Network Specific Facilities |
0x20 |
0 |
Sending Complete |
0xA1 |
0 (Single Byte IE) |
Display |
0x28 |
0 |
Keypad Facility |
0x2C |
0 |
Shift |
0x96 |
6 (LOCKING) |
IPU |
0x76 |
6 |
Shift |
0x90 |
0 (NON-LOCKING) |
Signal |
0x34 |
0 |
ABC |
0x77 |
6 |
DEF |
0x77 |
6 |
Shift |
0x97 |
7 (LOCKING) |
ABC |
0x77 |
7 |
DEF |
0x77 |
7 |
Assumption 4: User-supplied IEs (with the exception of CHANNEL_ID_IE, see below) take precedence over the Firmware-defined IEs, even those that are in private IE parts.
Assumption 5: The CHANNEL_ID_IE will always be taken from the Firmware-defined section.
Assumption 6: When Single Byte IEs and NON-LOCKING Shift IEs occur in both the User-supplied and Firmware-defined sections, the value will be taken from the User-defined section, but it will be inserted at the position defined by the firmware, assuming that there may be specific requirements on the firmware to have the position.
For more information on setting IEs, see the cc_SetInfoElem( ) function description.
Click here to contact Dialogic Customer Engineering
Copyright 2001, Dialogic Corporation