Dialogic® DSI SPCI Network Interface Boards
Programmer's Manual
March 2009 U03HSP
www.dialogic.com
Copyright and Legal Notice
Copyright © 1993-2009 Dialogic Corporation. All Rights Reserved. You may not reproduce this document in whole or in part without
permission in writing from Dialogic Corporation at the address provided below.
All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a
commitment on the part of Dialogic Corporation or its subsidiaries (“Dialogic”). Reasonable effort is made to ensure the accuracy of the
information contained in the document. However, Dialogic does not warrant the accuracy of this information and cannot accept
responsibility for errors, inaccuracies or omissions that may be contained in this document.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC
BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN
A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS
ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR
WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL
PROPERTY RIGHT OF A THIRD PARTY.
Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility
applications.
Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific
countries, and thus may not function properly in other countries. You are responsible for ensuring that your use of such products occurs
only in the countries where such use is suitable. For information on specific products, contact Dialogic Corporation at the address
indicated below or on the web at www.dialogic.com.
It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing
collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual property rights
owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic products other than a
license to use such product in accordance with intellectual property owned or validly licensed by Dialogic and no such licenses are
provided except pursuant to a signed agreement with Dialogic. More detailed information about such intellectual property is available
from Dialogic’s legal department at 9800 Cavendish Blvd., 5
users of its products to procure all necessary intellectual property licenses required to implement any concepts or
applications and does not condone or encourage any intellectual property infringement and disclaims any responsibility
related thereto. These intellectual property licenses may differ from country to country and it is the responsibility of
those who develop the concepts or applications to be aware of and comply with different national license requirements.
Dialogic, Dialogic Pro, Brooktrout, Diva, Cantata, SnowShore, Eicon, Eicon Networks, NMS Communications, NMS (stylized), Eiconcard,
SIPcontrol, Diva ISDN, TruFax, Exnet, EXS, SwitchKit, N20, Making Innovation Thrive, Connecting to Growth, Video is the New Voice,
Fusion, Vision, PacketMedia, NaturalAccess, NaturalCallControl, NaturalConference, NaturalFax and Shiva, among others as well as
related logos, are either registered trademarks or trademarks of Dialogic Corporation or its subsidiaries. Dialogic's trademarks may be
used publicly only with permission from Dialogic. Such permission may only be granted by Dialogic’s legal department at 9800
Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic's trademarks will be subject to full
respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogic’s trademarks requires proper
acknowledgement
Windows is a registered trademark of Microsoft Corporation in the United States and/or other countries. Other names of actual
companies and products mentioned herein are the trademarks of their respective owners.
This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to
use open source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic responsible
for any present or future effects such usage might have, including without limitation effects on your products, your business, or your
intellectual property rights.
Publication Date: March 2009
Document Number: U03HSP, Issue 5
2
th
Floor, Montreal, Quebec, Canada H4M 2V9. Dialogic en cou ra g es all
®
PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED,
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
Contents
Revision History ........................................................................................................... 6
1 Introduction ........................................................................................................ 7
1.1 Related Documentation............................................................................................................ 7
2 Specification ........................................................................................................ 8
2.1 Product Identification .............................................................................................................. 8
2.2 Capability .............................................................................................................................. 8
2.3 License Buttons ...................................................................................................................... 8
2.3.1 Run Modes ............................................................................................................ 8
2.3.2 Capacity ............................................................................................................ 9
3 Installation........................................................................................................ 10
3.1 Introduction ......................................................................................................................... 10
3.2 Hardware configuration ......................................................................................................... 11
3.2.1 Board Option Switch / Link Settings ............................................................................ 11
3.3 Software Installation for Windows® ......................................................................................... 11
3.3.1 Installing Development Package for Windows® ............................................................. 11
3.3.2 Starting the Windows® Device Driver .......................................................................... 12
3.3.3 Clearing Windows® 2000 Install Wizard ....................................................................... 13
3.3.4 Removing Development Package for Windows® ............................................................ 14
3.4 Software Installation for Linux ................................................................................................ 14
3.4.1 Installing Development Package for Linux .................................................................... 14
3.4.2 Device Drivers from Source Code................................................................................ 15
3.4.3 Verifying Device Driver Loading .................................................................................. 16
3.5 Software Installation for Solaris .............................................................................................. 16
3.5.1 Installing the Development Package for Solaris ............................................................ 16
3.5.2 Solaris 9 - Interface Name Checking ........................................................................... 17
3.5.3 Solaris 10 - Additional Commands .............................................................................. 17
3.5.4 Non-serviced interrupts reports .................................................................................. 17
3.5.5 Removing the Development Package for Solaris ........................................................... 18
4 Configuration and Operation ............................................................................. 19
4.1 Overview ............................................................................................................................. 19
4.1.1 System Structure ..................................................................................................... 19
4.2 System Configuration ............................................................................................................ 21
4.2.1 System Configuration File Syntax ............................................................................... 21
4.2.2 Generating a System Configuration File ....................................................................... 22
4.3 Protocol Configuration ........................................................................................................... 24
4.3.1 Protocol Configuration using the s7_mgt utility ............................................................. 24
4.3.2 Protocol Configuration Using Individual Messages ......................................................... 24
4.4 Board Information Diagnostics ................ ................................................................................ 26
4.5 Geographic Addressing .......................................................................................................... 27
4.6 Watchdog Timer ................................................................................................................... 27
4.7 Using the CT bus .................................................................................................................. 27
4.7.1 Switching Model ....................................................................................................... 28
4.7.2 Static Initialization .................................................................................................... 28
4.7.3 Dynamic Operation ................................................................................................... 29
4.7.4 Example Code - Building and Sending SC_LISTEN ........................................................ 29
5 Program Execution ............................................................................................ 32
5.1 Program Execution under Windows® ........................................................................................ 32
5.2 Program Execution under Linux .............................................................................................. 33
5.3 Program Execution under Solaris ............................................................................................ 34
3
Contents
5.4 Developing a User Application ................................................................................................ 34
6 Message Reference ............................................................................................ 36
6.1 Overview .......................................... ................................................................................... 36
6.1.1 General Configuration Messages ................................................................................. 36
6.1.2 Hardware Control Messages ....................................................................................... 36
6.1.3 MTP Interface Messages ............................................................................................ 37
6.1.4 Event Indication Messages ......................................................................................... 37
6.1.5 Message Summary Table ........................................................................................... 37
6.2 General Configuration Messages ............................................................................................. 39
6.2.1 SSD Reset Request ................................................................................................... 39
6.2.2 Board Reset Request................................................................................................. 40
6.2.3 Board Status Indication ............................................................................................. 42
6.2.4 Board Configuration Request ...................................................................................... 43
6.2.5 General Module Identification Message ........................................................................ 49
6.2.6 Read Board Info Request Message .............................................................................. 50
6.3 Hardware Control Messages ................................................................................................... 53
6.3.1 LIU Configuration Request ......................................................................................... 53
6.3.2 LIU Control Request .................................................................................................. 57
6.3.3 LIU Read Configuration Request ................................................................................. 59
6.3.4 LIU Read Control Request .......................................................................................... 60
6.3.5 LIU State Request .................................................................................................... 61
6.3.6 LIU CT bus Initialization Request ................................................................................ 62
6.3.7 CT bus Listen Request ............................................................................................... 65
6.3.8 Fixed Data Output Request ........................................................................................ 67
6.3.9 Reset Switch Request ............................................................................................... 68
6.3.10 CT bus Connect Request ............................................................................................ 69
6.3.11 Configure Clock Request............................................................................................ 74
6.3.12 Configure Clock Priority Request ................................................................................. 77
6.4 Event Indication Messages ..................................................................................................... 79
6.4.1 Board Status Indication ............................................................................................. 79
6.4.2 s7_mgt Completion Status Indication .......................................................................... 80
6.4.3 Clock Event Indication .............................................................................................. 81
6.4.4 LIU Status Indication ................................................................................................ 83
6.4.5 Error Indication ........................................................................................................ 84
6.4.6 MTP2 Level 2 State Indication .................................................................................... 86
6.4.7 MTP2 Q.752 Event Indication ..................................................................................... 87
6.4.8 MTP3 Q.752 Event Indication ..................................................................................... 89
7 CONFIGURATION COMMAND Reference ............................................................. 91
7.1 Physical Interface Parameters ................................................................................................ 91
7.1.1 SS7_BOARD Command ............................................................................................. 91
7.1.2 LIU_CONFIG Command ............................................................................................. 93
7.1.3 LIU_SC_DRIVE Command ......................................................................................... 95
7.1.4 SCBUS_LISTEN Command ......................................................................................... 96
7.2 MTP Parameters ................................................................................................................... 97
7.2.1 MTP Global Configuration .......................................................................................... 97
7.2.2 MTP Link Set .......................................................................................................... 98
7.2.3 MTP Signaling Link ................................................................................................... 98
7.2.4 MTP Route ........................................................................................................ 100
7.2.5 MTP User Part ........................................................................................................ 102
7.3 ISUP Parameters ................................................................................................................ 102
7.3.1 Global ISUP Configuration ....................................................................................... 102
7.3.2 ISUP Circuit Group Configuration .............................................................................. 103
7.4 TUP Parameters .................................................................................................................. 105
7.4.1 Global TUP Configuration ......................................................................................... 105
7.4.2 TUP Circuit Group Configuration ............................................................................... 106
4
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
8 Host Utilities ................................................................................................... 108
8.1 ssds .................................................................................................................................. 108
8.1.1 Description ........................................................................................................ 108
8.1.2 Syntax ........................................................................................................ 108
8.1.3 Command Line Options ........................................................................................... 108
8.2 s7_mgt .............................................................................................................................. 109
8.2.1 Description ........................................................................................................ 109
8.2.2 Syntax ........................................................................................................ 109
8.2.3 Command Line Options ........................................................................................... 109
8.2.4 Example ........................................................................................................ 110
Tables
Table 1: SPCI Network Interface Board Capability ................................................................................. 8
Table 2: Relationship between License Button Codes, Run Modes and Protocol Modules ............................. 9
Table 3: Protocol Dimensioning .......................................................................................................... 9
Table 4: Files Installed on a System Running Windows
Table 6: Files Installed on a System Running Linux ............................................................................. 15
Table 7: Files Installed on a System Running Solaris ........................................................................... 17
Table 8: Typical Telephony Systems Configurations ............................................................................ 19
Table 9: Host Processes and Utilities ................................................................................................. 20
Table 10: Board Diagnostics – Hardware Parameters ........................................................................... 26
Table 11: Message Summary ........................................................................................................... 37
®
...................................................................... 12
5
Revision History
Revision History
Issue Date Description
A 12-Apr-00 Initial release for evaluation purposes. Some sections incomplete.
B 20-Apr-00 Several minor corrections es pecially relating to LIU configuration and
switching. Addition of installation section for Windows
1 30-Jul-01 Sections detailing support for Windows
®
2000, Linux and Solaris added.
Additional messages to read LIU state, indicate clock events and s7_mgt
completion status.
2 06-Jan-03 Branding changed to Intel
®
NetStructure™. Septel PCI now SPCI4 / SPCI2 S
and Septel cP now CPM8. References to NUP pr otocol removed.
INAP_API.LIB added.
3 23-May-05 Remove INAP_API module.
Change name of package in Solaris DPK to <dpksol32.Z / dpksol64.Z >.
Add geographic addressing, gctload as a service, watchdog time r, Linux
driver source code release.
Added board Option Switch / Link settings, General Module Identification
Message and Read Board Info Request Message and Set on-board LED's
Message.
Add capacity section and support for Windows
4 05-Mar-09 Removed CPM8 specific content as product is now EOL.
Updated to Dialogic
®
branding. Refreshed operating system support and
documented new “bundled” license button set and corresponding ru n
modes.
5 20-Mar-09 Clarification to ISUP-S and TUP-S protocol dimensioning.
®
XP.
®
NT.
Note: Current software and documentation supporting Dialogic
®
DSI SPCI Network
Interface Boards is available at:
http://www.dialogic.com/support/helpweb/signaling
6
1 Intr oduct ion
The range of Dialogic® DSI SPCI Network Interface Boards includes
specialized T1/E1 SS7 signaling boards for use in PCI host computer systems.
All boards offer a common interface to the application allowing applications to
be easily ported between hardware architectures. This Programmer’s Manual
relates to the low density Dialogic
Dialogic
contains an embedded signaling processor capable of handling up to 4 SS7
signaling links and runs software which is downloaded onto the board at run
time.
The boards provide a suitable hardware platform for running the Dialogic
DSI protocol for realizing Signaling System Number 7 signaling nodes. The
boards can be used under any of the following operating systems: Windows
2000, Windows
document the term "Windows
Windows
This document is the Dialogic
Programmer’s Manual and it is targeted at system developers who choose to
integrate the boards in a host computer and to develop applications that
make use of the underlying SS7 protocol stack. The Programmer's Manual
includes information on software installation, system configuration, protocol
configuration, and operation of the board and SS7 software stack.
The Programmer's Manual should be used in conjunction with the appropriate
Installation Guide and Regulatory Notice for the board, the Dialogic
Environment Programmer's Manual and the Programmer’s Manuals for the
individual protocol modules as detailed in section 1.1.
High Density board ranges SS7HD and SS7MD are not covered by this
manual, and users should refer instead to the relevant documentation
package.
®
DSI SPCI2S Network Interface Boards. Each low density board
®
2000 and the Windows® XP operating systems.
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
®
DSI SPCI4 Network Interface Boards and
®
XP, Linux and Solaris. Throughout the remainder of this
®
" may be used to collectively refer to the
®
DSI SPCI Network Interface Boards
®
®
®
Software
1.1 Related Documentation
64-0393-xx Dialogic® DSI SPCI Network Interface Boards Installation Guide
®
60-1554-xx Dialogic
U10SSS - Dialogic
Environment Programmer's Manual
05-2331-xx - Dialogic
05-2471-xx - Dialogic
U04SSS - Dialogic
U09SSS - TUP Programmer’s Manual
U32SSS - Dialogic
DSI SPCI Regulatory Notices
®
Distributed Signaling Interface Components - Software
®
SS7 Protocols MTP2 Programmer’s Manual
®
SS7 Protocols MTP3 Programmer’s Manual
®
SS7 Protocols ISUP Programmer's Manual
®
DSI Protocol Stacks - Host Licensing User Guide
7
2 Specification
2 Specification
2.1 Product Identification
The product designations are as follows:
®
• Dialogic
• Dialogic
and two serial interfaces
Throughout this manual the term "SPCI" is used to refer (individually and/or
collectively, depending on context) to either or both such type of boards.
2.2 Capability
Table 1: SPCI Network Interface Board Capability
Number of: SPCI4 SPCI2S
T1/E1 links 4 2
V.11 / V.35 synchronous serial interfaces 0 2
H.100 Computer Telephony bus (CT bus) 1 1
SS7 links 4 4
DSI SPCI4 Network Interface Boards – Four T1/E1 interfaces
®
DSI SPCI2S Network Interface Boards – Two T1/E1 interfaces
2.3 License Buttons
The ss7.dc3 codefile supports different protocol module combinations that are
enabled by fitting the correct license button to the board. Each license button
is marked with a two letter code that is used for identification.
2.3.1 Run Modes
The run_mode parameter in either the SS7_BOARD command or the Board
Reset Request message determines the protocol modules that are started by
the code file at run time. The following table shows the relationship between
the license buttons and the supported run modes.
8
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
Table 2: Relationship between License Button Codes, Run Modes and Protocol Modules
Run Modes supported
Button Code
MM SS7SBPCIMONQ Monitoring 4
M3 SS7SBPCIMTPQ MTP 4
T1 SS7SBPCIISTUPSQ ISUP, TUP (Small) 2
T2 SS7SBPCIISTUPQ ISUP, TUP (Regular) 4
T4 SS7SBPCIISTUPLQ ISUP, TUP (Large) 4
Item Market Name
2.3.2 Capacity
The figures in the table below indicate the capacity for modules running on
the DSI SPCI Boards.
Table 3: Protocol Dimensioning
Capacity
Maximum
Number of Link
Run Mode
MTP3 4 64
ISUP-S 2 64 44 1024
TUP-S 2 64 44 1024
ISUP 4 64 64 2048
TUP 4 64 64 2048
ISUP-L 4 64 128 4096
TUP-L 4 64 128 4096
Sets
Description
Maximum
Number of
Routes
MTP2
MTP3
Maximum Number
of SS7 Links
√ √
√ √ √
√
√ √
√
√ √ √ √
Maximum
Number of
Circuit Groups
ISUP
ISUP-S
ISUP-L
√
Maximum
Numbers of
Circuits
TUP-S
√
TUP
TUP-L
MON
√
√
√
√
9
3 Installation
3 Inst a lla t i on
3.1 Introduction
This Programmer's Manual covers the installation and use of the software
contained in the following distributions:
• Development Package for Windows
• Development Package for Linux
• Development Package for Solaris
• User Part Development Package
• Code Files for Dialogic
protocols).
Each Development Package contains the device driver, library functions,
and header files for use by an application, a number of executables to be run
as part of the software environment, and a utility to configure the protocol
software. The installation of each package type is described in the following
sections.
The User Part Development Package contains example source code to
illustrate the techniques used for interfacing with the protocol modules and
protocol-specific header files for use when building an application. It is
distributed as a zip file and a tar file, and is applicable to all supported
operating systems. Extract the contents of the User Part Development
Package onto the development machine maintaining the sub-directory
structure.
The Code File contains the operating software for the DSI SPCI Boards. It is
in the form of a single binary file, which is downloaded by the host, to the
board, at run-time. Code Files all have a file suffix .dc3 and must not be
confused with code files for other products which use different suffixes. A
single SS7 Code File (ss7.dc3) includes SS7 protocol options (MTP, ISUP and
TUP). The Code File is used in conjunction with a software license button,
which is purchased and installed on the board to determine the protocols that
the user is authorized to run. The types of license buttons available are
described above. It is subsequently downloaded onto the board at run time.
Some SS7 protocols may also, optionally, be run as Host Protocol Binaries
subject to the purchase of appropriate licenses. Transferring some of the
work to the host allows the user to optimize system performance.
The Development Package, Code File and the User Part Development
Package may be obtained by downloading it from the Dialogic website at:
http://www.dialogic.com/support/helpweb/signaling.
They must be copied onto the target host machine maintaining binary file
integrity; possible transfer methods include copying using transferable media
and ftp.
®
®
DSI SPCI Network Interface Boards (various
10
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
3.2 Hardware configuration
3.2.1 Board Option Switch / Link Settings
The DSI SPCI Boards contain some switches and links used to establish
optional settings at the time of installation in a host. These must be set as
follows:
• CT Bus termination links - full details of how to use these links is provided
in the relevant board Installation Guide.
• BOOT Mode option switch - ensure the switch is set to the default setting
of "8".
• ADDR Switch - the default setting for this switch is "0", and is commonly
used, but see section 4.5 on Geographic Addressing
of this switch.
3.3 Software Installation for Windows®
The Development Package for Windows® is distributed electronically. The
distribution is in the form of a single self extracting binary named
DPKWIN.EXE. This binary can be run directly from a hard disk.
for alternative usage
3.3.1 Installing Development Package for Windows®
If the development package is to be used with a board then the board must
be installed before installation of the Development Package to ensure that the
driver is correctly loaded.
Before installing a new release of the Development Package, it is necessary to
remove any previous release of the package. Refer to instructions in section
3.3.4 Removing Development Package for Windows®
The installation must be performed by a user with Administrator privileges.
Before performing the installation, close all other applications.
To perform the installation, run the self-extracting binary DPKWIN.EXE. The
installation procedure prompts for an installation directory. The default
directory is c:\septel. If required, the default directory can be modified.
The following files (or similar) are transferred to the installation directory.
Note that a number of additional files relating to other products in the range
are installed at the same time.
.
11
3 Installation
Table 4: Files Installed on a System Running Windows®
Name Description
gctlib.lib Library to be linked with user's application (Microsoft*).
gctlibb.lib Library to be linked with user's application (Borland*).
INC Sub-directory containing include files.
system.txt Example system configuration file.
config.txt Example protocol configuration file.
gctload.exe
ssds.exe
s7_mgt.exe
s7_log.exe
s7_play.exe
tick_nt.exe
tim_nt.exe
servcfg.exe
gctserv.exe
mtpsl.exe
upe.exe
Executables for use as described elsewhere in this
manual.
The installation process automatically installs the device driver so the setup
program must be allowed to reboot the target machine when it has finished
installing the package.
Installation is now complete, although the device driver is not yet running.
The files the user needs to use, have been installed in the installation
directory. It is recommended that the user does not modify any files in this
directory, but instead creates a working directory into which all the necessary
files are copied.
If the machine is a development machine without any target boards, then no
further installation is required.
12
3.3.2 Starting the Windows® Device Driver
The device driver is initially installed as "Manual", it must therefore be
manually started by a user with Administrator privilege using the following
procedure:
1) Select the Control Panel (Start Æ Settings Æ Control Panel).
2) Select the "System" icon. In the "system properties" select the
"Hardware" tab and then select "Device manager". A tree of device nodes
is presented.
3) From the toolbar select "View Æ ShowHiddenDevices": Open the "Non
Plug and Play Drivers" device node branch. The "Septel" driver should be
displayed. If the board was not present at install of the Development
Package the device node may not be visible, this issue can be resolved by
starting the driver interface at a command prompt using the command:
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
Net start Septel
After rebooting the interface will be displayed as expected.
4) Right click on the "Septel" driver and select "Properties" and then select
the "Driver" tab.
5) The driver can be started immediately by selecting "start" in the "current
status" field.
Note: To automatically start the driver at system startup, select the "Automatic" option
from the "Startup" menu. The system must be re-started for this change to take
effect. It is strongly recommended that automatic startup be NOT enabled until
the correct operation has first been verified using manual startup.
On some systems, when using DSI SPCI Boards, the device driver does not
get registered. It may be necessary to manually start the driver using the
command "net start septel".
3.3.3 Clearing Windows® 2000 Install Wizard
The Windows® 2000 system may fail to fully recognize that the board is
controlled by the driver. It may consequently produce an "Install Wizard"
window for each board that is present at system boot.
This "Install Wizard" window may be quit without any problems; however, the
user may choose to use this work around to prevent the "Install Wizard"
window being presented, thereby removing the need for manual intervention:
1) Select the Control Panel (Start Æ Settings Æ Control Panel).
2) Select the "System" icon. In the "system properties" select the
"Hardware" tab and then select "Device manager". A tree of device nodes
is presented.
3) Open the "Other Devices" branch. One "Network Controller" is listed for
each installed SS7 board.
Note: Additional Network Controllers may be listed for other non-WDM
boards in the system, in which case the user must identify which belongs to
each resource.
4) "Disable" and then "enable" each of these "Network Controller". This is
achieved by right clicking on the device.
5) Reboot the system.
The "Install Wizard" window will no longer be presented for the device.
13
3 Installation
3.3.4 Removing Development Package for Windows®
Prior to installing a new version of the Development Package for Windows®,
the previous package must be removed as follows. This procedure requires a
user with Administrator privilege.
1) Select the Control Panel (Start Æ Settings Æ Control Panel).
2) Select "Add/Remove Programs".
3) Scroll down the devices and select "SS7 Development Package" and
select "Remove".
4) When package removal is confirmed, restart the target machine.
3.4 Software Installation for Linux
The Development Package for Linux is distributed electronically. The
distribution is in the form of a single compressed file called dpklnx6.Z.
3.4.1 Installing Development Package for Linux
Install the Development Package as follows:
1) Login and switch to a user account with root privileges.
2) Create a new directory on the development system to act as the root
directory for the software. This directory is referred to as the install
directory.
3) Copy the dpklnx6.Z file to the install directory. Take care to ensure
binary file integrity is maintained and the ".Z" file suffix remains in upper
case.
4) Extract the files using the command:
tar --no-same-owner -zxvf dpklnx6.Z
The following files (or similar) are extracted into the current working
directory. Note: additional files and directories relating to other products in
the range are installed at the same time.
14
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
Table 5: Files Installed on a System Running Linux
Name Description
gctlib.lib Library to be linked with user's application.
system.txt Example system configuration file.
config.txt Example protocol configuration file.
gctload.exe
ssds.exe
s7_mgt.exe
s7_log.exe
s7_play.exe
tick_nt.exe
tim_nt.exe
upe.exe
INC Sub-directory containing header files for use with user’s
SPCI_CPM_DRIVER Source code for the SPCI Network Interface Board
Executables for use as described elsewhere in this
manual.
application.
drivers.
The procedure to build and install these is described in
section 3.4.2.
3.4.2 Device Drivers from Source Code
When the package is unloaded the source code for the driver for the DSI SPCI
Boards is found in the subdirectory named SPCI_CPM_DRIVER. This source
code must be built for the required Kernel version as described below.
A build script, named build_spci_cpm.sh, is included in this subdirectory. To
build the driver, run this script.
This build script assumes a suitable environment for building Kernel modules
is available. This must include the appropriate Kernel include files being found
at: /usr/src/linux-`uname -r`/include.
(e.g., /usr/src/linux-2.4.7-10/include). If these are not found, the build
will fail.
Some Linux installations do not create a system source directory with the
required name, for example some SMP kernels do not create a directory with
the required smp suffix. If this is the case, then a softlink needs to be created
to give an appropriate path to the system header files. For example:
cd /usr/src
ln –s linux-2.4.27 linux-2.4.27smp
Some later version of Linux uses a revised format for the remap_page_range
parameters (for example Red Hat Linux Kernel Versions greater than 2.4.20
require this revised format). The build script supports an optional new_remap
parameter. If this parameter is set, the compile uses the revised format.
The build script supports an optional clean parameter that removes the
driver and all intermediate files.
Under some versions of Linux a warning similar to the following is generated:
warning: changing search order for system directory.
15
3 Installation
3.4.3 Verifying Device Driver Loading
This warning can be safely ignored.
For compatibility with the pre-built drivers the existing name format is
retained for Linux 2.4 drivers e.g., sptcpi-2.4.18-14smp.o. However, this
name format causes problems under Linux Kernel version 2.6; therefore, all
Linux 2.6 drivers are named sptpci26.ko.
An install script, named install_spci_cpm.sh, is included in the package.
This script installs the device driver, automatically allocates the major device
numbers, and creates the four appropriate device nodes. This replaces the
manual procedures to perform these operations, as described above.
The install script supports an optional remove parameter. This causes the
device driver to be removed and the device nodes to be deleted.
The installation must be performed by a user with root privileges.
When the device driver is loaded it outputs status messages to the system
log.
The system log is displayed using the command:
dmesg | more
An example message is:
sptpci V1.06
Copyright (C) 2000-2007 Dialogic Corporation. All rights
reserved.
Using major device number 127.
sptpci Device Id 0 @ Bus: 1 Device: 9 Function: 0
3.5 Software Installation for Solaris
The Development Package for Solaris is distributed electronically. The
distribution is in the form of two compressed files called dpksol32.Z and
dpksol64.Z for use with 32 bit or 64 bit kernels respectively.
The Development Package is suitable for use in the following configurations:
• Solaris 9 (32 and 64 Bit)
• Solaris 10 (32 and 64 bit)
3.5.1 Installing the Development Package for Solaris
Copy the appropriate file to the Solaris system. Take care to ensure the
binary file integrity is maintained and the ".Z" file suffix remains in upper
case.
The file must then be uncompressed and installed as shown below.
Note: This installation must be performed by a user with root privileges.
uncompress <dpksol32.Z / dpksol64.Z>
pkgadd –d <dpksol32 / dpksol64>
The Solaris package installation utility (pkgadd) prompts for further input.
16
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
On successful completion of the installation procedure, the following message
is displayed, and the user needs to reboot the system.
Installation of DKseptel was successful.
The following files (or similar) are transferred into the /opt/DKseptel
directory.
Note: Additional files relating to other products in the range are installed at the same
Table 6: Files Installed on a System Running Solaris
time.
Name Description
libgctlib.so
libgctlib.so.1
libgctlib.so.1.0.1
INC Sub-directory containing header files for use with user’s application.
system.txt Example system configuration file.
config.txt Example protocol configuration file.
gctload.exe
ssds.exe
tick_sol.exe
tim_sol.exe
s7_mgt.exe
s7_log.exe
upe.exe
Library to be linked with user's application.
Executables for use as described elsewhere in this manual.
3.5.2 Solaris 9 - Interface Name Checking
To use the package under Solaris 9, interface name checking must be
disabled. This is done by adding the following line to the /etc/system file:
set sunddi_netifname_constraints=0
The driver will not start properly if this line is not added.
3.5.3 Solaris 10 - Additional Commands
Customers using Solaris 10 must perform the following additional commands
after installing the package:
cd/opt/DKseptel
chown root ssdh
chmod +s ssdh
Note: The commands should be executed by a user with super-user permissions.
3.5.4 Non-serviced interrupts reports
Some systems exhibit problems due to non-serviced interrupts being reported
by the system. The problem can result in large numbers of event reports that
can impact the system performance.
The DSI SPCI Board drivers included in this package include an optional
work-around to eliminate these problems.
17
3 Installation
3.5.5 Removing the Development Package for Solaris
To enable this functionality the following line must be added to the
/etc/system file:
set sptpci:spt_claimint=1
The system has to be rebooted to force the change to take effect.
The Development Package for Solaris is removed using the package removal
utility:
pkgrm <dpksol32 / dpksol64>
The Solaris package removal utility (pkgrm) then prompts for further input.
On successful completion of the procedure the following message is displayed
and the user should reboot the system:
Removal of <dpksol32 / dpksol64> was successful.
18
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
4 Configuration and Operation
4.1 Overview
Prior to performing software configuration, the user should gain an
appreciation of:
• the flexibility of the protocol stack,
• the run-time options that exist,
• the mechanisms used to select particular features.
This section gives an overview of these aspects.
The user should also consult the Software Environment Programmer’s
Manual, which describes the basic principles of modules and message
passing.
4.1.1 System Structure
The SS7 software running on the board communicates with an application
running on the main CPU of the host computer. The physical interface to the
board uses the PCI bus. All communication with the board is handled by a
device driver and the messages passing to and from the board are managed
by a process (ssds) that runs on the host computer.
In addition to running the application on the host computer, the user may,
depending on the size of the overall system and the network topology, elect
to also run some of the SS7 protocol modules on the host. In such cases, the
interface between the application and the SS7 protocol software remains
identical. This allows for easy migration from a small system contained on a
single board to a large system distributed over many boards with minimal
changes to the application. When a protocol is run on the host, it is necessary
to purchase and install a Software License on the host.
The table illustrates some possible system configurations for a telephony
system.
Table 7: Typical Telephony Systems Configurations
Small System Medium System Large System
Software running on
the board
Software running on
Host Computer
Number of boards
MTP2
MTP3
ISUP / TUP
User Application ISUP / TUP
Single Single signaling
MTP2
MTP3
User Application
board (additional
boards may
support voice only)
MTP2
MTP3
ISUP / TUP
User Application
Multiple
19
4 Configuration and Operation
The following abbreviations are used in the table:
MTP2
MTP3
ISUP
TUP
Message Transfer Part – Level 2
Message Transfer Part – Level 3
ISDN User Part
Telephony User Part
In all cases, the process called ssds (SS7 Software Driver) must be run on
the host computer. This handles message transfer between the host and the
board using the device driver.
To define which protocol modules run on the host, edit the text file
system.txt.
Run the program gctload, which reads the system configuration parameters
from the file system.txt and starts up the selected processes bringing the
system into operation.
For further details of gctload, refer to the Software Environment
Programmer’s Manual.
The following processes for use on the host are included in the distribution.
All must be run on the host with the exception of s7_mgt, s7_log, and
s7_play, which are optional:
Table 8: Host Processes and Utilities
Name Description
gctload Process to initialize the system environment and start up all other related
ssds Process to interface with the device driver for passing messages to and from
tick_nt
tick_lnx
tick_sol
tim_nt
tim_lnx
tim_sol
s7_mgt Process to perform single shot protocol configuration for all protocol modules,
s7_log Utility process to allow messages received from the protocol stack to be
s7_play Utility process used to generate messages from a text file and send them into
processes running on the host, deriving the configuration from a text file
(system.txt).
the board(s) and for downloading software to the board(s).
Protocol timer process to send periodic “tick” notification to the tim_xxx
process which in turn handles protocol timers.
Process to receive periodic tick notification from tick_xxx and handle protocol
timers for all other processes.
deriving the configuration parameters from a text file (config.txt). This process
is optional. As an alternative to using it, the user may elect to perform
protocol configuration by sending messages directly to the other modules in
the system.
logged to a text file. This is useful for diagnostic purposes.
the system.
20
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
4.2 System Configuration
System configuration is handled by the program gctload, which reads the
system configuration data from a file called system.txt. This file must be
edited to reflect the requirements of your system, prior to running gctload.
System initialization requires first that a pool of message buffers is created
for subsequent inter-process communication. Secondly, that a message
queue is created for each process that runs and that any message redirection for modules that are running remotely is initialized. Then all
processes can be started.
The program gctload exists to handle this initialization sequence and to
create the inter-process communication environment. It reads input from the
text file called system.txt, carries out all system initialization and starts up
all processes. system.txt is a user configurable file containing details of all
the module identifiers known to the system, details of whether they are local
modules or remote modules accessed by a local module (message
redirection), and lists the command line for all processes to be started by
gctload.
gctload creates a message queue for each of the local module identifiers. It
subsequently expects a process to service its message queue otherwise
messages written to that queue will never be read, causing eventual loss of
system messages.
gctload initializes the message queue look-up table so that messages
destined for modules that do not exist locally are re-directed to a message
queue for a module that does exist locally.
Having created the system environment, gctload proceeds to spawn all
processes listed in the system.txt file in the order listed.
4.2.1 System Configuration File Syntax
The system configuration file system.txt is a text file used by gctload to
configure the software environment.
The file syntax permits the use of comments to improve the readability of the
file. Comments are inserted into the file by using an asterisk *; all characters
on the line after the asterisk are ignored.
Numbers can be entered in either decimal or hexadecimal format.
Hexadecimal numbers must be prefixed with 0x. For example, the value
eighteen can be entered in either of the following formats:
0x12 *(Hexadecimal)
18 *(Decimal)
The System Configuration File contains the following commands:
a) LOCAL commands to allow gctload to generate message queues
for modules running locally.
b) REDIRECT commands to cause messages generated for modules
not running locally to be redirected via a module that is running
locally.
c) FORK_PROCESS commands advising gctload of any processes
that need to be started locally.
21
4 Configuration and Operation
The full syntax of each command is listed in the Software Environment
Programmer’s Manual.
An example system.txt file is shown below:
*
* Example system.txt for the Development Package for Windows®.
*
* Edit this file to reflect your configuration.
*
* Essential modules running on host:
*
LOCAL 0x20 * ssd/ssds - Board interface task
LOCAL 0x00 * tim_nt - Timer task
*
* Optional modules running on the host:
*
LOCAL 0xcf * s7_mgt - Management/config task
LOCAL 0x2d * upe - Example user part task
*
* Modules running on the board (all redirected via ssd):
*
* REDIRECT 0x23 0x20 * ISUP module
* REDIRECT 0x4a 0x20 * TUP module
REDIRECT 0x22 0x20 * MTP3 module
REDIRECT 0x71 0x20 * MTP2 module
REDIRECT 0x10 0x20 * CT bus/Clocking control module
REDIRECT 0x8e 0x20 * On-board management module
*
* Redirection of status indications:
*
REDIRECT 0xdf 0x2d * LIU/MTP2 status messages -> upe
REDIRECT 0xef 0x2d * Other indications -> upe
*
* Now start-up all local tasks:
*
FORK_PROCESS ssds.exe
FORK_PROCESS tim_nt.exe
FORK_PROCESS tick_nt.exe
FORK_PROCESS s7_mgt.exe
FORK_PROCESS upe.exe
*
22
4.2.2 Generating a System Configuration File
This section describes the procedure for generating a system configuration
file (system.txt) and details any operating system specific differences in
behaviour of the development packages.
First, the file must contain LOCAL declarations for all modules that run on the
host computer. As a minimum this must include the SSDS module and the
timer module. Hence the following declarations must exist:
LOCAL 0x20 * ssd / ssds - Board interface task
LOCAL 0x00 * tim_xxx - Timer task
LOCAL declarations are required for any optional modules that run on the
host. Typically, this includes s7_mgt and the user's own application module.
It may also include host-based protocol modules and the s7_log utility. For
example:
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
LOCAL 0xcf * s7_mgt - Management/config task
LOCAL 0x2d * upe - Example user part task
LOCAL 0x3d * s7_log - Prints messages to screen/file
After the LOCAL declarations, REDIRECT commands are added for modules
that run on the board so that messages destined for these modules are
transported via ssds (module_id = 0x20) and the device driver, to the board.
These REDIRECT commands are always required:
REDIRECT 0x71 0x20 * MTP2 module
REDIRECT 0x10 0x20 * CT bus/Clocking control module
REDIRECT 0x8e 0x20 * On-board management module
Further REDIRECT commands are required for protocols chosen to run on the
board. This typically includes MTP3 and one or more user parts. For example:
REDIRECT 0x23 0x20 * ISUP module
REDIRECT 0x4a 0x20 * TUP module
REDIRECT 0x22 0x20 * MTP3 module
Next, ensure status indications issued from the board can arrive at a module
running on the host. (If this does not happen, the system will quickly run out
of available messages for inter-process communication).
Two module_id's (0xdf and 0xef) require redirection to a suitable process
running on the host. Initially these messages should be redirected to the
s7_log utility, which prints out a line for each message received. Ultimately,
the user's own application will expect to receive these notifications.
REDIRECT 0xdf 0x3d * LIU/MTP2 status messages -> s7_log
REDIRECT 0xef 0x3d * Other indications -> s7_log
Include FORK_PROCESS commands for all modules that run on the host
computer.
All systems require ssds, tim, and tick modules to be run.
®
For Windows
, these FORK_PROCESS commands are mandatory:
FORK_PROCESS ssds.exe
FORK_PROCESS tim_nt.exe
FORK_PROCESS tick_nt.exe
For Linux, these FORK_PROCESS commands are mandatory:
FORK_PROCESS ssds
FORK_PROCESS tim_lnx
FORK_PROCESS tick_lnx
For Solaris, these FORK_PROCESS commands are mandatory:
FORK_PROCESS ssds
FORK_PROCESS tim_sol
FORK_PROCESS tick_sol
Finally, include FORK_PROCESS commands for any modules chosen to run on
the host (e.g., protocol modules, user's application or diagnostic utilities). For
example:
FORK_PROCESS s7_mgt
FORK_PROCESS upe
FORK_PROCESS s7_log
23
4 Configuration and Operation
4.3 Protocol Configuration
The Development Package contains a protocol configuration utility, s7_mgt
which performs initialization of all the software modules running on the
signaling board. It reads the protocol configuration data from a text file called
config.txt and provides a quick and flexible method of configuring the
protocol modules without the need to write software for that purpose.
Alternatively, the protocol stack may be configured by sending individual
configuration messages documented in the per-module Programmer’s
Manuals to each protocol module. This approach is of particular use if the
application needs to reset the board and run a new configuration without
stopping the application program. It is described in section 4.3.2 Protocol
Configuration Using Individual Messages.
4.3.1 Protocol Configuration using the s7_mgt utility
The default configuration file used by s7_mgt is config.txt. The -k option
allows the user to specify an alternative filename if required. For example:
s7_mgt -kmyconfig.txt
The format of the configuration commands is described in Appendix A.
s7_mgt can optionally be configured to send a message to a nominated
module on completion of the configuration sequence. This option is activated
using the –i option to specify the receiving module_id. For example:
s7_mgt –i0xef
To assist problem diagnosis, run s7_mgt using the –d option, and additional
diagnostic output will be generated. For example:
s7_mgt –i0xef -d
See section 4.4 Board Information Diagnostics
, for diagnostic output format.
24
4.3.2 Protocol Configuration Using Individual Messages
As an alternative to using the s7_mgt configuration utility it is possible to
carry out the protocol configuration by building and sending messages
directly to the board. This approach does mean that it is necessary to write
some application code to handle the configuration but has the advantage that
the application can, if required, re-configure the board without re starting the
application.
All communication with the board is in the form of sending and receiving
messages. The configuration sequence is described in the following section.
The application must allocate a message structure using the library function
getm() and send it to the board using the library function GCT_send(). The
application must periodically call the library function GCT_receive() or
GCT_grab() in order to receive messages from the board. GCT_receive() will
block until a message is available whilst GCT_grab() will return immediately.
Once the application has finished processing the received message, it must
release the message structure back to the system by calling the library
function relm(). The library functions are all described in the Software
Environment Programmer's Manual.
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
To configure the board using individual messages, the following sequence
must be used. (The format of all the messages is described in Section 5 of
this manual):
1) Build and send an SSD Reset Message.
This contains the parameters to initialize the ssds module.
2) Build and send a Board Reset Message for each board.
This includes the id of the board and the name of the Code File.
It causes the board to be reset and the Code File downloaded.
3) Wait until a Board Status Message is received (for each board).
Inspect the status field to determine whether the reset was successful.
On failure you should check carefully the parameters and try again.
On success continue to the next step.
4) Build and send a Board Configuration Message. This contains all
mandatory protocol configuration parameters for the Message Transfer
Part (MTP)
(such as point codes, physical link settings and MTP configuration
parameters).
5) Wait until a Board Configuration Confirmation M e ss age is received.
Inspect the status field which is zero on success.
On failure re-check the configuration parameters and go back to resetting
the board.
6) Optionally, send LIU Configuration Request Messages for each T1/E1
line interface unit on the board to configure the appropriate operating
mode.
Ensure the status field is zero in the confirmation message.
7) Optionally, send MTP Config Route Messages for any remote signaling
points (other than adjacent signaling points. The route configuration for
adjacent signaling points is automatically set up using the board
configuration message). Ensure the status field is zero in the confirmation
message.
8) If a user part (e.g., ISUP or TUP) is included in the Code File, build and
send the per-module configuration message (as defined in the
Programmer’s Manual for the User Part Module). Ensure the status field is
zero in the confirmation message.
9) If a user part is included, build and send circuit group configuration
messages for each circuit group (as defined in the Programmer’s Manual
for the User Part Module). Ensure the status field is zero in the
confirmation message.
10) The protocol stack is now configured ready for use (the same as if the
configuration utility s7_mgt had been used). The user must send an MTP
Activate Signaling Link message for each signaling link to start up SS7
operation.
25
4 Configuration and Operation
4.4 Board Information Diagnostics
To assist in diagnosis of configuration problems and reporting hardware
details when encountering problems, a diagnostic display feature is available
in s7_mgt.
When s7_mgt is run with the –d command line option, a diagnostic display of
board hardware parameters is generated in this format following
configuration of the board.
S7_MGT Board identification: board_id 0
Board type: 2 (SPCI)
Hardware revision: 0
RAM size: 0x00000000
Interface type: 0
RTB switch: 0
ADDR switch: 0
BOOT switch: 8
Shelf: 0
Slot: 0
Firmware: V1.02
Electronic serial number: 01-000007e09eb9-8a
License serial number: 02-0000008c92f7-72
The parameters are as described below:
Table 9: Board Diagnostics – Hardware Parameters
26
Parameter Description
Board type Board types are rep orted as follows:
2 SPCI2S or SPCI4
Hardware revision The board hardware revision number.
RAM size The on-board RAM size.
Interface type Parameter not supported for DSI SPCI Boards. Value
returned equals 0.
RTB switch Parameter not supported for DSI SPCI Boards. Value
returned equals 0.
ADDR switch Geographic addressing switch setting, that is, the
address at which the board appears when the –o3
feature of ssds is used.
BOOT switch The setting of the board's rotary switch labeled “Boot”.
Default setting - 8.
Shelf Parameter not supported for DSI SPCI Boards. Value
returned equals 0.
Slot Parameter not supported for DSI SPCI Boards. Value
returned equals 0.
Firmware Firmware revision number.
Electronic serial number The board's electronic serial number.
License serial number License serial number. The serial number of the fitted
license button (all zero's if none found).
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
4.5 Geographic Addressing
Geographic Addressing allows the logical position of a board (or board_id) in
a system to remain the same irrespective of the addition or removal of other
boards on the PCI bus. Two address modes are supported:
• PCI address mode – (default) addressing determined by enumerating
boards on the PCI bus at boot time (i.e., the default order found by the
operating system).
• Switch address mode - determined by a 16 position ADDR switch on the
board.
The configuration of Geographic Addressing is controlled by command line
parameters to the ssds utility. See section 8.1 ssds
4.6 Watchdog Timer
An optional host to board watchdog timer may be configured. This allows the
board to detect a failure of the host software. If such a condition is detected,
then the board goes into a reset state. This prevents a condition whereby the
software on the host has stopped running but the boards still presents an "inservice" condition to the remote end.
This functionality is controlled by command line parameters to the ssds
utility. See section 8.1 ssds
for details.
for details.
4.7 Using the CT bus
The SPCI2S and SPCI4 boards support two or four T1/E1 Line Interface Units
and a CT bus interface (H.100) respectively. The on-board signaling processor
handles the SS7 signaling timeslots whilst the remaining circuits (voice or
data bearer circuits) are passed to the CT bus for distribution to other boards.
All communication between the application and the board is message-based.
Initial configuration is usually handled by the configuration utility s7_mgt,
which takes commands from the text file (config.txt) and generates all the
necessary configuration messages for the board. Subsequent operation is
entirely message driven, messages being passed in both directions between
the board and the application.
One of the roles of the application is to control the dynamic switching
between the CT bus and the T1/E1 line interfaces. This section provides
details of how to interface with the CT bus, including the initial (static)
configuration and the subsequent (dynamic) switching.
The operation of the CT bus switching interface is described in terms of the
SCbus switching model using the messages MVD_SC_DRIVE_LIU,
MVD_MSG_SC_LISTEN and MVD_MSG_SC_FIXDATA and config.txt
commands LIU_SC_DRIVE and SCBUS_LISTEN.
27
4 Configuration and Operation
4.7.1 Switching Model
The basic switching model assumes that at system initialization all incoming
T1/E1 timeslots and all resource board output timeslots are connected up to
channels on the CT bus and that these connections are never changed. This
has the advantage that once the on-board CT bus drivers have been set up
they are never changed so the chances of inadvertently causing CT bus
conflict is minimized. It also means that the user can predict the exact CT bus
channels where any input timeslot can be located and this in turn can assist
with fault diagnosis and general system test.
It is also possible to generate fixed patterns on any T1/E1 output timeslots to
provide the correct idle pattern for presentation to the network on all circuits
where there is no active call.
Having completed the system initialization, all drives to the CT bus are set
up. Then, on a dynamic (call by call) basis, the connectivity must be modified
when a new call arrives and when it finishes.
When a new call arrives, the application, in general, needs to initiate two
listen commands. One command causes the resource to listen to the
appropriate CT bus channel to hear the incoming voice path and the other
causes the T1/E1 interface to listen to the output from the resource board to
generate the outgoing voice path.
When a call clears, the application needs to initiate generation of the fixed
idle pattern towards the network operation (and may wish to connect an idle
pattern to the resource board).
28
4.7.2 Static Initialization
Static initialization is handled by the s7_mgt utility. For each T1/E1 line
interface unit, user must include an LIU_SC_DRIVE command in the
config.txt file. The syntax for this command is detailed in appendix A.
The LIU_SC_DRIVE command has several parameters. board_id and
liu_id together uniquely identify the affected line interface unit. sc_channel
is the channel number of the first channel on the CT bus that is to be used for
timeslots from the specified LIU. ts_mask is a mask identifying which
timeslots on the T1/E1 interface are carrying voice circuits (as opposed to
signaling) and therefore need to be connected to the CT bus. The least
significant bit of ts_mask must always be zero when driving from an T1/E1
interface.
As an example, consider a two board system where the first board has 4 E1
ports and the second board has 4 T1 ports. We allow the first 512 CT bus
channels to be used by other boards in the system and therefore start at
sc_channel 512.
Dialogic® DSI SPCI Network Interface Boards Programmer's Manual Issue 5
LIU_SC_DRIVE 0 0 512 0xfffefffe * 30 E1 voice ccts on ts 1..15 &
17..31
LIU_SC_DRIVE 0 1 542 0xfffefffe * 30 E1 voice ccts on ts 1..15 &
17..31
LIU_SC_DRIVE 0 2 572 0xfffefffe * 30 E1 voice ccts on ts 1..15 &
17..31
LIU_SC_DRIVE 0 3 602 0xfffefffe * 30 E1 voice ccts on ts 1..15 &
17..31
LIU_SC_DRIVE 1 0 632 0x00fffffe * 23 T1 voice ccts on timeslots
1..23
LIU_SC_DRIVE 1 1 655 0x00fffffe * 23 T1 voice ccts on timeslots
1..23
LIU_SC_DRIVE 1 2 678 0x00fffffe * 23 T1 voice ccts on timeslots
1..23
LIU_SC_DRIVE 1 3
701 0x00fffffe * 23 T1 voice ccts on timeslots
1..23
4.7.3 Dynamic Operation
The application controls dynamic changes to CT bus switching by sending the
MVD_MSG_SC_LISTEN message to the board. This message is documented
in chapter 5 Program Execution
on the T1/E1 interface and the CT bus channel number (sc_channel) to
which the timeslot listens. The message is directed to the correct board by
calling the GCT_set_instance function prior to calling GCT_send.
When a new call arrives, the application needs to instigate 2 listen commands
(although they do not necessarily both apply to the SS7 board). One connects
the voice circuit in the forward direction and the other connects it in the
backward direction.
When a call terminates, the application must issue a fixed data message to
ensure the network port sees the voice idle pattern.
. It contains the liu_id, the timeslot number
4.7.4 Example Code - Building and Sending SC_LISTEN
/*
* Example function for building and sending an MVD_MSG_SC_LISTEN
* message to a SPCI2S or SPCI4 signalling board.
*
* The only change that the user needs to make is to fill in the
* OUR_MOD_ID definition below so that is equal to the module_id
* of the application module.
*/
#define OUR_MOD_ID (0xef)
#include "system.h" /* Definitions of u8, u16 etc */
#include "msg.h" /* Definitions of HDR, MSG etc */
#include "libc.h" /* Used only for memset prototype */
#include "sysgct.h" /* Prototypes for GCT_xxx */
29
4 Configuration and Operation
#include "pack.h" /* Prototypes for rpackbytes */
#include "ss7_inc.h" /* Message & module definitions */
/*
* Macro to generate the value for use in the rsp_req field of the
* message header in order to request a confirmation message:
*/
#define RESPONSE(module) (((unsigned short) 1) << ((module) & 0x0f))
/*
* Function to drive an SCbus / CT bus timeslot
* onto a timeslot on a PCM port:
*/
int listen_to_scbus(board_id, liu_id, timeslot, sc_channel)
int board_id; /* board_id (0, 1, 2 ...) */
int liu_id; /* PCM port id (*/
int timeslot; /* Timeslot on the PCM port (1 .. 31) */
int sc_channel; /* SCbus / CT bus channel number */
{
MSG *m;
u8 *pptr;
/*
* Allocate a message (and fill in type, id, rsp_req & len):
*/
if ((m = getm(MVD_MSG_SC_LISTEN, 0, RESPONSE(OUR_MOD_ID), MVDML_SCLIS) )
!= 0)
{
pptr = get_param(m);
memset(pptr, 0, m->len);
/*
* Enter the parameters in machine independent format:
*/
rpackbytes(pptr, MVDMO_SCLIS_liu_id, (u32)liu_id, MVDMS_SCLIS_liu_id);
rpackbytes(pptr, MVDMO_SCLIS_timeslot, (u32)timeslot,
MVDMS_SCLIS_timeslot);
rpackbytes(pptr, MVDMO_SCLIS_sc_channel, (u32)sc_channel,
MVDMS_SCLIS_sc_channel);
m->hdr.dst = MVD_TASK_ID;
30
Loading...