Connect Asterisk on OKS-7

Support for SS7 signaling was announced in chan_dahdi for a long time, but it was really impossible to use it due to limitations in implementation. Almost the only alternative was to use the chan_ss7 driver from Netfors (although their free version is not ideal, but it allows you to build at least some working system). And finally, Asterisk v13 + introduced support for SS7, which allows you to connect to real equipment. So, consider the sequence of steps required to build Asterisk, which supports working with digital communication channels.

Connection planning

We need to decide whether we will have a connection to a higher provider (uplinks), or we will exclusively deal with the maintenance of our downlinks. Both the link layer settings (from whom and in what order the synchronization of physical flows will be performed) and the network layer parameters (see below) will depend on this.

In our example, we will use the following initial data:
- two 4-port interface boards Digium TE 420;
- on the first board, 4 ports are controlled by OKS-7 signaling and assembled in one bundle (linkset). Connection parameters: point-to-point, our pointcode 650, pointcode of neighbor 599, it is also the endpoint. This is a connection to uplink, that is, we will receive physical synchronization from it.
- on the second board, a consumer working on the EuroISDN protocol is connected to the first port, to which we give 30 trunk lines (that is, we use all time slots in E1). For this consumer we are a network (NET).
- on the second board, another consumer is connected to the second port, but also working on the EuroISDN protocol. But we give him only 10 trunks (10 lower time slots in E1. The rest of the time slots in the stream, except for the signal one, are not used).
- the remaining two ports of the second board are not yet used.

Installing the interface cards

I use the interface cards manufactured by Digium on 1 (TE 131 *), 2 (TE 235 *), and 4 (TE 420 *) channels. Now on sale there are 8-channel boards, but somehow the hands did not reach to test their performance.
Before installing the boards, you must:

- set the required interface type (T1 or E1) for each of the ports on the board with jumpers;
- set a switch identifying the serial number of the board in the system (when installing multiple boards, the values ​​set on the switches must be unique for each card);
- when installing several cards in the system, it is also recommended to connect them with a special loop, which will provide uniform synchronization for all ports (although in reality I did not notice any malfunctions in the absence of this loop even when sending faxes between ports located on different boards).
For more details on the installation process, see the original datasheet from Digium.

Build kernel-level drivers and related utilities

Since we installed additional interface equipment, kernel level drivers, which are not available in standard linux distributions, will be required to support it. Therefore, we will have to assemble them ourselves, and for this we will need the linux kernel sources. If we use the source code of the exact version of the kernel that is installed on the system, then we will not need to assemble and install the kernel itself. If the version does not match, then you will need to first build a new kernel, and only then build the dahdi drivers.

So, download from the asterisk official site and unpack the latest version of dahdi drivers. By the way, you can immediately download the libpri and libss7 libraries, which will be needed to build chan_dahdi. There are two useful utilities in the tools package for working with dahdi, which by default may not be compiled. This is dahdi_tool (allows you to view the state of the physical E1 ports in console mode) and dahdi_pcap (allows you to save traffic passing through the E1 port for further analysis using wireshark). Building a dahdi_tool requires a newt-devel package on the system, and dahdi_pcap requires libpcap-devel.

For the dahdi_pcap utility to work, before editing, you need to edit the

dahdi-linux-complete / linux / include / dahdi / dahdi_config.h file, in which you need to add the line

#define CONFIG_DAHDI_MIRROR

Next, we begin to assemble and install the drivers themselves:

cd dahdi-linux-complete
make clean
make
sudo -u root make install

The dahdi_pcap utility is not built by the standard build system anyway, so we assemble it manually:

cd dahdi-linux-complete / tools
make dahdi_pcap

After that, manually copy the dahdi_pcap executable file to the place we need.

Creating a configuration of kernel-level drivers

Now we begin to configure physical-level drivers. All configuration files are located in the / etc / dahdi directory. We are interested in / etc / dahdi / modules (a list of loadable modules) and /etc/dahdi/system.conf (link-level configuration for all physical ports).
In / etc / dahdi / modules, each line contains the name of the module to be loaded. If you are not sure which module supports the equipment in use, you can run the dahdi_genconf utility, which will check the installed equipment and create the corresponding configuration file. And you can make a universal configuration by simply listing in / etc / dahdi / modules all the modules that were built in the previous step (i.e. * .ko files from the dahdi-linux-complete / linux / drivers / dahdi directory, but without a path and .ko extensions).
In my case (Digium TE420 *, TE235 *, and TE131 * boards are used) in / etc / dahdi / modules it is enough to specify only one wct4xxp module.

The link layer configurations for each of the ports used (span), as mentioned above, are in the /etc/dahdi/system.conf file.

Suppose we use one 4-port card to connect to a higher-level communications provider via OKS-7 (in a bundle of 4 full physical flows E1, each of which has a signal time slot), and one 2-port card to connect downlinks to us EuroISDN. In this case, we take physical synchronization from our superior operator (the order of choice of ports is consistent with it), and for our downlinks we act as the source of the clock signal. In this case, one of our downlinks uses all 30 timeslots (full E1), and the second we give only the first 10 timeslots.

For connection via the OKS-7 protocol, an example configuration is as follows:

# CARD 0, SPAN 2
span = 1,1,0, ccs, hdb3, yellow
bchan = 1-15,17-31
mtp2 = 16

# CARD 0, SPAN 2
span = 2.2.0, ccs, hdb3, yellow
bchan = 32-46.48-62
mtp2 = 47

# CARD 0, SPAN 3
span = 3.3.0, ccs, hdb3, yellow
bchan = 63-77, 79-93
mtp2 = 78

# CARD 0, SPAN 4
span = 4,4,0, ccs, hdb3, yellow
bchan = 94-108,110-124
mtp2 = 109

# CARD 1, SPAN 1 Customer channel, timing master (i.e. far end is a slave)
span = 5,0,0, ccs, hdb3, crc4, yellow
bchan = 125-139,141-155
dchan = 140

# CARD 1, SPAN 2 Customer channel, timing master (i.e. far end is a slave)
span = 6.0,0, ccs, hdb3, crc4, yellow
# But the client only uses 10 timeslots
bchan = 156-165
unused = 166-170,172-186
dchan = 171

# The remaining 2 ports on the second card are not used, so they are not required to be described.

Notes:

In the span parameter, the first argument is the port number (for their location on the interface board, see the datasheet). The boards themselves are arranged in a logical order corresponding to the value of the switches in ascending order of the value set on them).

The second argument is the value that defines physical synchronization. A value of 0 means that we are the source of the clock for the remote side. Non-zero values ​​set the priority of our synchronization from external sources (the lower the value, the more priority the external clock source will be for us).

The third parameter indicates the value depending on the length of the cable connecting our and the remote system. The correspondence of the parameter value to the physical length is described in the comments in system.conf.

The next parameter indicates the type of frames. For E1 with OKS-7 or EuroISDN alarm this will be ccs. The following is a method of encoding data. For E1 with OKS-7 or EuroISDN alarm this will be hdb3.

The next parameter (possibly) will be specified crc4, allowing the integrity control of the received data. In any case, this value should coincide with what the remote side expects from us.

The last parameter I set is yellow. This causes the driver to send the “yellow alarm” state when the corresponding span is not opened by the application program (for example, Asterisk has not been started yet or it was forced to stop).

After the port declaration (span) is the definition of the channels that it contains. In our case, the channels will be of 3 types: signal (HDLC), voice (usually used to transmit a signal encoded by one of the G.711 variants. However, for 3GPP these channels can contain unrestricted raw 64K data, and the channel’s operating mode changes the program depending on the requests in the signaling channel) and not used (if the stream defines a smaller number of channels than the available number of time slots).

To declare a signal link for OKS-7 we use the parameter mtp2 = channel, and for EuroISDN this parameter has the name dchan = channel. In fact, both of these values ​​are equivalent and define the specified channel as an HDLC channel.

We declare voice channels using the parameter bchan = channel (s), and not used channels we declare using the unused = channel (s) parameter.

After completing the configuration, load the drivers with the command
/etc/init.d/dahdi start and verify the operability using the dahdi_tool utility:



The picture shows that all 4 ports on the first interface board and the first 2 ports on the second interface board have a physical connection and are synchronized with the remote side (i.e., the channel level is raised on them). The remaining 2 ports on the second board have the “Red alarm” status indicating that there is no physical connection to them or is not working (link layer error).

You can also see the status of a specific physical port



... and check the responsiveness of the system as a whole with the dahdi_test utility:



Note that the higher the “Average:” value, the better the responsiveness of the system. If this value is less than 99.99%, then, most likely, there will be problems with the transmission of facsimile data on digital channels. Sound distortion may also occur when using the audio conferencing functionality.

If we get a message like “Unable to open / dev / dahdi / ctl: No such file or directory” when trying to start dahdi_tool, then this means that the drivers are not loaded or are configured incorrectly. You can check their download using the standard lsmod utility:

#lsmod
Module Size Used by Tainted: G
wctc4xxp 32992 0
dahdi_transcode 4566 1 wctc4xxp
wct4xxp 241730 166
dahdi 201849 486 dahdi_transcode, wct4xxp

You can check the availability and logical location of the equipment with the command lspci- 00:

00l : 00l : 00l
: Class 0600: 8086: 0150
00: 02.0 Class 0300: 8086: 0162
00: 14.0 Class 0c03: 8086: 1e31 xhci_hcd
00: 16.0 Class 0780: 8086: 1e3a
00: 16.3 Class 0700: 8086: 1e3d serial
00: 19.0 Class 0200: 8086: 1502 e1000e
00: 1a.0 Class 0c03: 8086: 1e2d ehci-pci
00: 1b.0 Class 0403: 8086: 1e20 snd_hda_intel
00: 1c.0 Class 0604: 8086: 1e10 pcieport
00: 1c.4 Class 0604: 8086: 1e18 pcieport
00: 1c.6 Class 0604: 8086: 1e1c pcieport
00: 1c.7 Class 0604: 8086: 1e1e pcieport
00: 1d.0 Class 0c03: 8086: 1e26 ehci-pci
00: 1e.0 Class 0604: 8086: 244e
00: 1f.0 Class 0601: 8086: 1e53
00: 1f.2 Class 0106: 8086: 1e02 ahci
00: 1f.3 Class 0c05: 8086: 1e22
02: 00.0 Class 0604: 104c : 8231
03: 08.0 Class 0780: d161: 1420 wct4xxp
04: 00.0 Class 0604: 104c: 8231
05: 08.0 Class 0780: d161: 1420 wct4xxp
06: 00.0 Class 0200: 8086: 10d3 e1000e

(for Digium equipment, the manufacturer code will be d161).

Assembling the necessary libraries for the fully functional chan_dahdi

To support EuroISDN signaling, we need the libpri library, the source texts of which we downloaded earlier from asterisk.org. Unpack them, build and install:

cd libpri
make clean
sudo -u root make install

To support the OKS-7 signaling, we need the libss7 library, the source texts of which are also on asterisk.org. Unpack them, build and install:
cd libss7
make clean
make
sudo -u root make install

Now unpack the source code of the asterisk itself and start the automatic configuration system:

cd asterisk
./configure

Then we recommend checking the Asterisk modules and in order not to overload the article with the description of this necessary procedure, we posted it on a separate resource .
“At the same time, we hope that we will not abuse your attention and give a full description of the audit.”

Checking the Asterisk modules

To check the readiness of the modules for assembly, run make menuselect Make



sure that the chan_dahdi driver is ready to build (the automatic configuration system found libraries and header files for dahdi, libpri and libss7 libraries).

Compiling and installing asterisk:
make
sudo -u root make install
sudo -u root make samples

The last command will install the configuration example in the / etc / asterisk directory.

Now we need to edit /etc/asterisk/chan_dahdi.conf to define the network level parameters for the created connections in it.

[trunkgroups]
; Leave this section empty, if only EuroISDN channels
; not used in the assembly flow diagram indicating trunks flow identifier
; in the message. For OKS-7 this section is not used at all.

[channels]
; General parameters for our EuroISDN connections
echocancel = no
faxdetect = incoming

; The context of the landing of incoming calls from ISDN ports
; In our case it is the same for all physical ports
; but you can use separate contexts.
context = landing

Configure EuroISDN ports:

switchtype = euroisdn

;
; Some parameters specific to ISDN are omitted, because their description is the topic of a separate article
;

; Depends on the remote system. If she does not recognize the situation when
; you hang up, try replacing the value with inband (perverts!)
priindication = outofband

; CLIP we will process
usecallerid = yes

; Yes, and we will send a calling presentation on outgoing calls. Suddenly who wants
; hide your caller ID from definition? ;)))
usecallingpres = yes

; Our downlink, using all 30 timeslots to transmit traffic.
; Physically connected to the first port of the second streaming board.
; For him we act as a network (NET), for us he is CPE.
; Transferring a call to him is done by a team
; Dial (DAHDI / g5 / called_number )
group = 5
callgroup = 5

signalling = pri_net

channel => 125-139
channel => 141-155

; Our downlink, using only 10 timeslots to transmit traffic.
; Physically connected to the second port of the second streaming board.
; Transferring a call to him is done by a team
; Dial (DAHDI / g6 / called_number )
group = 6
callgroup = 6

signalling = pri_net

; The client uses 10 timeslots
channel => 156-165

So, we have 4 physical E1 streams assembled in one bunch, controlled by OKS-7 signaling. Each physical stream has one signal link (the standard location of the 16th time slot), the rest of the links are used to transmit data. Streams in the bunch are collected from the lowest, CIC numbered sequentially, starting with 1. The corresponding piece of chan_dahdi.conf:

; Signaling type
signalling = ss7
; Next are the parameters common to various types of alarms
; It is unlikely that you will need to change them.
Usecallerid = yes
usecallingpres = yes
callwaitingcallerid = yes
threewaycalling = no
transfer = no
canpark = no
cancallforward = no
echocancel = no
echocancelwhenbridged = no

; The context to which calls coming from the remote system
context = landing will land

; The logical group used to send a call to this bunch. Those.
; the call command will look like
; Dial (DAHDI / g1 / destination_number)
group = 1
callgroup = 1
; pickupgroup = 1

; In Europe (and in Russia), the ITU variant
ss7type = itu is used

; SS7 Called Nature of Address Indicator
; For local / zone level connections
; can be set explicitly ss7_called_nai = National
; But we leave the default value (it is also commented out)
:; ss7_called_nai = dynamic

; We will not specify prefixes either. It’s easier for me to deal with them in dialplan.
; ss7_internationalprefix = 00
; ss7_nationalprefix = 0
; ss7_subscriberprefix =
; ss7_unknownprefix =

; On incoming calls, we will send ACM as soon as processing begins
; dialplan landing. Those. the far side will understand that the call was at least somewhere
; delivered. Whether or not to enable this option is a matter of taste.
; ss7_explicitacm = yes

; Automatic transmission of ACM on incoming calls when it has been redirected
; asterisk th on another channel and on this other channel the call state arose
; or answer. Affects the transmission of early media from a third-party channel to the call.
; Or you will always need to call Proceeding () before Dial ().
; ss7_autoacm = yes

; When initializing the channel driver, we consider all CICs to be blocked (i.e.
, unavailable for use). Their unlocking will happen automatically
; after completion of logical testing of the communication channel.
; ss7_initialhwblo = yes

; Driving control. I leave by default.
; ss7_use_echocontrol = yes
; ss7_default_echocontrol = yes

; Definition of a beam (linkset)
linkset = 1

; For the first stream in the beam, SLC = 0 (for each subsequent stream it increases by 1)
; This parameter depends on the configuration of the remote side
slc = 0

; Our pointcode
pointcode = 651

; pointcode remote side
; This parameter depends on the configuration of the remote side.
adjpointcode = 599

; It is unlikely that you will use STP routing, so the final pointcode
; matches the pointcode of the remote side. But may have a different meaning if
; the remote side is not the endpoint.
; This parameter depends on the configuration of the remote side
defaultdpc = 599

; NI value for MTP3. Most likely it will be either national or national_spare
; This parameter depends on the configuration of the remote side
networkindicator = national_spare

; Specify the signal channel for the 1st stream
sigchan = 16
; Be sure to determine the timers! They need to be defined
; after each new signal channel
#include ss7.timers

; We determine the correspondence between the CIC and the physical channels
cicbeginswith = 1
channel = 1-15
cicbeginswith = 17
channel = 17-31

; By analogy, we determine the remaining 3 physical ports included in the bundle

slc = 1
pointcode = 650
adjpointcode = 599
defaultdpc = 599
networkindicator = national_spare
sigchan = 47
#include ss7.timers

cicbeginswith = 33
channel = 32-46
cicbeginswith = 49
channel = 48-62

slc = 2
pointcode = 650
adjpointcode = 599
defaultdpc = 599
networkindicator = national_spare
sigchan = 78
#include ss7.timers

cicbeginswith = 65
channel = 63-77
cicbeginswith = 81
channel = 79-93

slc = 3
pointcode = 650
adjpointcode = 599
defaultdpc = 599
networkindicator = national_spare
sigchan = 109
#include ss7.timers

cicbeginswith = 97
channel = 94-108
cicbeginswith = 113
channel = 110 -124 It

remains only to compose a dialplan in extensions.conf and run asterisk in console mode:
asterisk -vvvc

- We want to assure you that the Asterisk alarm theme will develop in the future and will be supplemented with new materials.