ISDN Stack Code

This page provides a roadmap to the STREAMS ISDN Stack code. This code presented here is a (possibly outdated) snap-shot of our OpenSS7 working directories. This is provided for browsing only to get a feel for the OpenSS7 stack code. Please read our licensing terms before using any of the code viewed here.

STREAMS ISDN Stack Code

The main directory for the LiS STREAMS version of OpenSS7 can be viewed here. Or, you can select one of the specific modules from the diagram below, or from the section headings of the list below:

ISDN Q.931 Call Control

ISDN Q.933 Call Control

X.213 Network Services Part

Integrated Digital Loop Carrier

Digital Private Network/Accss Subscriber System (DPNSS/DASS)

ISDN Q.921 (LAPD)

ISDN Q.921 (LAPD) is an integral part of the OpenSS7 stack. This multiplexing driver permits LAPD users to open LAPD data link provider streams and bind them to local DLSAPs. It fully supports connectionless and connection oriented delivery.

THe ISDN Q.921 (LAPD) multiplexing driver has High-Level Data Link Control (HDLC) streams linked underneath it by the ISDN configuration daemon, either statically or dynamically. LAPD users can also onpen and link HDLC streams for their own use. Linked streams can he any stream providing services of the Communications Device Interface (CDI) in the same manner as the HDLC stream.

The ISDN Q.921 (LAPD) multiplexing driver handles full LAPD procedures including manual and automatic assignment of terminal endpoint identifiers (TEI) and automatic (TEI) audit procedures.

The ISDN Q.921 (LAPD) multiplexing driver is used primarily in direct support of ISDN Q.931. You can review the LAPD code here.

ISDN Q.922 (LAPF)

X.25 (LAPB)

V5.2/GR-303 Data Link

DPNSS/DASS Data Link

High-Level Data Link Control (HDLC)

ISDN Stack manager

BICC Multiplexing Driver Code

BICC (Bearer Independent Call Control) is a relatively new addition to the OpenSS7 SS7 stack. This multiplexing driver permits BICC users to open BICC streams and bind them to BICC Circuit Identifier ranges between specific Local and Remote Point Codes. This permits a BICC user stream to represent a BICC "Trunk Group".

This multiplexing driver has MTP streams linked underneath it by the SS7 Configuration Daemon, either a priori or on demand. BICC Users can also open and link MTP streams for their own use. Linked MTP streams can be SS7 MTP, SIGTRAN M3UA (over SCTP or SSCOP-MCE) or TALI MTP streams (over TCP or SCTP). MTP3b version of SS7 MTP and TALI MTP streams are also supported.

The BICC multiplexing driver handles Unequippped Circuit Identification Codes automagically and incorporates partial (non-circuit specific) state machines for BICC.

The BICC multiplexing driver is used primarily by the CS/AIN Call Model, OpenSwitch and Asterisk PBX integration applications. (See "Applications"). You can view the BICC code directory here.

ISUP Multiplexing Driver Code

ISUP (Integrated Service Digital Network [ISDN] User Part) is an integral part of the OpenSS7 SS7 stack. This multiplexing driver permits ISUP users to open ISUP streams and bind them to ISUP CIC ranges between specific Local and Remote Point codes. This permits an ISUP user stream to represent one or more ISUP Trunk Groups.

The ISUP multiplexing driver has MTP streams linked underneath it by the SS7 configuration daemon, either statically, or on demand. ISUP users can also open and link MTP streams for their own use. Linked streams can be SS7 MTP, SIGTRAN M3UA (over SCTP or SSCOP-MCE) or TALI MTP streams (over TCP or SCTP). MTP3b version of SS7 MTP and TALI MTP streams are also supported.

The ISUP multiplexing driver handles Unequipped Circuit Identification Codes automagically and incorporates partial (non-circuit specific) state machines for ISUP.

The ISUP multiplexing driver is used primarily by the CS/AIN Call Model, OpenSwitch and Asterisk PBX integration applications. (See "Applications"). You can view the ISUP code directory here.

TCAP Multiplexing Driver Code

TCAP (Transaction Capabilities Application Part) is an integral part of the OpenSS7 SS7 stack. This multiplexing driver permits TC- or TR-users to open TCAP streams and bind them to SCCP Global Titles for specific Subsystem Numbers and Point Codes. This permits an TC- or TR- user stream to represent a range of Global Titles for a specific Subsystem Number representing a range of TCAP subscriber services.

The TCAP multiplexing driver has SCCP streams linked underneath it by the SS7 configuration daemon, either statically, or on demand. TC- and TR-users can also open and link SCCP streams for their own use. Linked streams can be SS7 SCCP or SIGTRAN SUA (over SCTP or SSCOP-MCE). MTP3b and TALI versions of SS7 SCCP are also supported via the MTP and TALI muxes.

The TCAP multiplexing driver handles dialogues and non-existent transaction identifiers automagically. It includes full TCAP TC and TR state machines. The interface to TCAP is modelled on the STREAMS OSI Transport Provider Interface (TPI).

The TCAP multiplexing driver is used primarily by the HLR, SMSC, IN, LNP and CS/AIN Call Model applications. (See "Applications"). You can view the TCAP code directory here.

SCCP Multiplexing Driver Code

SCCP (Signalling Connection Control Part) is an integral part of the OpenSS7 SS7 stack. This multiplexing driver permits SCCP users to open SCCP streams and bind them to SCCP Global Titles for specific Subsystem Numbers and Point Codes. It fully supports protocol class 0, 1, 2, and 3 operation. This allows SCCP users to represent a range of subscribers and users of an SCCP subsystem.

The SCCP multiplexing driver has MTP streams linked underneath it by the SS7 configuration daemon, either statically, or on demand. SCCP users can also open and link MTP streams for their own use. Linked streams can be SS7 MTP, SIGTRAN M3UA (over SCTP or SSCOP-MCE) or TALI MTP streams (over TCP or SCTP). MTP3b versions of SS7 MTP and TALI MTP streams are also supported.

The SCCP multiplexing driver handles protocol class 0, 1, 2 and 3 operations. It includes full SCCP state machines. The interface to the SCCP modules is modelled on the STREAMS OSI Network Provider Interface (NPI).

The SCCP multiplexing driver is used primarily in direct support of TCAP. You can view the SCCP code directory here.

MTP3 Multiplexing Driver Code

MTP3 (Message Transfer Part [MTP] Level 3) is an integral part of the OpenSS7 SS7 stack. This multiplexing driver permits MTP users to open MTP streams and bind them to local MTP Point Codes and Service Indicators. It fully supports sequenced and unsequenced delivery. This allows MTP users to represent a service indicator at a signalling point.

The MTP multiplexing driver has Signalling Link (SL) streams linked underneath it by the SS7 configuration daemon, either statically or dynamically. MTP users can also open and link SL streams for their own use. Link streams can be SS7 MTP2, MTP3b (over SSCOP-MCE), SIGTRAN M2PA (over SCTP), and SIGTRAN M2UA (over SCTP or SSCOP-MCE) streams.

The MTP multiplexing driver handles full MTP procedures including the "Transfer Function". In includes full MTP state machines. The interface to the MTP modules is modelled after the STREAMS OSI Network Provider Interface (NPI) Connectionless (CL) interface.

The MTP multiplexing driver is used primarily in direct suppor of SCCP, ISUP and BICC. You can view the MTP code directory here.

SS7 Stack Manager Code

The SS7 Stack Manager is an SS7 configuration deamon that runs in user space with sufficient priviledge and opens control streams to the SS7 multiplexing drivers, modules and drivers to maintain and manage the configuration of the SS7 stack. It is executed from system init scripts at startup to bring up the SS7 stack at boot time and uses a number of configuration files to peform its function.

The SS7 configuration deamon is not required to be able to use the SS7 stack, but it removes the need for an application to peform its own stack configuration. It is supported by all of the SS7 components. You can view the SS7CONF code directory here.

Old SS7 Stack Code

If you are interested in browsing the old Linux Native Kernel implementation from the openss7-0.7.2.tgz release, you can walk through the directory here. Note that this approach was abadonned in favor of the STREAMS implementation that can be viewed from the diagram and lists above. The reasons for abandonning the Linux Kernel Native (Sockets) approach were as follows:

Portability to more Operating Systems and architectures.
Support for embedded systems and RT operating systems.
Close control over congestion and flow control withing the SS7 stack.
Separation of performance issues and considerations from the underlying kernel architecture.
Separation from GPL'ed kernels via the LGPL'ed LiS STREAMS package permitting linking of proprietary applications.