Nachdem das mit der Rufumleitung am Anlagenanschluß mit Fritz!OS nicht so richtig tat, ist quasi Asterisk mit einer ISDN-Karte die letzte Hoffnung …
Ich hatte Grund zur Hoffnung, daß es mit relativ aktueller (neuer als ca. 2012) libpri klappt, insofern installierte ich eine aus meinem Hardwarefundus gefischte HFC-S-ISDN-PCI-Karte in einem Futro, und probierte mein Glück mit Ubuntu 16.04, der aktuellen LTS-Version.
Satz mit X: in 1:2.10.2~dfsg-1ubuntu1 wurde zaphfc, notwendiger DAHDI-Treiber für die Cologne-Chip-Single-Port-Karten, entfernt:
* debian/dkms.conf.in
– Dropping ap400, opvxd115, wcopenpci, and zaphfc from build as
those got dropped from the Debian extra patch.
Nunja; die Installation soll noch rund ein halbes Jahr laufen, dann nehmen wir eben 14.04 LTS, denn da ist zaphfc noch drin.
Aber natürlich habe ich die Rechnung ohne die vielen Wirte gemacht: 14.04 gibt’s nur noch als 14.04.5-Image, mit einem 4er Kernel. dahdi-dkms allerdings bricht beim 4er Kernel ins Essen, wird offensichtlich nicht mehr gepflegt (was, gelinde gesagt, ziemlich scheiße ist, verließe man sich darauf, daß in einem LTS-Setup alles weiterfunktioniert).
Ist mir aber auch egal, Downgrade auf 3.19er Kernel dann eben. Und nach einem kleinen Ausflug in die Welt des Rescue-Boots – ohne das ›linux-image-extra‹-Package fehlt ein Modul, welches die Futro-Hardware benötigt, um die CF-Card als Laufwerk anzusprechen; ohne pata_atiixp kein Bootdevice und somit auch kein Root-FS – und dem dkms-Lauf gab es, endlich, endlich, einen Treiber für meine HFC-S-ISDN-Karte (»Cologne Chip«):
root@voip:~# dahdi_hardware -v pci:0000:0e:07.0 zaphfc+ 1397:2bd0 HFC-S ISDN BRI card
Allerdings … in Asterisk tut’s nicht:
root@voip:~# dahdi_scan [1] active=yes alarms=OK description=HFC-S PCI A ISDN card 0 [TE] name=ZTHFC1 manufacturer=Cologne Chips devicetype=HFC-S PCI-A ISDN location=PCI Bus 14 Slot 08 basechan=1 totchans=3 irq=20 type=digital-TE syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts=AMI framing_opts=CCS coding=AMI framing=CCS [2] active=yes alarms=UNCONFIGURED description=DAHDI_DUMMY/1 (source: HRtimer) 1 name=DAHDI_DUMMY/1 manufacturer= devicetype=DAHDI Dummy Timing location= basechan=4 totchans=0 irq=0 root@voip:~# dahdi_hardware pci:0000:0e:07.0 zaphfc+ 1397:2bd0 HFC-S ISDN BRI card root@voip:~# lsdahdi ### Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] " AMI/CCS 1 BRI Clear (EC: OSLEC - INACTIVE) 2 BRI Clear (EC: OSLEC - INACTIVE) 3 BRI Hardware-assisted HDLC ### Span 2: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: HRtimer) 1" (MASTER) root@voip:~# asterisk -r Privilege escalation protection disabled! See https://wiki.asterisk.org/wiki/x/1gKfAQ for more details. Asterisk 11.7.0~dfsg-1ubuntu1, Copyright (C) 1999 - 2013 Digium, Inc. and others. Created by Mark SpencerAsterisk 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. ========================================================================= Connected to Asterisk 11.7.0~dfsg-1ubuntu1 currently running on voip (pid = 879) voip*CLI> dahdi show status Description Alarms IRQ bpviol CRC Fra Codi Options LBO HFC-S PCI A ISDN card 0 [TE] OK 0 0 0 CCS AMI 0 db (CSU)/0-133 feet (DSX-1) DAHDI_DUMMY/1 (source: HRtimer) 1 UNCONFI 0 0 0 CAS Unk 0 db (CSU)/0-133 feet (DSX-1) voip*CLI> dahdi show channels Chan Extension Context Language MOH Interpret Blocked State Description root@voip:~# more /etc/asterisk/dahdi-channels.conf context=from-isdn channel => 1-2 switchtype = euroisdn signalling = bri_cpe_ptmp group = 1 root@voip:~# more /etc/asterisk/chan_dahdi.conf trunkgroups] [channels] language=de switchtype=euroisdn pridialplan=unknown prilocaldialplan=unknown internationalprefix = 00 nationalprefix = 0 localprefix = 09876 privateprefix = 09876123456 unknownprefix = priindication = outofband facilityenable=yes usecallerid=yes callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes immediate=no echocancel=yes echocancelwhenbridged=yes echotraining=yes callgroup=1 pickupgroup=1 mohinterpret=default mohsuggest=default group=1 signalling=bri_cpe_ptmp ; p2p TE mode => bri_cpe ; p2mp TE mode => bri_cpe_ptmp ; p2p NT mode => bri_net ; p2mp NT mode => bri_net_ptmp context=isdn-dtag channel => 1-2 root@voip:~# uname -a Linux voip 3.19.0-79-generic #87~14.04.1-Ubuntu SMP Wed Dec 21 18:46:52 UTC 2016 i686 athlon i686 GNU/Linux root@voip:~# dmesg | grep -B2 hfc [ 10.028151] dahdi: Telephony Interface Registered on major 196 [ 10.028161] dahdi: Version: 2.5.0.1 [ 10.150688] vzaphfc: HFC-S PCI A ISDN (V1.42) loading [ 10.151251] vzaphfc: card 0: registered ZTHFC1/0/1 [ 10.151259] vzaphfc: card 0: registered ZTHFC1/0/2 [ 10.151263] vzaphfc: card 0: registered ZTHFC1/0/3 [ 10.214250] vzaphfc: card 0: resetting [ 10.236562] vzaphfc: card 0 configured for TE mode at mem 0xf8300000 (0xf843c000) IRQ 20 -- [ 16.965985] dahdi_transcode: Loaded. [ 18.379171] dahdi_echocan_oslec: Registered echo canceler 'OSLEC' [ 18.380399] vzaphfc: card 0: chan B1: TX FIFO has become empty [ 18.380409] vzaphfc: card 0: chan B1 opened as ZTHFC1/0/1. [ 18.380432] vzaphfc: card 0: chan B1 closed as ZTHFC1/0/1. [ 18.380450] vzaphfc: card 0: chan B2: TX FIFO has become empty [ 18.380455] vzaphfc: card 0: chan B2 opened as ZTHFC1/0/2. [ 18.380474] vzaphfc: card 0: chan B2 closed as ZTHFC1/0/2. [ 18.380493] vzaphfc: card 0: chan D opened as ZTHFC1/0/3. [ 18.380499] vzaphfc: card 0: chan D closed as ZTHFC1/0/3. root@voip:~# lsmod | egrep 'dah|hfc' dahdi_echocan_oslec 16384 2 echo 16384 1 dahdi_echocan_oslec dahdi_transcode 16384 0 dahdi_dummy 16384 0 zaphfc 24576 0 dahdi 196608 4 dahdi_dummy,dahdi_transcode,dahdi_echocan_oslec,zaphfc crc_ccitt 16384 1 dahdi
Hmm. Wie es aussehen sollte, steht in diesem G+-Beitrag.
Auch die vier Jahre alten Tipps halfen nur bedingt weiter. Eingesetzt wurde »dahdi-2.5.0.1+dfsg-1ubuntu4~14.04.4«; des Rätsels Lösung fand sich in einem Git-Commit:
dahdi: Fix failure to read / write on kernel 3.16+
Kernel version 3.16+, since upstream commit (7f7f25e82d54870d “replace checking for ->read/->aio_read presence with check in ->f_mode” )[1], does not like it when dahdi changes the set of allowed file operations on a file descriptor outside of the context of an open() system call.
DAHDI changes the available file operations when a channel is opened by first opening /dev/dahdi/channel and then calling the DAHDI_SPECIFY ioctl to bind it to a particular DAHDI channel. Until DAHDI_SPECIFY is called there weren’t any read()/write() callbacks implemented and therefore after the initial open, the kernel was setting not setting FMODE_CAN_{WRITE,READ} on the file descriptor indicating that those operations were not allowed.
Now define empty shell functions on the general dahdi_fops so the vfs layer will not mark a file descriptor as unwritteable or unreadable on open.
Wie auch immer, Kernel 3.13 klingt auch nach einem Plan — und tatsächlich, kaum in den antiquarischen Tiefen eines 3.13er Kernels angekommt, klappt’s auch mit der ISDN-Karte. Yay …
Jetzt muß ich die ISDN-Karte nur noch auf den Anlagenmodus konfigurieren, korrekt in Asterisk einbinden und nach nur zwei Tagen werde ich sehen, ob Transfer() am Anlagenanschluß Partial Rerouting ausführt …
Das ist wirklich alles eine ganz große Grütze, und ich bin ziemlich froh, schon vor ca. 8 Jahren das Handtuch geworfen und auf FritzBoxen als ISDN-Interface gesetzt zu haben. Gut, ganz so schnell ging’s dann auch wieder nicht, aber ich habe tatsächlich das Trauerspiel um Treiber verpaßt — bis ich in der 1. Woche 2017 unverhofft mich dem Thema wieder widmen durfte.
chan_capi, die Asterisk-Unterstützung für Karten, die via CAPI ansprechbar sind, wird mühsam weitergepflegt, es gibt sogar Anpassungen für Asterisk 13. Allerdings habe ich auf die Schnelle nicht rausgefunden, ob und wie welche aktiven ISDN-Karten noch unterstützt werden in aktuellen Kerneln (also weit jenseits 3.13+), geschweige denn, welche davon unter Linux wie per CAPI ansprechbar wären. Ältere aktive ISDN-Karten bekommt man da für relativ kleines Geld; allerdings liest sich die Mailingliste auch eher wie ein Abgesang, zumindest werden mehr und mehr Features zugusten der Basisfunktion über Bord geworfen. Und was aktuelle Kernel angeht, irgendwo zwischen 3.2 und vor 3.19 ist ein inoffizielles Treiberpaket für die DIVA-Karten stehen geblieben — letztes Update vor 2 Jahren. Mithin auch keine Option im Jahre 2017 mehr.
Aber es gibt auch geile Lösungen: die PCI(e)-Karten der beroNet GmbH kommen für’s Hostsystem als Realtek-Ethernetkarte daher, welche z. B. Asterisk dann per SIP über die »zweite Netzwerkkarte« anspricht — und Zusatzmodule machen die Ports dann zu ISDN- und/oder Analog-Ports. Aktive Karten, die aber wirklich keine Treiber brauchen, solange der Realtek-Ethernet-Chipsatz noch vom OS unterstützt wird. Schade, in der Bucht war vor ein, zwei Wochen eine 4-Port-ISDN-Karte, aber Sofortkauf für 150,– war mir dann doch zuviel des Guten — schließlich habe ich zuhause erst im letzten Jahr die 144 kBit/sec des ISDN- durch 100 MBit/sec des VDSL-Vectoring-Anschlusses ersetzt.
Letztlich schade, war an sich ein Schnäppchen — aber ab 2018 wird es kaum noch möglich sein, echte ISDN-Anschlüsse zu bekommen, und, seien wir mal ehrlich, preislich wie technisch ist SIP ISDN mittlerweile Lichtjahre voraus. Für 5 EUR/Monat bekommt man 10 parallele Gespräche per SIP — das wären 5 ISDN-Anschlüsse, die alleine an Kupferdoppeladern mit 50 EUR zu Buche schlagen. Plus lustiger Technik, die diese 10 einzelnen B- und 5 D-Kanäle logisch bündelt, Anrufe drauf verteilt.
Bei SIP hingegen: 10 EUR/Monat drauf, und man hat 1000 Minuten ins Fest- und 100 Minuten in die Mobilfunknetze frei. Klar, einen leistungsfähigen Internet-Zugang braucht man obendrauf; aber auch die gibt’s ab 25 EUR/Monat. Und man ist dann prinzipiell frei in der Wahl seines ITSP (Internet-Telephony Service Provider); Kehrseite allerdings: ohne IP kein SIP, rafft’s den Internetzugang dahin, sei es lokal oder beim ISP, hat sich auch die Telefonie erledigt. Bin wirklich gespannt, wie sich das in den nächsten Jahrzehnten auswirken wird. Oder ob.
Anyway, das Fazit bleibt: ISDN ist schon länger tot, nur haben ›wir‹ es nicht wahrhaben wollen. Also ich in dem Maße jedenfalls nicht. Schon beim letzten ISDN-Asterisk-Abenteuer habe ich geflucht wie ein Rohrspatz; zum Teil ist es deutlich besser geworden, DAHDI mit zaphfc läuft wie ein Kätzchen — unter Ubuntu 14.04 LTS mit Kernel 3.13. Danach … fehlt jegliche Anpassung an Änderungen im Kernel, HFC-S-Karten sind mithin jenseits Kernel 3.13 nur noch Elektroschrott.
Treiber für die 4-Port-Karten hingegen (HFC-4S), werden noch weiter gepflegt (wie lange?!), also entweder eine solche holen (inkl. PC, in dem eine Full-Profile-PCI(!)-Karte noch Platz findet) oder auf Media-Gateways ausweichen, hat man noch ISDN-Geraffel zu bedienen.
IMHO ist dies auch der bislang deutlichste Beweis, daß auch Hardware ›gealtert wird‹; sie altert gar nicht zwingend von sich heraus, sondern wird passiv, durch Nichtanpassung an aktuelle Entwicklungen, abgehängt. Leider auch in der Open-Source-Welt; warum es gerade die HFC-S-Karten betrifft, erschließt sich mir nicht: die Änderungen für HFC-S und HFC-4S dürften austauschbar sein, machbar wäre es wohl. Alternativ könnte man auch die HFC-S-Treiber in die HFC-4S-Treiber integrieren, denke ich — aber es nutzen wohl zu wenige … Anyway, vor zehn Jahren hätte ich noch Stein und Bein geschworen, daß derlei nur proprietären Software-Hardware-Kombinationen ›passiert‹.
FTR, der Asterisk-x86-Server mit HFC-S läuft mittlerweile; und anders als eine Fritz!Box, kann jener am ISDN-Anlagenanschluß auch ganz wunderprächtig »Call Deflection Partial Rerouting«, dank DAHDI.
Daß AVMs Support-Helden, die mich per Twitter zur Support-Case-Eröffnung baten, nach gut einer Woche die Frage, ob denn ein aktuelles Fritz!OS am Anlagenanschluß ›CDPR‹ können sollte, mit »daß muß die Telekom einstellen und außerdem ist der Betrieb am Anlagenanschluß nicht supportet« (Nein! Doch! Oh! — das war mir initial schon klar, aber scheinbar hat AVM weder bei Twitter noch im Ticket meine Frage gelesen :() beantworteten, spricht für mich Bände. Ernsthaft, liebe AVM, ich hatte das vorher gelesen und daher getwittert, statt den Support zu belästigen. Hrmpft.
Wrap up: Fritz!OS kann zwar in den Anlagenmodus geschaltet werden (ISDN PtP statt PtMP), Rufumleitungen tun dann aber nur »zu Fuß«, sprich mit der eigenen Anschlußnummer über den zweiten B-Kanal. Eine Fritz!Box kann aber nur einen S0 gleichzeitig extern bedienen, Rufumleitung unter Nutzug beider B-Kanäle ist ziemlich nervig.
Ein Asterisk 11 unter Ubuntu 14.04 LTS und Kernel 3.13 ist im Jahre 2017 die scheinbar einzige Möglichkeit, noch eine HFC-ISDN-Karte sinnvoll zu nutzen. Und SIP hat in den letzten ~10 Jahren deutliche Forschritte gemacht, was die Qualität angeht — anders als damals höre ich heute, ISDN-verwöhnt, auch bei Verbindungen ins Festnetz per SIP kaum einen Unterschied.
Ruhe also sanft, ›mein‹ Integrated Services Digital Network!