6.3.3 Working with Fixed Routing Configurations

The following topics provide more information about using Global Call with DM3 boards that use the fixed routing configuration:

• Fixed Routing Configuration Restrictions
• gc_OpenEx( ) Restrictions (Fixed Routing)
• Associating Network and Voice Devices (Fixed Routing)
• ISDN Direct Layer 2 Access (Fixed Routing)
• Using Device Handles (Fixed Routing)
• Device Handling Guidelines for the Global Call API (Fixed Routing)
• Initializing Applications with DM3 Boards Only (Fixed Routing)
• Initializing Applications with DM3 and Springware Boards (Fixed Routing)

6.3.3.1 Fixed Routing Configuration Restrictions

The following restrictions apply to DM3 fixed routing configurations only.

Note: Except where explicitly stated, these restrictions are in addition to those described for the DM3 flexible routing configuration. See Section 6.3.2, "Working with Flexible Routing Configurations" for more information.

Table 13 shows the Global Call API Restrictions when using a DM3 boards with a Fixed Routing Configuration.

Table 13. Global Call API Function Restrictions in a Fixed Routing Configuration

Function Name	Notes
gc_AttachResource( )	Not supported. See Section 6.3.3.3, "Associating Network and Voice Devices (Fixed Routing)" for more information.
gc_Detach( )	Not supported. See Section 6.3.3.3, "Associating Network and Voice Devices (Fixed Routing)" for more information.
gc_OpenEx( )	Limitations: See Section 6.3.3.2, "gc_OpenEx( ) Restrictions (Fixed Routing)", Section 6.3.3.3, "Associating Network and Voice Devices (Fixed Routing)", and Section 6.3.3.5, "Using Device Handles (Fixed Routing)" for more information.

6.3.3.2 gc_OpenEx( ) Restrictions (Fixed Routing)

The Global Call API provides a common signaling interface for network-enabled applications, regardless of the signaling protocol needed to connect to the local telephone network. For details on the Global Call functions discussed in this chapter, see the Global Call API Library Reference.

In R4 applications that use a DM3 boards with a fixed routing configuration, it is not possible to specify the protocol and voice device in the devicename parameter in gc_OpenEx( ) commands.

The devicename can be as simple as:
:N_dtiB1T1

where N_ denotes a network time slot device, in this example, dtiB1T1.

The following restrictions apply:

• The network time slot device field (N_) is required.
• The protocol identifier field (P_), if specified, is ignored. The protocol name is unnecessary here because it is selected when using Intel® Dialogic Configuration Manager for PCD/FCD file selection. Also, for R4 on DM3 products, all protocols are bi-directional. You do not need to dynamically open and close devices to change the direction of the protocol. For R4 on earlier-generation devices, most protocols are unidirectional.
• The voice channel device field (V_), if set to a value other than the voice device automatically assigned during download, causes the gc_Open( ) command to fail. Voice devices are automatically associated with network devices as part of the cluster configuration during firmware download.

6.3.3.3 Associating Network and Voice Devices (Fixed Routing)

For applications that use Springware boards, it is possible to open a line device using the gc_OpenEx( ) function, open a voice device using the dx_open( ) function, then use the gc_AttachResource( ) function to associate the voice device with the line device, using the line device ID and the voice device handle.

For R4 applications that use DM3 boards and a fixed routing configuration, this is neither necessary nor possible. A voice device is automatically associated with a line device as part of a DM3 cluster configuration during DM3 initialization. Therefore, the gc_AttachResource( ) and gc_Detach( ) functions are not supported.

Note: Including a voice device name that is different than the voice device automatically associated with the line device, in the devicename parameter of the gc_Open( ) function returns an error.

6.3.3.4 ISDN Direct Layer 2 Access (Fixed Routing)

For applications that use a DM3 board and a fixed routing configuration, the gc_GetFrame( ) and gc_SndFrame( ) functions are supported. The DM3 firmware supports direct layer 2 access in DM3 fixed routing configurations.

6.3.3.5 Using Device Handles (Fixed Routing)

Since an R4 for DM3 application must use Global Call for call control on DM3 boards, the DM3 network interface devices must be opened with the gc_OpenEx( ) function.

Note: Where call control is not required, such as with ISDN NFAS, dt_open( ) may be used to open DM3 network interface devices.

Also, since the voice device and network interface time slot in a DM3 fixed routing configuration are permanently routed and attached to each other, TDM bus routing and attaching of the devices is unnecessary with DM3 boards. The same is true of a fax device and its network interface time slot in the DM3 fixed routing configuration. The resource device (voice/fax) and its associated DTI network interface time slot on the same physical port are tied together in a DM3 cluster. The resource channel is explicitly tied to the network interface time slot; and the voice resource cannot be shared or separately routed to another network interface device. Thus, the resource device and associated network interface device are bound together in a static link, and there is no support for routing the resource independently to the TDM bus. However, the DTI network interface can be routed to the TDM bus, allowing access to other TDM bus resources.

With the DM3 fixed routing configuration, the voice or fax resource device has no direct access to the TDM bus time slots and it is neither necessary nor possible to attach the resource and network interface devices together from the host. Therefore, in most cases, an application does not need to open the voice channel device and/or the network interface time slot device directly using the dx_open( ) and dt_open( ) functions, respectively. However, the fax device must explicitly be opened using fx_open( ). Although the fax device also has no direct access to the TDM bus time slots and therefore cannot be routed over the TDM bus, it is necessary to retrieve the fax device handle to do fax operations.

6.3.3.6 Device Handling Guidelines for the Global Call API (Fixed Routing)

The following summary applies only to a DM3 fixed routing configuration and presents some guidelines for DM3 device-handling using the Global Call API.

• Use gc_Start( ) to initialize Global Call prior to using any devices.
• Use gc_OpenEx( ) to open the voice resource and network interface devices; then use gc_GetResourceH( ), with a resourcetype of GC_VOICEDEVICE, to retrieve the voice device handle and gc_GetNetworkH( ), with a resourcetype of GC_NETWORKDEVICE to retrieve the network interface device handle.

  The gc_OpenEx( ) function internally opens the associated voice channel on DM3 boards. Do not specify the name of the voice device channel in the gc_OpenEx( ) device string. The devicename string for the gc_OpenEx( ) function should look similar to the following:
  ":N_dtiB1T1:P_ISDN"

  See Section 6.3.3.2, "gc_OpenEx( ) Restrictions (Fixed Routing)" for more information.

• Since the fax library does not support the use of a voice handle for fax commands, you cannot use the device handle from dx_open( ) to call fax API functions. You must use fx_open( ) to open a channel device for fax processing and use that fax device handle. Therefore, it is recommended that you do the following to retrieve and use the fax device handle:
  • Use ATDV_NAMEP( ) to retrieve the voice device name for the voice device handle returned by gc_GetResourceH( ) with a resourcetype of GC_VOICEDEVICE.
  • Use fx_open( ) on this voice device name to open the associated fax device and retrieve the fax device handle.
• The voice device is automatically and permanently associated with and connected to the network interface line device, so the gc_AttachResource( ) and gc_Detach( ) functions cannot be used and are not supported for DM3 boards.
• In general, when using DM3 and Springware boards, the application must use a device-discovery procedure to become hardware-aware. To perform device discovery and identify whether a logical device belongs to a DM3 board, use the gc_GetCTInfo( ) function and in the CT_DEVINFO structure check the ct_devfamily field for a value of CT_DFDM3. For details, see the CT_DEVINFO data structure description in the Voice API Programming Guide.
• Application performance may be a consideration when opening and closing devices with Global Call. If the application uses Global Call to dynamically open and close devices as needed, it can impact the application's performance. One way to avoid this is to open all DM3 devices during application initialization and keep them open for the duration of the application, closing them only at the end.

6.3.3.7 Initializing Applications with DM3 Boards Only (Fixed Routing)

This scenario is one where the application uses only DM3 boards.

SCbus routing and attaching of the devices is not necessary with DM3 hardware and the DM3 clustering scheme. The voice device and network interface time slot that share the same DM3 cluster are permanently routed and attached to each other, and the voice device has no direct access to the CT Bus time slots.

In most cases, applications do not need to open the voice channel device and/or the network interface time slot device directly using the voice and DTI APIs respectively, since it is neither necessary nor possible to attach both devices together from the host.

Furthermore, for the same reasons mentioned above, the gc_OpenEx( ) device string should not indicate the name of the voice device channel. For example, the device name string for the gc_OpenEx( ) function should look similar to the following:

":N_dtiB1T1:P_ISDN"

Although it is not necessary to specify the ISDN protocol for R4 on DM3 boards, it is specified in this example to retain compatibility with R4 on Springware boards. The gc_OpenEx( ) function will internally open the associated voice channel.

An R4 for DM3 digital interface application would typically perform the following initialization routine:

Note: Use the sr_getboardcnt( ) function with the class name set to DEV_CLASS_DTI and DEV_CLASS_VOICE to determine the number of network and voice boards in the system, respectively.

1. Start/Initialize GlobalCall with gc_Start( ).
2. Open a Global Call time slot device using gc_OpenEx( ).
3. Obtain an associated DTI time slot device handle using gc_GetResourceH( ) with a resourcetype of GC_NETWORKDEVICE.
4. Obtain an associated voice channel device handle using gc_GetResourceH( ) with a resourcetype of GC_VOICEDEVICE.
5. Repeat steps 2 to 4 for each Global Call time slot device.

6.3.3.8 Initializing Applications with DM3 and Springware Boards (Fixed Routing)

The following procedure shows how to use Global Call to initialize an application and perform device discovery when the application supports both DM3 and Springware boards:

Note: Use the sr_getboardcnt( ) function with the class name set to DEV_CLASS_DTI and DEV_CLASS_VOICE to determine the number of network and voice boards in the system, respectively.

1. Start/Initialize Global Call using gc_Start( ).
2. Open a Global Call time slot device using gc_OpenEx( ).
3. Obtain an associated DTI time slot device handle using gc_GetResourceH( ) with a resourcetype of GC_NETWORKDEVICE.
4. Call gc_GetCTInfo( ) and check CT_DEVINFO.ct_devfamily value:
   • If ct_devfamily value is CT_DFDM3, then obtain associated voice channel device handle using gc_GetResourceH( ) with a resourcetype of GC_VOICEDEVICE, and flag all the Global Call time slot devices associated with the trunk as DM3 type.
   • Otherwise, open the standard R4 voice device and obtain a device handle. Attach the standard R4 voice channel device to the Global Call time slot device using gc_AttachResource( ).
5. Repeat steps 2 to 4 for all Global Call time slot devices.

Click here to contact Telecom Support Resources