HOWTO

Installation of SX2 ISDN cards and controller number assignment (kb4293)

The information in this article applies to:

  • SwyxWare 2011
  • SX2 QuadBRI V2
  • SX2 DualPRI V2
  • SX2 DualPRI
  • SX2 SinglePRI
  • SX2 QuadBRI

[ Summary | Information ]


Summary

This article describes the installation of SX2 ISDN boards and the controller number assignment.


Information

Installing  SX2 ISDN Boards

  • Windows detects new Hardware and starts Install new Hardware dialogue
    (A unique Hardware ID is created from the combination of the board´s PCI ID and the PCI slot ID. That is also the reason why Windows detects the ISDN card as new hardware, in case the card is put into another PCI slot)
  • User selects a path where The SX2 driver can be found  (sx2.inf und data.cab)
  • Windows checks if the driver is valid for the installed Hardware and installs the driver. All driver files from data.cab are copied to their respective folders. 
  • Windows also stores a copy of the *.inf and eventually the whole driver package to be able to install the driver automatically in case the hardware is detected again.( e.g. with server 2008) 
  • Card installation is completed by starting the SX2 coinstaller DLL (%windir%\System32\Swyx\sx2conf_w.x.y.z.dll)
  • which creates the registry path HKLM\SOFTWARE\CAPI20, if it doesn´t exist already and looks for already installed CAPI devices. If no entries are found the board ID 1 will be assigned to the newly installed card or otherwise the largest found value+1 will be assigned. After that the SX2 CoInstaller will generate new entries using this Board ID and also stores this Board ID in the registry.

 

Taking the new card in service

Windows loads SX2 driver

  • SX2 driver is then called with a refrence to the new Hardware.
  • Driver reads BoardID vom Hardware related registry hive whre it has been stored by the CoInstaller.
  • Driver creates a "functional device object" with \device\CAPI20x where x is the Board ID.
  • Windows is starting up the device.
  • After the ISDN board is started the driver checks if a boardID has been set up manually using the DIP switches. If so, the driver overwrites the former BoardID.
  • Driver creates the device file \DosDevices\CAPI20y where y is the boardID.
  • This File can now be used by an application to communicate with the driver or the ISDN board respectively.

Taking the Swyxware 2011 Gateway in service

  • after the restart the gateway will enumerate all ISDN boards and create a port mapping table BoardID ⇔ controller number
  • When the gateway becomes active, the card configuration is written into the data base (selector is the gateway´s hostname)
  • SwyxWare administration then reads these values from the db when configuring the trunks and displays the boardID/PortID assignments grafically so that they can be easily selected.
  • after the gateway has received a trunk configuration, it will check if the controller number is unique (update scenario).
  •  in this case it detects the respective BoardID/PortID and writes these values back into the db, so that these steps won´t be performed at every startup.
  • if the trunk is taken in service for the first time, the gateway will also check, if there are controller specific registry entries. If so, they are also stored in the db (expert configuration).
  • The registry entries however will be kept so that they can be reused for newly created trunks in the future, but they do not have any influence on the trunk configuration anymore. 

 

Standby

  •  in a standby scenario the trunk configuration is replicated to the standby gateway  (to be precise, it uses the hostname of the master gateway for database queries). Therefore in a standby configuration, a trunk must always be created with the active master gateway. For this reason the boardID/PortID must be identical on both gateways. 
  • This was the same in former versions of Swyxware , but refered to the controller number. 
 
Enumeration of the controller number
 
  • refer to http://www.capi.org
    For aplications there should be an intermediate layer (CAPI2032.DLL) which hides the device files and makes the CAPI devices accessible via so called controller numbers.
  • Controller number start with 1
  • Controller numbers are assigned following the order of the boardIDs. The controller numbers are incremented for each Port  
     
Example
 
BoardId Type of board Number of ports Controller number
1 QuadBRI 4 Controller 1 - 4
2 DualPRI 2 Controller 5 - 6
3 SinglePRI 1 Controller 7
15 DualPRI 2 Controller 8 - 9


If a card is being disabled or  removed from the system, the subsequent cards will be newly enumerated,
 

 
Example - DualPRI (boardID 2) is removed
 
BoardId Type of board Number of ports Controller number
1 QuadBRI 4 Controller 1 - 4
3 SinglePRI 1 Controller 5
15 DualPRI 2 Controller 6 - 7


For this reason Swyxware 2011 has changed from controller number to a combination of BoardID and local PortID when configuring trunks.

In contrast to the controller number these parameters do not change anymore after installation. Additionally in master-standby scenarios it is much easier to assign the same boardID to the cards on both gateways which can then be used in trunk configuration. 
 
For further information please refer to http://www.capi.org/download/capi20-2.pdf

Comment

Comment on this article



If we have any follow-up questions, where can we contact you?

E-Mail Address (optional)


Note

This feedback form can't be used for support requests. Those requests must be directed to your Swyx reseller or distributor.