Connect to OCTOI via S0-Adapter

Hello, I am trying to connect an ISDN phone to OCTOI using the following instructions:

However, as someone who has no experience with Asterisk, the instructions are not entirely clear. Are there perhaps people here who would be willing to help me reproduce the setup described?

I would like to end up with a guide that allows even absolute beginners to connect ISDN devices to OCTOI using the method described.

I have the following questions to get started:

  1. Which kernel modules exactly need to be blacklisted, and how is this done?
  2. Which version of Asterisk is recommended? And what is the recommended installation method?
  3. What exactly is asterisk-dahdi? And what is the best way to install it without installing dahdi via DKMS?
  4. Are additional drivers required for the PCI card?

Thanks a lot and have a nice week!
Florian

I don’t want to slow down your enthusiasm, but it looks to me that this method isn’t something that is “officially supported”, but more or less a documentation of a proof of concept, so I wouldn’t rely on that it is somehow maintained. I’m also not sure whether having a PCI card modded by soldering tiny parts onto it, adding a RF jack and then adding a hardware clock device worth ~160€ is something “absolute beginners” would have fun with :slight_smile:
The official way would be to use the ice1usb and work via E1, maybe putting a E1 ISDN card and a S0 ISDN card into a PC and bridge them could be a more reliable option. I mildly remember that this has been done also, bridging done based on date then, as long as you don’t want to put a full-fledged PBX with E1 port onto the table.

However, I’m not sure what would be the best way currently. There are plans that OCTOI will get a “official” S0-hardware:

It looks to me that it is still under development, but not actively currently. Since OCTOI is a community project, i.e. something that people do for fun / in their spare time, it depends on who is able to spend some time and what the particular person is able to do or likes to help with.

However, as mentioned in the feature ticket, there is a Raspberry Pi hat with a dual S0 Cologne Chip:

I’m not sure whether the latter works in OCTOI since it doesn’t seem to have an input possibility for a high precision clock source.

Nevertheless, I’ll try to answer at least some of your questions:

How blacklisting is done: A Google search should have provided you an answer; it’s pretty straight forward, here is what is the top Google result I got:

I don’t know which modules are affected off the top of my head, but what I would do is look into the kernel modules tree on the Linux system and search for the place where hfcpci is located. mISDN should even have its own subdirectory, IIRC. Then simply blacklist all of them.
It should be like located under: .../kernel/drivers/isdn/...

No version is mentioned, the project was documented around 2022, so my best guess would be Asterisk 18. Since the solution as such does not depend on Asterisk specialities, a good sign is whether the Asterisk version chosen is able to successfully bring up the patched asterisk-dahdi / channel-driver, since this is the only speciality here.
Regardind installation: More or less the only way to install Asterisk is to compile it from source.
There have been packages maintained by Debian for many years, but the asterisk core package has been removed from Debian 12. Interestingly, many supplemental packages remain in the repo.
The only “turnkey” solution I know of so far is to use the FreePBX distro, but I would not recommend that since it assumes that you do not fiddle around with Asterisk’s guts or make greater changes to the underlying Linux. Changes made there can become broken by FreePBX updates or your changes may break the FreePBX application.
Building/Installing Asterisk from source is explained here:
https://docs.asterisk.org/Getting-Started/Installing-Asterisk/Installing-Asterisk-From-Source/What-to-Download/
It is pretty simple nowadays and boils down to running the following commands from the unpacked sources:

  • contrib/scripts/install_prereq
  • I would always run contrib/scripts/get_mp3_source.sh so you Asterisk will be able to do MP3 transcoding; This comes in very handy If you like to play tones/music/recordings/MoH to the caller. You can just use MP3 files directly and don’t need to convert it upfront.
  • ./configure
  • make menuconfig, add MP3 “format” support (see above)
  • make install

The ability of Asterisk to communicate with other systems is provided by so-called channel drivers. For SIP, chan_sip and PJSIP are used. Some channel drivers are part of the main Asterisk source tree, and others are provided externally. For example, there has been over many years an active community maintaining a channel driver for Ciscos proprietary VoIP protocol SCCP.
asterisk-dahdi is a channel driver which lets Asterisk use hardware that supports the DAHDI driver framework.
I think it is described that you could just re-install OCOI’s dahdi-linux after the Asterisk variant is there. So I would prefer that method.

Actually, the (modified) dahdi-linux is (contains) the driver (i.e. kernel module) for the HFC card, called zaphfc. Before the name DAHDI was born, it was called “zaptel”, hence the name.

That’s correct. It’s just a simple proof-of-concept with old hardware I had available (and the GPSDO of course).

That driver also does a number of other weird things, like transferring the B channel data via I2S/DMA directly by writing to hardware registers in the Raspberry Pi SoC:

#define BCM2708_PERI_BASE 0xfe000000
//i2s stuff
#define I2S_BASE                 (BCM2708_PERI_BASE + 0x203000) /* i2s controller */
#define GPIO_BASE                (BCM2708_PERI_BASE + 0x200000)

#define SPI0_BASE                (BCM2708_PERI_BASE + 0x204000)

That’s a … weird … design choice to say the least.
Such a driver would ideally be just using the SPI interface (and for an effective data rate of less than 384 kbit/s there is no reason not too), but that driver is still missing.

Yup. That’s a hack, which always causes trouble with DKMS after system upgrades, etc., but it does work (and I do it this way, too).

First of all, I would like to thank you for your replies to my thread! This community seems to consist of many nice, talented and dedicated people. And since everyone here is investing their private time, I don’t want to steal anyone’s time unnecessarily.

A few days ago I successfully got a setup of icE1usb and an Auerswald telephone system up and running. I am therefore not dependent on getting an implementation with an ISDN PCI card to work. I’m more driven by curiosity and the prospect of having an energy-saving and silent alternative that could run 24 hours a day. :slight_smile: But I also understand if it is seen as wasted effort.

I hope it’s okay if I try to document my efforts here in as much detail as possible. Not at least for myself to read up on.

Hardware:

  • Fujitsu S900
  • ISDN card (HFC-S PCI A ISDN card)
  • Phone (Sinus PA 302i)

I start with a fresh 64bit installation of Debian 12. After I had given my user account Sudo rights, I performed the following steps:

1. Asterisk installation:

cd
wget https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz

tar -xvf asterisk-18-current.tar.gz
cd asterisk-18.23.1/

sudo contrib/scripts/install_prereq install

sudo ./configure
sudo make menuselect

sudo make
sudo make install

make menuselect: I have not made any changes to the default settings.

2. Asterisk-DAHDI installation:

cd
wget https://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz
tar xzf dahdi-linux-complete-current.tar.gz

cd dahdi-linux-complete-3.4.0+3.4.0/

sudo make all
sudo make install

3. blacklist kernel modules:

sudo nano /etc/modprobe.d/blacklist.conf

in this file i added the following lines:

blacklist hfcmulti
blacklist w6692
blacklist mISDNisar
blacklist mISDNipac
blacklist avmfritz
blacklist speedfax
blacklist hfcsusb
blacklist hfcpci
blacklist mISDNinfineon
blacklist mISDN_core
blacklist mISDN_dsp

4. dahdi-linux installation:

cd
git clone https://gitea.osmocom.org/retronetworking/dahdi-linux.git

cd dahdi-linux

make
sudo make install

5. dahdi-tools installation:

git clone https://gitea.osmocom.org/retronetworking/dahdi-tools

cd dahdi-tools

autoreconf -i

./configure
make
make install

6. config:

osmo-e1d.cfg: (like below but with the actual server ip and username)

octoi-client 123.123.123.123 10013
 local-bind 0.0.0.0 3333
 account username
  mode dahdi-trunkdev
  dahdi-trunkdev name octoi
  dahdi-trunkdev line-number 0
e1d
 interface 0 dahdi-trunkdev
  trunkdev-name octoi
  line 0
   mode e1oip

/etc/dahdi/system.conf:

# Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [NT] " (MASTER)
span=1,0,0,ccs,ami
# termtype: nt
bchan=1-2
hardhdlc=3

# Span 2: trunkdev/octoi/0 "Virtual trunk octoi span 0" 
span=2,1,0,ccs,hdb3,crc4
# termtype: te
bchan=4-18,20-34
dchan=19

# Global data

loadzone        = de
defaultzone     = de

/etc/asterisk/chan_dahdi.conf:

[trunkgroups]

[channels]
language=de
switchtype=euroisdn

echocancel=no
echocancelwhenbridged=no

pridialplan=unknown
prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0

overlapdial=yes

#include dahdi-channels.conf

/etc/asterisk/dahdi-channels.conf:

; Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [NT] " (MASTER) AMI/CCS
group=0,11
context=from-hfc
switchtype = euroisdn
signalling = bri_net_ptmp
channel => 1-2
context = default
group = 63

group=0,12
context=from-octoi
switchtype = euroisdn
signalling = pri_cpe
channel => 4-18,20-33
context = default
group = 63

/etc/asterisk/extensions.lua: (here i changed XXXX to my own prefix)

extensions = {
    ["from-hfc"] = {
        ["_X."] = function(context, extension)
            app.dumpChan()
            channel.CALLERID("all"):set(string.format("%s <%s>", "HFC", '030XXXX' .. 1234))
            app.dial("Dahdi/g12/"..extension, 100, "tkTK")
        end;
    };
    ["from-octoi"] = {
        ["_X."] = function(context, extension)
            app.dumpChan()
            app.dial("Dahdi/g11/"..extension, 100, "tkTK")
        end;
    };
    hangup = {
        s = function(context, extension)
            app.verbose("WARNING: Unknown call!")
            app.hangup()
        end;

    };
    default = {
        include = {"hangup"};
    };

    public = {
        -- ATTENTION: If your Asterisk is connected to the internet and you do
        -- not have allowguest=no in sip.conf, everybody out there may use your
        -- public context without authentication.  In that case you want to
        -- double check which services you offer to the world.
        include = {"hangup"};
    };
}

hints = {
    default = {
        ["1234"] = "SIP/1234";
    };
}

Sorry for the perhaps too detailed post. I hope that I have not already made a major mistake. In the next post I will describe what is holding me up at the moment.

After executing the following commands:

sudo modprobe zaphfc nt_modes=0
sudo modprobe dahdi-trunkdev

And a reboot. the situation is as follows:

with sudo dahdi_tool i get:

Here I have the first question: Is it normal for “Alarms” to say “UNCONFIGURED”? This does not relate to the actual configuration of the card?

after the command sudo dahdi_trunkdev create octoi:

And while executing sudo osmo-e1d:

It looks to me like the octoi part is working. (?) But now I have the following questions:

  1. is there any way to find out if the communication between ISDN phone and the card works in principle? In other words, does the basic data exchange work? I have crimped a corresponding cable (3 :left_right_arrow: 4 ; 4 :left_right_arrow: 3 ; 5 :left_right_arrow: 6 and 6 :left_right_arrow: 5).

  2. what settings are still missing? Especially with Asterisk.

Thanks again, and best regards!

The “unconfigured” part looks like dahdi_cfg hasn’t been run yet?
Run it with dahdi_cfg -v ideally :slight_smile:

After dahdi_trunkdev create octoi you also want to run dahdi_trunkdev config octoi.

It might work then.

As a word of caution: The clock mod is the most important part of this whole thing.
It’s the central piece of this whole experiment and the globally synchronized clocks are the reason OCTOI works at all (and as well as it does).
Without a synchronized 12.288 MHz clock, you’ll run into buffer under/overruns very quickly and your connection will drop.

You can probably still make a short call, but it won’t be stable (and stuff like analog modems will also not work as well or at all).

Thanks! I think i’m again one step closer :slight_smile:

Yes, I have to admit that the ISDN card still draws its clock from the factory installed crystal. And I realize how important a precise clock is for stable communication. I had hoped to establish a connection for a few seconds. I then wanted to modify the card and use an external GPS disciplined clock source.

results in:

DAHDI Tools Version - 3.1.0-6-g5255769

DAHDI Version:
Echo Canceller(s):
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
SPAN 2: CCS/HDB3 Build-out: 0 db (CSU)/0-133 feet (DSX-1)

34 channels to configure.

Setting echocan for channel 1 to none
Setting echocan for channel 2 to none
Setting echocan for channel 3 to none
Setting echocan for channel 4 to none
Setting echocan for channel 5 to none
Setting echocan for channel 6 to none
Setting echocan for channel 7 to none
Setting echocan for channel 8 to none
Setting echocan for channel 9 to none
Setting echocan for channel 10 to none
Setting echocan for channel 11 to none
Setting echocan for channel 12 to none
Setting echocan for channel 13 to none
Setting echocan for channel 14 to none
Setting echocan for channel 15 to none
Setting echocan for channel 16 to none
Setting echocan for channel 17 to none
Setting echocan for channel 18 to none
Setting echocan for channel 19 to none
Setting echocan for channel 20 to none
Setting echocan for channel 21 to none
Setting echocan for channel 22 to none
Setting echocan for channel 23 to none
Setting echocan for channel 24 to none
Setting echocan for channel 25 to none
Setting echocan for channel 26 to none
Setting echocan for channel 27 to none
Setting echocan for channel 28 to none
Setting echocan for channel 29 to none
Setting echocan for channel 30 to none
Setting echocan for channel 31 to none
Setting echocan for channel 32 to none
Setting echocan for channel 33 to none
Setting echocan for channel 34 to none

I think the last step is that Asterisk needs some sort of basic configuration files besides the ones mentioned above. Running sudo asterisk -cv results in the following errors:

Unable to open specified master config file '/etc/asterisk/asterisk.conf', using built-in defaults
Asterisk 18.23.1, Copyright (C) 1999 - 2022, Sangoma Technologies Corporation and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
PBX UUID: d52b092f-dae5-4682-b066-1a2950c771be
Unable to load config file 'stasis.conf'
Could not load Stasis configuration; using defaults
[Jun 26 08:15:20] ERROR[1058]: logger.c:2237 init_logger: Errors detected in logger.conf.  Default console logging is being used.
 Asterisk PBX Core Initializing
 Asterisk Dynamic Loader Starting:
[Jun 26 08:15:20] WARNING[1058]: loader.c:2394 loader_config_init: 'modules.conf' invalid or missing.
[Jun 26 08:15:20] ERROR[1058]: asterisk.c:4068 check_init: Module initialization failed.  ASTERISK EXITING!

I am sorry that I still have so little knowledge of Asterisk. Is there a minimum configuration that is sufficient for this setup?

Not sure, I usually always started my configs from the Debian default configuration.

You can probably just download & extract that package and use those config files (worst case, I can look for mine, but they’re old and still Debian 11/Asterisk 16, iirc).

and yes, your DAHDI setup now looks good! :smile:

If you could send me your configuration files, that would be great! Then I could try to adapt them for Asterisk 18.

Is there any way to test if the communication between ISDN phone and ISDN card works? At the moment the phone is still reporting: No line (Keine Leitung). But it is connected directly to the card via a crossover cable.

I probably have another problem: sudo dahdi_genconf gives the following errors:

cut: '/sys/bus/dahdi_devices/devices/pci:0000:02:07.0/spantype': No such file or directory
cut: /sys/bus/dahdi_devices/devices/trunkdev_octoi/spantype: No such file or directory
Failed probing type for channel 4 at /usr/local/share/perl/5.36.0/Dahdi/Config/Gen/System.pm line 238.
1 Like

Yeah, dahdi_genconf doesn’t work in many cases. Just ignore that tool and write the system.conf manually.

Are you sure your cable/wiring is OK? Did you add termination resistors somewhere?

I’ll look for the config files.

I hope so, here is a diagram of the cable i made:

I did not add termination resistors.

Uhm… Is that diagram really correct?
5,6 to 5,6 and 3,4 to 3,4 would be a straight-through cable.

You’d want 3,4 to 5,6 and 5,6 to 3,4…

EDIT: Wrong info! Look below.

Thank you very much for your response. Now, I am also unsure. If I connect 3,4 to 5,6, the polarity would change. I thought it should be maintained.

Or is there something i am missing?

Sorry about that, I didn’t look correctly.
4 and 5 are TX- and TX+, 3 and 6 are RX- and RX+.

The right adapter should be fine.
Some phones also want some line voltage to detect an S0 line.
You could try to connect some 9V batteries in series to get about 36V for some DC bias?

Hey, i tried to apply a bias voltage of 36 Volt, but the phone still complains. :slightly_frowning_face:

Could you share your files? Maybe i find some point where i screwed up :face_with_peeking_eye:

Thanks for all your help so far!

I sent you a DM with the config files a couple of days ago already :smile:

Oh, sorry. I hadn’t seen your message. :see_no_evil:
The good news is that I seem to have taken another small step forward: The phone no longer reports that the line is unavailable. I had not configured the ISDN line correctly in NT mode. Unfortunately, I have not made any further progress. I’ll take a break over the weekend and then get back to it. :smile:

One error I receive which I get from Astersik is:

[Jun 28 15:48:19] ERROR[1834]: chan_dahdi.c:19019 process_dahdi: Unknown signalling method 'bri_net_ptmp' at line 14.
[Jun 28 15:48:19] ERROR[1834]: chan_dahdi.c:19019 process_dahdi: Unknown signalling method 'pri_cpe' at line 22.

That seems like a serious error to me, doesn’t it? :thinking:

Huh!

… that is indeed weird – and an error I haven’t seen before.

I haven’t compiled my asterisk from source – just used the Debian one. It’s possible that they have some magic tricks/patches on it, but I cannot say for sure.

The current example config file for Asterisk’s master branch still includes these signalling methods:

So I’m guessing they should be supported?!