Dialogic DSI SPCI Network Interface Boards For Linux, these Forkprocess commands are mandatory

Page 23

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

Page 22 Page 24
Image 23
Page 22 Page 24
Contents March Dialogic DSI Spci Network Interface BoardsCopyright and Legal Notice Contents Message Reference Configuration Command ReferenceHost Utilities 108 TablesRevision History Related Documentation IntroductionLicense Buttons SpecificationProduct Identification CapabilityCapacity Protocol DimensioningIntroduction InstallationInstalling Development Package for Windows Hardware configurationSoftware Installation for Windows Board Option Switch / Link SettingsName Description Files Installed on a System Running WindowsStarting the Windows Device Driver Clearing Windows 2000 Install Wizard Removing Development Package for Windows Software Installation for LinuxInstalling Development Package for Linux Device Drivers from Source Code Files Installed on a System Running LinuxAn example message is Software Installation for SolarisInstalling the Development Package for Solaris Verifying Device Driver LoadingSolaris 9 Interface Name Checking Solaris 10 Additional CommandsNon-serviced interrupts reports Files Installed on a System Running SolarisRemoving the Development Package for Solaris System has to be rebooted to force the change to take effectSystem Structure Configuration and OperationTypical Telephony Systems Configurations OverviewTelephony User Part Following abbreviations are used in the tableHost Processes and Utilities Isdn User PartSystem Configuration File Syntax System ConfigurationGenerating a System Configuration File For Solaris, these Forkprocess commands are mandatory For Linux, these Forkprocess commands are mandatoryProtocol Configuration Using Individual Messages Protocol ConfigurationProtocol Configuration using the s7mgt utility Page Parameter Description Board Information DiagnosticsBoard Diagnostics Hardware Parameters Parameters are as described belowGeographic Addressing Watchdog TimerUsing the CT bus Static Initialization Switching ModelExample Code Building and Sending Sclisten Dynamic OperationMSG Page To run the system within the current console, enter Program ExecutionProgram Execution under Windows To run it in the background enter Program Execution under LinuxDeveloping a User Application Program Execution under SolarisNmake /f ctu.mnt Hardware Control Messages General Configuration MessagesMessage Reference Message Summary MTP Interface MessagesEvent Indication Messages Message Summary Table0x3e18 SSD Reset Request General Configuration MessagesStatus Response Board Reset RequestNumboards Runmode Parameter Description BoardtypePhyid CodefileFormat Board Status IndicationValue Meaning Board Configuration RequestField Name Meaning Type MGTMSGCONFIG0 0x7F10 Src Description Event TypeMaxsiflen Parameter Description Isolated from the other boards using the CT bus. The CT busMessage Reference Bit Data Rate Value Description Minrev General Module Identification MessageParameter Description Majrev Major revision identifier for the object being queriedText Read Board Info Request MessageSPCI2S or SPCI4 board Field Name Meaning Type Mgtmsgrbrdinfo 0x6f0d SrcValue Mnemonic Meaning Prommajrev BoardrevSwa SwbDst Mvdtaskid Rspreq LIU Configuration RequestField Name Meaning Type Liumsgconfig 0x7e34 Hardware Control MessagesFrameformat LiutypeLinecode Line coding technique taken from the following tableNfaw CrcmodeBuildout FawRaigen Description RaigenClearmask Field Name Meaning Type Liumsgcontrol 0x7e35 LIU Control RequestParameter Description Aisgen Loopmode Description Diagnostic loop back mode taken from the following tableLoopmode LIU Read Configuration Request LIU Read Control Request Offset Size Name State LIU State RequestState Description LIU CT bus Initialization RequestParameter Description State Current state of the LIU from the following tableField Name Meaning Type Mvdmsgscdriveliu 0x7e18 Src Parameter Description LiuidScchannel TsmaskMode Value Mnemonic Description 0xff None Setup failedOffset Size Name Liuid Timeslot Scchannel CT bus Listen RequestMvipinvalidtimeslot TimeslotOffset Size Name Liuid Timeslot Pattern Fixed Data Output RequestPattern Reset Switch RequestCT bus Connect Request Mvdmsgscconnect 0x7e1f Field Name MeaningLocalslot If a parameter is not required, it must be set to zeroLocalstream CT bus speed Source Slot Range SourcestreamSourceslot Destslot DeststreamField Name Meaning Type Mvdmsgcnfclock 0x7e20 Src Configure Clock RequestParameter Description Busspeed Value Bus speed No change Value Clock ModeClkmode PllclksrcRef1mode Value NETREF1 clock ModeField Name Meaning Type Mvdmsgclockpri 0x7e21 Src Configure Clock Priority RequestParameter Description Liunpri Event Indication Messages Parameter Description Board Status 2 s7mgt Completion Status IndicationField Name Meaning Type Mvdmsgclkind 0x0e23 Src Result of initial configuration coded as followsClock Event Indication Parameter Description Completion StatusParameter Description Event ID Field Name Meaning Type Mvdmsgliustatus 0x0e01 Liuid Src LIU Status IndicationLiustatus Status field in the message header is coded as followsValue Mnemonic State Error IndicationError Code is coded as shown in the following table Parameter Description Error CodeParameter Description Link State 6 MTP2 Level 2 State IndicationEvent Code is coded as shown in the following table 7 MTP2 Q.752 Event IndicationParameter Description Event Code Abatement of signaling link congestion Excessive delay of acknowledgementExcessive error rate Suerm Onset of signaling link congestionOffset Size Name Len Event specific parameters 8 MTP3 Q.752 Event IndicationMtpevajspok Value Mnemonic Paramter DescriptionPhysical Interface Parameters Configuration Command Reference1 SS7BOARD Command Bit CT Bus Clocking Mode Runmode Protocols selected to Run on the Board Liuconfig CommandFrameformat Frame format taken from the following table Crcmode CRC mode taken from the following tableBoardid Liuscdrive CommandScbuslisten Command Options MTP Global ConfigurationMTP Parameters Reserved1, reserved2MTP Link Set MTP Signaling LinkBlink LinkidLinkref SlcBlink Serial Port MTP RouteDpc NormlsUserpartmask SecondlsMTP User Part Global Isup ConfigurationIsup Parameters Isup Circuit Group Configuration Variant CicmaskUserinst OpcTUP Parameters Global TUP ConfigurationGlobal configuration parameters for the TUP module Configuration parameters for a group of TUP circuits TUP Circuit Group Configuration107 Description Command Line OptionsHost Utilities SsdsMmodule id Kconfig fileS7mgt Inotify module id Example

DSI SPCI Network Interface Boards specifications

Dialogic DSI SPCI Network Interface Boards are highly advanced and versatile communication solutions tailored for the demands of modern telephony and multimedia applications. These boards are designed to efficiently process voice, data, and signaling, making them an essential component for businesses looking to enhance their communication capabilities.

One of the standout features of the Dialogic DSI SPCI boards is their ability to handle multiple telephony protocols. This flexibility allows users to connect to various network types, whether PSTN, VoIP, or legacy systems, ensuring seamless interoperability. The boards support industry-standard protocols such as ISDN, SS7, and SIP, enabling integrated communication across diverse platforms.

The technology behind the Dialogic DSI SPCI boards incorporates state-of-the-art digital signal processing (DSP). This powerful DSP architecture provides efficient encoding and decoding of voice and video signals, leading to enhanced call quality and reduced latency. Moreover, the DSP technology supports advanced codecs, ensuring that voice communication is clear and intelligible, even over bandwidth-limited connections.

Another significant characteristic of these boards is their scalability. Organizations can start with a single board and expand their telecommunication capabilities as their needs grow. This scalability makes them suitable for a wide range of applications, from small businesses to large enterprises, allowing for easy integration into existing infrastructures.

In addition to their powerful processing capabilities, Dialogic DSI SPCI boards also prioritize reliability and robustness. They are designed with a focus on fault tolerance, ensuring that telephony services remain uninterrupted even in the event of hardware failure. This resilience is critical for mission-critical applications where downtime can lead to significant revenue loss.

Furthermore, the boards feature extensive application development support. Developers can leverage the Dialogic API and various development kits to create custom telephony applications that meet specific business requirements. This programmability opens the door to innovative solutions, such as interactive voice response (IVR) systems, automated call distribution (ACD), and customer relationship management (CRM) integration.

In summary, Dialogic DSI SPCI Network Interface Boards are a cornerstone for organizations looking to innovate their telecommunication systems. With their support for multiple protocols, advanced DSP technology, scalability, reliability, and development support, these boards empower businesses to optimize their communication strategies and adapt to the evolving landscape of digital interaction.
Top Page Image Contents