Connecting Asterisk via OKS-7

SS7 signaling support was announced in chan_dahdi for a long time, but it was impossible to actually use it due to implementation constraints. Virtually the only alternative was to use the chanforss driver from Netfors (although their free version is not perfect, but it allows you to build at least some working system). And finally, in Asterisk v13 +, there is support for SS7, which allows you to connect to real equipment. So, we will consider the sequence of steps necessary for assembling Asterisk, supporting work with digital communication channels.



Connection planning

')

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



In our example, we will use the following source data:

- two 4-port interface boards Digium TE 420;

- on the first board, 4 ports are controlled by the OKS-7 signaling and collected in one bundle (linkset). Connection parameters: "point-to-point", our pointcode 650, pointcode neighbor 599, it is also the end point. This is an uplink connection, i.e., we will receive physical synchronization from it.

- on the second board, a consumer working via the EuroISDN protocol is connected to the first port, to which we give 30 connecting lines (that is, we will use all the timeslots in E1). For this consumer, we are a network (NET).

- on the second board, another consumer is connected to the second port, but also operating under the EuroISDN protocol. But we give him only 10 connecting lines (10 junior timeslots in E1. The remaining timeslots in the stream, with the exception of the signal, are not involved).

- the remaining two ports of the second board are not used yet.



Installing Interface Cards



I use Digium interface cards for 1 (TE 131 *), 2 (TE 235 *), and 4 (TE 420 *) channels. Now on sale there are also 8-channel boards, but somehow they didn’t get their hands on testing their performance.

Before installing the boards, you must:



- set with jumpers the required interface type (T1 or E1) for each of the ports on the board;

- set the switch that identifies 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 into the system, it is also recommended to connect them with a special loop that 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 details on the installation process, see the original Digium datasheet.



Build kernel-level drivers and related utilities



Since we have installed additional interface hardware, its support will require kernel-level drivers, which are absent in standard linux distributions. Therefore, we will have to compile them ourselves, and for this we will need the linux kernel source. If you use the source code of exactly the version of the kernel that is installed on the system, then we will not need to build and install the kernel itself. If the version does not match, then it will be necessary to first build a new kernel, and only after that, assemble dahdi drivers.



So, download asterisk from the official site and unpack the latest version of dahdi drivers. By the way, you can immediately download both the libpri and libss7 libraries, which will be needed to build chan_dahdi. The tools package for working with dahdi has two useful utilities that may not be built by default. These are dahdi_tool (allows you to view the status of the E1 physical ports in the 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 the package newt-devel in the system, and dahdi_pcap requires libpcap-devel.



For the dahdi_pcap utility to work, it is required to edit the file before the assembly



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



#define CONFIG_DAHDI_MIRROR



Next, proceed to the assembly and installation of the actual drivers:



cd dahdi-linux-complete

make clean

make

sudo -u root make install



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



cd dahdi-linux-complete / tools

make dahdi_pcap



After that, manually copy the executable file dahdi_pcap in the right place for us.



Creating a kernel-level driver configuration



Now we are going to configure the physical layer drivers. All configuration files are located in the / etc / dahdi directory. We are interested in / etc / dahdi / modules (list of loadable modules) and /etc/dahdi/system.conf (data link configuration for all physical ports).

/ Etc / dahdi / modules in each line is written the name of the module that is to be loaded. If you are not sure which specific module supports the equipment used, you can run the dahdi_genconf utility, which will check the installed equipment and create the appropriate configuration file. And you can make a universal configuration by simply listing in / etc / dahdi / modules all the modules that were assembled in the previous step (i.e. * .ko files from the dahdi-linux-complete / linux / drivers / dahdi directory, but without the path and .ko extensions).

In my case (using Digium TE420 *, TE235 * and TE131 * boards), it is enough to specify only one wct4xxp module in / etc / dahdi / modules.



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



Suppose we use one 4-port board to connect to the upstream telecom operator on OKS-7 (there are 4 full E1 physical streams in the bundle, each of which has signal timeslot), and one 2-port fee to connect to us downlinks on EuroISDN. In this case, we take the physical synchronization from our higher-level operator (the order of choice of ports is consistent with it), and for our downlinks we ourselves act as the source of the clock signal. At the same time, one of our downlinks uses all 30 timeslots (full E1), and the second we give only 10 first timeslots.



For connection via the SS-7 protocol, the configuration example 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 (ie 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 (ie far end is a slave)

span = 6,0,0, ccs, hdb3, crc4, yellow

# But the client uses only 10 timeslots

bchan = 156-165

unused = 166-170,172-186

dchan = 171



# The remaining 2 ports on the second map are not used, so it is not necessary to describe them.



Notes:



In the span parameter, the first argument is the port number (for their location on the interface card, 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 for them).



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



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



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



The next parameter (possibly) will be crc4, which allows the integrity control of the received data. In any case, this value should coincide with what the distant party expects of us.



The last parameter I set is yellow. This causes the driver to transmit the “yellow alarm” status when the corresponding span is not open by the application program (for example, Asterisk is not yet started or it was forcibly stopped).



After the port is announced (span), the channels it contains are defined. 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 may contain unrestricted raw 64K data, and the channel’s operating mode changes the program depends on the requests in the signaling channel) and not used (if the stream has a smaller number of channels than the available number of timeslots).



For the announcement of the 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.



Voice channels are announced with the help of the parameter bchan = channel (s), and not used channels are announced with the help of the parameter unused = channel (s).



After the configuration is complete, load the driver with the command

/etc/init.d/dahdi start and make sure that it works with 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 are physically connected and synchronized with the remote side (i.e., the data link layer is raised on them). The remaining 2 ports on the second board have the status “Red alarm” indicating that they are not physically connected to or is not operational (link level error).



You can also view 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 greater the value of "Average:", the more responsive the system. If this value is less than 99.99%, then, most likely, there will be problems with the transmission of facsimile data via digital channels. Sound distortion is also possible when using the audio conferencing functionality.



If, when trying to start dahdi_tool, we get a message like “Unable to open / dev / dahdi / ctl: No such file or directory”, this means that the drivers are not loaded or configured incorrectly. You can check their load with 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 using the lspci command:



#lspci -k

00: 00.0 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 d161 value will be the manufacturer’s code).



Build the required libraries for full-featured chan_dahdi



To support EuroISDN signaling, we need the libpri library, the source codes of which we downloaded earlier from asterisk.org. Unpack them, perform the assembly and installation:



cd libpri

make clean

sudo -u root make install



To support the SS7 signaling, we need the libss7 library, the source code of which is also available on asterisk.org. Unpack them, perform the assembly and installation:

cd libss7

make clean

make

sudo -u root make install



Now we unpack the source texts of asterisk itself and run 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 do not abuse your attention and give a description of the test as a whole.



Check Asterisk Modules



To check whether the modules are ready for assembly, run make menuselect







We are convinced that the chan_dahdi driver is ready for assembly (the automatic configuration system found libraries and header files for dahdi, libpri and libss7 libraries).



We compile and install asterisk:

make

sudo -u root make install

sudo -u root make samples



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



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



[trunkgroups]

; Leave this section empty if only EuroISDN channels

; do not use the thread assembly scheme in trunks with the stream identifier

; in the message. For SS7, this section is not used at all.



[channels]

; General options for our EuroISDN connections

echocancel = no

faxdetect = incoming



; The context of landing incoming calls from ISDN ports

; In our case, it is the same for all physical ports.

; but separate contexts can also be used.

context = landing



Configuring EuroISDN ports:



switchtype = euroisdn



;

; Some ISDN-specific parameters are omitted, for their description is the topic of a separate article.

;



; Depends on the remote system. If she does not recognize the situation when

; you put the phone down, try changing the value to inband (perverts!)

priindication = outofband



; CLIP will be processed

usecallerid = yes



; And we will send the calling presentation on outgoing calls. Suddenly, who wants

; hide your caller ID from the definition? ;)))

usecallingpres = yes



; Our downlink, which uses all 30 timeslots to transmit traffic.

; Physically connected to the first port of the second streaming card.

; For him, we act as a network (NET), it is CPE for us.

; Call transfer to him is made by the command

; 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 connects to the second port of the second streaming card.

; Call transfer to him is made by the command

; Dial (DAHDI / g6 / called_number)

group = 6

callgroup = 6



signalling = pri_net



; The client uses 10 timeslots

channel => 156-165



So, we have 4 E1 physical streams collected in one bundle, controlled by signaling SS-7. Each of the physical streams has one signal link (the standard location of the 16th timeslot), the other links are used for data transmission. Bundles are collected starting from the youngest, CIC are numbered sequentially, starting with 1. The corresponding piece from chan_dahdi.conf:



; Alarm type

signalling = ss7

; Next are the general parameters for various types of alarm.

; Hardly you need to change them.

usecallerid = yes

usecallingpres = yes

callwaitingcallerid = yes

threewaycalling = no

transfer = no

canpark = no

cancallforward = no

echocancel = no

echocancelwhenbridged = no



; Context to which calls from remote system will land

context = landing



; Logical group used to send a call to this bundle. Those.

; call command will be

; Dial (DAHDI / g1 / destination_number)

group = 1

callgroup = 1

; pickupgroup = 1



; In Europe (and in Russia) the ITU variant is used.

ss7type = itu



; SS7 Called Nature of Address Indicator

; For local / zone connections

; can be set explicitly ss7_called_nai = National

; But we leave the default value (it is also commented out):

; ss7_called_nai = dynamic



; Prefixes also will not be specified. It's easier for me to understand the dialplan

; ss7_internationalprefix = 00

; ss7_nationalprefix = 0

; ss7_subscriberprefix =

; ss7_unknownprefix =



; On incoming calls we will send ACM as soon as processing starts.

; dialplan landing. Those. the remote side will understand that the call was at least somewhere

; delivered to Whether or not to allow this option is a matter of taste.

; ss7_explicitacm = yes



; Automatic transfer of ACM on incoming calls when it was redirected

; asterisk on another channel and on this other channel a call status has occurred

; 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 the Dial ().

; ss7_autoacm = yes



; When initializing a channel driver, we consider all CICs blocked (i.e.,

; unavailable for use). They will unlock automatically.

; after completion of the logical test of the communication channel.

; ss7_initialhwblo = yes



; Control ehodavom. I leave the default.

; ss7_use_echocontrol = yes

; ss7_default_echocontrol = yes



; Beam Definition (linkset)

linkset = 1



; For the first stream in the bundle, SLC = 0 (for each subsequent one it increases by 1)

; This parameter depends on the configuration of the remote side.

slc = 0



; Our pointcode

pointcode = 651



; remote point pointcode

; This parameter depends on the configuration of the remote side.

adjpointcode = 599



; Hardly you will use STP routing, so the final pointcode

; matches the pointcode of the remote side. But it may have a different meaning if

; the far side is not the end point.

; 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 determined

; after each new signaling channel

#include ss7.timers



; Determine compliance with CIC and physical channels

cicbeginswith = 1

channel = 1-15

cicbeginswith = 17

channel = 17-31



; By analogy, we determine the remaining 3 physical ports entering 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 create a dialplan in extensions.conf and run asterisk in console mode:

asterisk -vvvc



- We want to assure you that the topic of the Asterisk alarm system will develop further and be supplemented with new materials.