HFC-Karte mit Dahdi und Asterisk 1.6

[sflemming]

Hallo Horatio,

ich poste Dir nochmal was ich in der /var/log/asterisk/messages für Meldungen bekomme. Vielleicht gibt das ja auch noch Anhaltspunkte.

[Jan 11 21:48:35] NOTICE[24867] cdr.c: CDR simple logging enabled.
[Jan 11 21:48:35] NOTICE[24867] loader.c: 175 modules will be loaded.
[Jan 11 21:48:35] NOTICE[24867] res_smdi.c: No SMDI interfaces are available to listen on, not starting SMDI listener.
[Jan 11 21:48:35] WARNING[24867] res_config_ldap.c: No directory user found, anonymous binding as default.
[Jan 11 21:48:35] ERROR[24867] res_config_ldap.c: No directory URL or host found.
[Jan 11 21:48:35] NOTICE[24867] res_config_ldap.c: Cannot load LDAP RealTime driver.
[Jan 11 21:48:36] ERROR[24867] res_timing_dahdi.c: Asterisk has detected a problem with your DAHDI configuration and will shutdown for your protection
.  You have options:
        1. You only have to compile DAHDI support into Asterisk if you need it.  One option is to recompile without DAHDI support.
        2. You only have to load DAHDI drivers if you want to take advantage of DAHDI services.  One option is to unload DAHDI modules if you don't need them.
        3. If you need DAHDI services, you must correctly configure DAHDI.
For more information on Asterisk timing modules, including ways to potentially fix this problem, please see doc/timing.txt
[Jan 11 21:48:36] WARNING[24867] translate.c: plc_samples 160 format f
[Jan 11 21:48:36] NOTICE[24867] pbx_ael.c: Starting AEL load process.
[Jan 11 21:48:36] NOTICE[24867] pbx_ael.c: AEL load process: parsed config file name '/etc/asterisk/extensions.ael'.
[Jan 11 21:48:36] NOTICE[24867] pbx_ael.c: AEL load process: checked config file name '/etc/asterisk/extensions.ael'.
[Jan 11 21:48:36] NOTICE[24867] pbx_ael.c: AEL load process: compiled config file name '/etc/asterisk/extensions.ael'.
[Jan 11 21:48:36] NOTICE[24867] pbx_ael.c: AEL load process: merged config file name '/etc/asterisk/extensions.ael'.
[Jan 11 21:48:36] NOTICE[24867] pbx_ael.c: AEL load process: verified config file name '/etc/asterisk/extensions.ael'.
[Jan 11 21:48:36] WARNING[24867] utils.c: trying to reset empty pool
[Jan 11 21:48:36] WARNING[24867] utils.c: trying to reset empty pool
[Jan 11 21:48:36] WARNING[24867] utils.c: trying to reset empty pool
[Jan 11 21:48:36] WARNING[24867] chan_dahdi.c: Ignoring any changes to 'userbase' (on reload) at line 23.
[Jan 11 21:48:36] WARNING[24867] chan_dahdi.c: Ignoring any changes to 'vmsecret' (on reload) at line 31.
[Jan 11 21:48:36] WARNING[24867] chan_dahdi.c: Ignoring any changes to 'hassip' (on reload) at line 35.
[Jan 11 21:48:36] WARNING[24867] chan_dahdi.c: Ignoring any changes to 'hasiax' (on reload) at line 39.
[Jan 11 21:48:36] WARNING[24867] chan_dahdi.c: Ignoring any changes to 'hasmanager' (on reload) at line 47.
[Jan 11 21:48:36] NOTICE[24867] config.c: Registered Config Engine curl
[Jan 11 21:48:36] NOTICE[24867] chan_skinny.c: Configuring skinny from skinny.conf
[Jan 11 21:48:36] WARNING[24867] pbx_config.c: ==!!== Unknown directive: language at line 3 -- IGNORING!!!

Ich denke das Problem ist erstmal wirklich in Asterisk zu suchen.

Was hat denn Deine Horstbox für ne Architektur, ist da ein MIPS drauf oder ein PowerPC? Vielleicht sollte ich mir das Ding auch mal ansehen, hört sich interessant an. Eine Lösung wäre natürlich sich einen externen ISDN/SIP-Gateway zu kaufen, aber irgendwie will ich nicht so recht aufgeben, das wird doch irgendwie zu bewältigen sein.

Vorher werde ich heute aber auch nochmal die Quellen ansehen, vielleicht finde ich ja eine laufende Kombination.

Vielleicht liegt es ja auch tatsächlich an der Asterisk config. Vielleicht sollten wir ja da auch nochmal vergleichen.

Beste Grüße, Stefan

 

[motte]

Hallo horatio42/alle,

den "error 0" - genauer: "app_dial.c:1721 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 0 - Unknown)" erhalte ich, wenn ich einen Fehler im Dialplan habe, derart wie "Dial(DAHDI/1/${EXTEN})" statt "Dial(DAHDI/g1/${EXTEN})".

Mit letzterer Extension kriege ich aber auch zuverlässig die Fehlermeldung "app_dial.c:1721 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)". Ich habe wirklich nicht die leiseste Ahnung, woran das liegen kann. Asterisk schweigt sich an dieser Stelle leider wirklich aus.

Noch schlimmer ist es allerdings bei eingehenden Anrufen. Läuft Asterisk im Realtime-Modus friert an dieser Stelle nach einigem Zögern der Rechner ein. Solange hört der Anrufer nichts, dann "Der Teilnehmer ist zurzeit nicht erreichbar".

Ich stelle mir vor, dass die beiden Probleme irgendwie miteinander zusammenhängen. Ich habe Larrys Patch _nicht_ durchgeführt, weil dieser mit dahdi-dkms (=2.2.0.2) von Ubuntu-Linux 9.10 (karmic) und linux-headers-2.6.31-17 zwar Patch-Erfolge bringt, dann beim maken aber erhebliche Fehler erzeugt und das Kompilieren (make) dadurch abbricht. Ich habe auch noch nicht verstanden, was der Patch nun anders machen sollte, als die mitgelieferte dahdi-Version, die bis auf den oslec-Echocanceller, der sich später nicht laden lässt, alle Treiber erfolgreich baut und installiert.

VG, Alex.

 

[motte]

Hallo Stefan,

kannst Du trotz Deiner Fehlermeldung "res_timing_dahdi.c: Asterisk has detected a problem with your DAHDI configuration" eigentlich über DAHDI telefonieren? Für die Fehlermeldung verantwortlich sind folgende Module:

res_timing_dahdi.so
res_timing_pthread.so
res_timing_timerfd.so

Wofür dienen die genau? Ich stelle mir vor, dass man sie nicht laden muss, wenn man Meetme oder andere speziellen Timer-Funktionen nicht verwendet. Wobei ich mich schon frage, wodurch sie entsteht, denn /dev/dahdi/timer ist da und dahdi_dummy meldet im Kernel-Log "dahdi_dummy: High Resolution Timer started, good to go"

VG, Alex.

 

[sflemming]

Hallo Alex,

danke für Deine neuen Lösungsansätze.

Die relevanten Teile meiner extension.conf sind:

exten => _0X.,1,Set(CALLERID(num)=12345)                                                              
exten => _0X.,n,Dial(DAHDI/g1/${EXTEN:1})                                                                
                                                                                                         
exten => _X.,1,Set(CALLERID(num)=67890)                                                               
exten => _X.,n,Dial(DAHDI/g1/${EXTEN})

Ich sehe da jetzt so auf Anhieb keinen Fehler.

dahdi_scan sagt:

[1]
active=yes
alarms=OK
description=HFC-S PCI A ISDN card 0 [TE] layer 1 DE
name=ZTHFC1
manufacturer=
devicetype=
location=
basechan=1
totchans=3
irq=0
type=digital-
syncsrc=0
lbo=399-533 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

dahdi_hardware sagt:

pci:0000:01:07.0     zaphfc-      1397:2bd0 HFC-S ISDN BRI card

dahdi_speed und dahdi_test landen allerdings im jenseits. Da passiert nichts mehr.

Ein Ctrl-C bei dahdi_test liefert:

--- Results after 0 passes ---
Best: 0.000 -- Worst: 100.000 -- Average: 100.000000, Difference: 100.000000

In Asterisk selbst bekomme ich bei dahdi show channels:

Chan Extension  Context         Language   MOH Interpret        Blocked    State     
 pseudo            default                    default                         In Service
      1            default         de         default                         In Service
      2            default         de         default                         In Service

dahdi show status in asterisk bringt mir

Description                              Alarms  IRQ    bpviol CRC4   Fra Codi Options  LBO
HFC-S PCI A ISDN card 0 [TE] layer 1 DE  OK      0      0      0      CCS AMI  YEL      399-533 feet (DSX-1)
DAHDI_DUMMY/1 (source: HRtimer) 1        UNCONFI 0      0      0      CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)

Meine geladenen Module sind:

Module                  Size  Used by
dahdi_dummy             3280  0 
dahdi_echocan_oslec     2016  0 
echo                    4304  1 dahdi_echocan_oslec
dahdi_transcode         5656  0 
zaphfc                 11400  3 
dahdi                 193520  10 dahdi_dummy,dahdi_echocan_oslec,dahdi_transcode,zaphfc
r8169                  32532  0 
forcedeth              54892  0

Wichtig zu erwähnen ist, dass es eine amd64 Architektur ist!

Ich kann definitiv mit dahdi keine Anrufe entgegennehmen oder absetzen.

Ich hoffe, dass die Ausgaben vielleicht zur Lösung des Problems beitragen oder andere eventuell die ein oder andere Sache in ihren eigenen Configs wiedererkennen.

Danke für Eure Hilfe,
Stefan

 

[Larry]

Tach zusammen, frohes neues und so und überhaupt!

Kurzer Zwischenstand:
Mit sflemming's ebuild konnte ich gestern erfolgreich Asterisk-1.6.2.x (!) auf x86 bauen und wie gehabt mehrere Testrufe durchführen.
Mit dem ganzen Konstrukt unter Asterisk 1.6.1.x habe ich es bisher gar nicht getestet, aber laut tameritoke gabs dort die erwähnten Probleme (dahdi lädt nicht korrekt / läßt sich nicht korrekt initialisieren / * kann nicht auf dahdi zugreifen). Nach Installation von Asterisk 1.6.0.x gings dann plötzlich. So sind wir zumindest schon mal zwei, bei denen es funktioniert.

Nur noch mal als Hoffnungsschimmer für Euch: Ich arbeite nun bereits seit ein paar Monaten produktiv (!) mit der dieser Lösung - keinerlei Probleme bisher *seufz*

Ich baue das ganze nun noch auf x86_64 nach und schaue mal, was dabei 'rumkommt...

 

[horatio42]

Hallo zusammen,

erstmal danke an alle für das Feedback!

@stefan:

...
Was hat denn Deine Horstbox für ne Architektur, ist da ein MIPS drauf oder ein PowerPC?
...

Intel XScale, also im Endeffekt eine ARM-RISC-Architektur. Ist mit 533MHz/64MB RAM recht flott unterwegs und eigentlich ein "Residential Gateway" also ein Router mit DSL-Modem und Telefoniefunktionen.
Nähere Infos findest Du hier. Besonders hervorzuheben ist der potc-Thread, in dem an einer alternativen Firmware (D-Link hat den Support eingestellt) mit aktuellem Kernel und Asterisk gebastelt wird. Im Zusammenspiel mit mISDN funktioniert ISDN schon, hat aber ein paar Macken weswegen ich im Moment mal in dahdi reinschaue...
Nur eine Warnung bevor Du jetzt direkt losrennst und das Ding kaufst: mit Horstbox ist im Allgemeinen die Horstbox PROFESSIONAL gemeint. Es gibt inzwischen eine Consumer-Variante (auch Horstbox STANDARD genannt) in einem schicken weißen Gehäuse die aber intern auf anderer Hardware (MIPS/AR7) basiert! Siehe auch die Threads im obigen Forum. Da die Pro anscheinend von D-Link abverkauft wird, sind beide preislich recht ähnlich. Ich würde die Pro angesichts der vorhandenen Hardware durchaus als Schnäppchen bezeichnen wollen. Man sollte aber einen ausgeprägten Basteltrieb mitbringen, da die Original-FW ist wirklich nicht so toll ist, und die bei der alternativen Firmware muss man die meisten Dinge nach wie vor von Hand konfigurieren, auch darum die selbst Firmware zu kompilieren kommt man auch nicht herum. Linux-Kenntnisse sind da unerlässlich. Wer regelmäßig Asterisk-configs manuell ändert dürfte aber ausreichend hart gesotten sein um sich da reinzufuchsen ;-)

@alex:
Danke für die Klarstellung bzgl. der Fehlermeldungen ("error 0" und "error 34"), es könnte in der Tat sein dass ich die Dial-Rules zwischenzeitlich geändert hatte.
Und sorry für meine recht laxe Wiedergabe der Fehlermeldungen. Werde die in Zukunft auch lieber copy-pasten...

Und nochmal @stefan:
Meine Configs ähneln Deinen recht stark. Auch ich hatte eine Meldung von Asterisk bzgl. Problemen mit der Timer-Konfiguration, konnte die aber durch gezieltes (Nach-)Laden von dahdi_dummy und des chan_dahdi -Moduls in Asterisk "workarounden"... bevor ich jetzt aber wieder Sachen ungenau aus meiner Erinnerung poste, werde ich das Ganze nochmal gezielt reproduzieren und später genauer hier reinstellen.

H.

 

[motte]

Hallo Stefan,

ich verstehe zurzeit nicht, wozu das g1 bei "Dial(DAHDI/g1/${EXTEN:1})" gut ist. Ist das immer noch richtig? Früher bei Zaptel und Asterisk 1.4 hat das super funktioniert. Aber jetzt tut sich hier bei Asterisk 1.6.2.0~rc2-0ubuntu1.2 nur die beschriebene Cause 34 / Congestion-Meldung, ohne das ich erkennen kann, woran es liegen könnte.

dahdi_scan

# 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 01 Slot 09
basechan=1
totchans=3
irq=16
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

dahdi_hardware

pci:0000:01:08.0     zaphfc+      1397:2bd0 HFC-S ISDN BRI card

dahdi_speed und dahdi_test landen allerdings im jenseits. Da passiert nichts mehr.

Doch, dahdi_test tut jetzt nach einem Reboot wieder (dahdi_speed habe ich nicht...):

# dahdi_test 
Opened pseudo dahdi interface, measuring accuracy...
100.000% 99.993% 99.998% 99.997% 99.999% 99.997% 99.999% 99.998% 
99.997% 99.998% 99.999% 99.997% 99.997% 99.998% 99.998% 99.997% 
99.998% 99.998% 99.998% 99.997% 99.997% 99.998% 99.999% 99.998% 
99.998% 99.997% 99.998% 99.999% 99.998% 99.998% 99.998% 99.997% 
99.998% 99.998% 99.998% 99.997% 99.998% 99.998% 99.998% 99.997% 
99.999% 99.997% 99.997% 99.999% 99.997% 99.999% 99.998% 99.998% 
99.998% 99.997% 99.998% 99.999% 99.997% 99.813% 99.810% 99.997% 
99.998% 99.568% 99.563% 99.997% 99.998% 99.999% 99.998% 99.999% 
99.997% 99.998% 99.999% 99.998% 99.998% ^C
--- Results after 69 passes ---
Best: 100.000 -- Worst: 99.563 -- Average: 99.979915, Difference: 99.997845

# invoke-rc.d dahdi start
Loading DAHDI hardware modules:
   zaphfc: done   dahdi_transcode: done   dahdi_echocan_oslec: error   dahdi_dummy: done
Running dahdi_cfg: .

In Asterisk selbst bekomme ich bei dahdi show channels:

   Chan Extension  Context         Language   MOH Interpret        Blocked    State     
 pseudo            default                    default                         In Service
      1            isdn-in         de         default                         In Service
      2            isdn-in         de         default                         In Service

dahdi show status in asterisk bringt mir

Description                              Alarms  IRQ    bpviol CRC4   Fra Codi Options  LBO
HFC-S PCI A ISDN card 0 [TE]             OK      0      0      0      CCS AMI  YEL      0 db (CSU)/0-133 feet (DSX-1)
DAHDI_DUMMY/1 (source: HRtimer) 1        UNCONFI 0      0      0      CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)

Ich habe amd32.

Ich kann definitiv mit dahdi keine Anrufe entgegennehmen oder absetzen.

Oh, guck an: Das hatte ich ganz anders verstanden. Aber ich kann Dich be(un)ruhigen. Auch mit obiger Konfig tut's nicht besser...

Betriebsystem: Ubuntu karmic 9.10, Kernel 2.6.31-17.54 (Ubuntu-spezifisch, der letzte mit dem dahdi erfolgreich compiliert wurde, aktuell wäre 2.6.31-18.55)

@Larry: Frohes Neues

 

[motte]

Was ist eigentlich der Nachteil, wenn man mit mISDN arbeitet? Ich meine: Vielleicht funktioniert's wenigstens etwas mit mISDN? Das wäre schon 100% mehr als mit DAHDI (zurzeit)...

 

[horatio42]

Hallo Alex,

Was ist eigentlich der Nachteil, wenn man mit mISDN arbeitet? Ich meine: Vielleicht funktioniert's wenigstens etwas mit mISDN? Das wäre schon 100% mehr als mit DAHDI (zurzeit)...

ein paar von den Nachteilen im Zusammenspiel mit meiner Horstbox hatte ich hier mal aufgelistet...

Generell benutzt das aktuelle mISDN (v2) einen zusätzlichen demon (LCR -> Linux Call Router), man kann nicht mehr direkt aus asterisk mit den Kernel-Modulen kommunizieren. Keine Ahnung warum das so ist. Der LCR bietet eigene Routing-Möglichkeiten auf ISDN-Ebene, wer aber auf asterisk-Integration angewiesen ist, muss beides laufen lassen... auf einem Embedded System wieder Horstbox nicht gerade der Hit... RAM ist da ein knappes Gut.

Aber das Ganze hat auch ein paar Vorteile:
- es funktioniert prinzipiell (ich kann damit aus Asterisk stabil telefonieren)
- die mISDN-module sind seit Kurzem Teil des aktuellen Standard-Kernels. Werden also maintained und auf aktuelle Versionen angepasst.

Probiers' halt aus. Beachte dass obiges auf die mISDN v2 zutrifft. Diese benötigt zwingend den LCR-Demon und den chan_lcr für asterisk (http://www.linux-call-router.de). Die alte Version (v1) kam noch ohne Demon aus und das Asterisk Modul hieß noch chan_misdn. Obwohl es immer wieder Leute gibt die behaupten dass v1 bei ihnen stabil läuft: bei mir knallt sie gewaltig. Außerdem wirst Du die sourcen an aktuelle Kernel-Versionen selbst anpassen müssen, die Module die dem Kernel beiliegen sind v2.
Einigen Distros liegt ja vielleicht sogar alles als fertig konfiguriertes Modul bei, hab da aber keinen Überblick.

Generell muss man wohl sagen dass Digium nicht allzu viel am Support für die hfc-s billig-Chips liegt... wahrscheinlich weil sie ihre eigene Hardware verkaufen wollen(?) LCR/mISDN wird vom linux-call-router team maintained. chan_misdn wurde (obwohl Teil der Asterisk-sourcen) immer etwas stiefmütterlich behandelt (zugunsten zaptel/dahdi?). Oder übersehe ich da was?


Meine Configs reiche ich noch nach, hatte gerade etwas Stress mit meiner Horstbox.

H.

 

[motte]

Hallo H.,

das es da auch noch ein altes und ein neues mISDN gibt wusste ich nicht und die Treibernennungen sind da in der Tat schonmal sehr hilfreich Ich probier hier wahrscheinlich erst nochmal eine "Live"-Gemeinschaft oder so aus, bevor ich es dann mal mit mISDN versuche.

Meine Configs reiche ich noch nach, hatte gerade etwas Stress mit meiner Horstbox.

Mir würden geeignete mISDN-Konfigs natürlich die Arbeit erleichtern ;-)
Andererseits: Wer kann behaupten, mit Asterisk umzugehen, wenn er nur Konfigs adaptiert ;-))

VG, Alex.

 

[sflemming]

Hallo allerseits,

ich melde mich nochmal um ein kleines Update zu geben. Vielleicht hilft das Euch ja auf Eurem Weg oder ihr könnt es zumindest bestätigen.

Wir sind noch am forschen und haben festgestellt, dass es vermutlich ein 64 Bit Problem gibt. Was auf 32 Bit läuft scheint derzeit bei 64 Bit gegen den Baum zu gehen.

Eine weitere interessante Sache ist: Wenn ich bei mir die Kernel Frequenz von 250Hz auf 1000Hz anhebe funktionier bei mir dahdi_speed.

Bei dahdi_test sieht es aber leider noch schlecht aus.

Bezüglich misdn kann ich sagen, dass es bei mir mehr als schlecht lief, bzw. derzeit auf gentoo wegen jeder Menge Fehler nichtmal zu kompilieren ist.

Stefan

 

[motte]

Hi,

Wir sind noch am forschen und haben festgestellt, dass es vermutlich ein 64 Bit Problem gibt. Was auf 32 Bit läuft scheint derzeit bei 64 Bit gegen den Baum zu gehen.

So dumm es klingt, aber ich war bislang der Meinung, ich hätte hier ein 32-Bit-System auf einer 64-Bit-Architektur laufen. Mittlerweile bin ich mir da nicht mehr so sicher, weil ich linux-image-* (linux kernel on x86/x86_64) verwende, hätte aber in der Kernel-Boot-Meldung etwas von "64" lesen wollen, wenn es wirklich ein 64-Bit-Kernel wäre. Ich sage das deshalb so gedehnt, weil es neuerdings auch die linux-image-*-pae (kernel image on x86) gibt, die aber für ein 32-Bit-System mit mehr als 4 GB RAM sein sollen. Ich blick' da nicht mehr durch...

Linux version 2.6.31-18-generic (buildd@rothera) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #55-Ubuntu SMP Fri Jan 8 14:55:26 UTC 2010 (Ubuntu 2.6.31-18.55-generic)

Da ich in Ermangelung von Fehler- oder Debugmeldungen wirklich keinen Schimmer habe, warum DAHDI bei mir nicht geht, möchte ich das gerne wenn möglich erstmal begraben. Andererseits...

Bezüglich misdn kann ich sagen, dass es bei mir mehr als schlecht lief, bzw. derzeit auf gentoo wegen jeder Menge Fehler nichtmal zu kompilieren ist.

mISDN ist ja im Ubuntu-Kernel drin - allerdings läuft LCR nur mit getrennt zu besorgendem und extra vorher zu compilierenden mISDNuser. Noch schlimmer wird es dadurch, dass sich der benötigte chan_LCR offenbar nur dann compiliert, wenn Asterisk aus den Sourcen selbst compiliert wurde(!) Ansonsten ist mir das Verhalten von LCR nicht erklärlich.
Update: Paket asterisk-dev ausgepackt und schon compiliert LCR auch den chan_LCR. Komisch: Kaum macht man's richtig, schon funktioniert's ;-) Ich werde euch hier aber erstmal nicht mehr mit LCR langweilen: Eigentlich soll es ja mit DAHDI funktionieren...

VG, Alex.

 

[horatio42]

Hallo zusammen,

so, hier nochmal mein DAHDI-setup nachgereicht, vielleicht fällt ja jemandem irgend etwas auf:
Das grundlegende Setup ist eine Horstbox (Intel XScale, Big Endian) mit einem 2.6.32.3er Kernel, asterisk 1.6.0.21-rc1, und dahdi 2.2.1-rc2 mit Larry's Patches für zaphfc support.

Die kernel-module:

        # dahdi modules
        insmod $basedir/lib/modules/crc-ccitt.ko
        insmod $basedir/lib/modules/dahdi.ko
        insmod $basedir/lib/modules/dahdi_dummy.ko
        insmod $basedir/lib/modules/zaphfc.ko
        insmod $basedir/lib/modules/echo.ko
        insmod $basedir/lib/modules/dahdi_echocan_oslec.ko
        insmod $basedir/lib/modules/dahdi_transcode.ko

Und die system.conf:

# cat /etc/dahdi/system.conf
span=2,0,3,ccs,ami
bchan=1-2
dchan = 3
echocanceller=oslec,1-2
loadzone        = de
defaultzone     = de

span=3,0,3,ccs,ami
bchan=4-5
dchan = 6
echocanceller=oslec,4-5
loadzone        = de
defaultzone     = de

Anmerkung hierzu: ich habe dahdi_dummy *vor* zaphfc geladen und laut dahdi_scan belegt der dann quasi den ersten Eintrag (Span?):

# dahdi_scan
[1]
active=yes
alarms=UNCONFIGURED
description=DAHDI_DUMMY/1 (source: HRtimer) 1
name=DAHDI_DUMMY/1
manufacturer=
devicetype=DAHDI Dummy Timing
location=
basechan=1
totchans=0
irq=0
type=digital-
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=
framing_opts=
coding=
framing=
[2]
active=yes
alarms=OK
description=HFC-S PCI A ISDN card 0 [TE] layer 1 DE
name=ZTHFC1
manufacturer=
devicetype=
location=
basechan=1
totchans=3
irq=0
type=digital-
syncsrc=0
lbo=399-533 feet (DSX-1)
coding_opts=AMI
framing_opts=CCS
coding=AMI
framing=CCS
[3]
active=yes
alarms=OK
description=HFC-S PCI A ISDN card 1 [TE] layer 1 DE
name=ZTHFC2
manufacturer=
devicetype=
location=
basechan=4
totchans=3
irq=0
type=digital-
syncsrc=0
lbo=399-533 feet (DSX-1)
coding_opts=AMI
framing_opts=CCS
coding=AMI
framing=CCS

(Dies ist bereits ein scan *nach* erfolgtem dahdi_cfg).
Ich habe das in der Reihenfolge gemacht, da ich den eigenartigen Effekt hatte dass mich asterisk mit einem Problem in der DAHDI-Konfiguration anspuckt wenn ich zaphfc zuerst lade und dann dahdi_dummy Eintrag [3] und nicht [1] ist. Warum ist mir in keinster Weise klar.

Das dahdi_cfg sieht auch unauffällig aus:

# dahdi_cfg -vvv
DAHDI Tools Version - 2.2.1-rc2

DAHDI Version: 2.2.1-rc2
Echo Canceller(s): OSLEC
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 2: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 02: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 02)
Channel 03: D-channel (Default) (Echo Canceler: none) (Slaves: 03)
Channel 04: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 04)
Channel 05: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 05)
Channel 06: D-channel (Default) (Echo Canceler: none) (Slaves: 06)

6 channels to configure.

Setting echocan for channel 1 to oslec
Setting echocan for channel 2 to oslec
Setting echocan for channel 3 to none
Setting echocan for channel 4 to oslec
Setting echocan for channel 5 to oslec
Setting echocan for channel 6 to none

Komischerweise ist hier wieder von Span 1+2 die Rede, obwohl sie im dahdi_scan (und auch meiner system.conf) ja auf 2+3 liegen... aber vielleicht entsprechen die Einträge in dahdi_scan ja keinen Spans...? Die Konfiguration scheint jedenfalls zu passen.

Im Messagelog (dmesg) sieht zunächst auch alles ok aus:

<6>zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xc498e000 fifo 0xc3bd8000(0x3bd8000) IRQ 24 HZ 100
<6>zaphfc: Card 0 configured for TE mode
<6>zaphfc: Card 0 configured for master mode
<4>PCI: enabling device 0000:00:0d.0 (0140 -> 0143)
<6>zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xc4998100 fifo 0xc3be8000(0x3be8000) IRQ 24 HZ 100
<6>zaphfc: Card 1 configured for TE mode
<6>zaphfc: Card 1 configured for master mode
<6>zaphfc: 2 hfc-pci card(s) in this box.
<6>dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
<6>dahdi_transcode: Loaded.

Nach einiger Zeit tauchen da aber folgende Fehler auf:

<2>zaphfc[1]: b channel buffer overflow: 4074, 4074
<2>zaphfc[0]: rx sync changed: 4074, 4330
<2>zaphfc[0]: b channel buffer overflow: 4074, 4330
<2>zaphfc[1]: b channel buffer underrun: -3343, -3343
<2>zaphfc[0]: b channel buffer underrun: -3343, -3343

Ist nicht ganz reproduzierbar *wann*, auch die Zahl und Häufigkeit schwankt.

Ok, zu Asterisk, hier meine chan_dahdi.conf:

# cat /etc/asterisk/chan_dahdi.conf
[trunkgroups]

[channels]
language=de
switchtype=euroisdn
pridialplan=dynamic
prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0
;;localprefix = 0221
;;privateprefix = 022112345678
unknownprefix =
facilityenable = yes
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
;
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
;echotraining=800
;rxgain=2.0
;txgain=3.0
;
group=1
callgroup=1
pickupgroup=1
mohinterpret=default
mohsuggest=default
;
context=incoming-isdn
immediate=yes
channel => 4-5
;channel => 1-2
callerid = asreceived

Wie gesagt enthält die Horstbox *zwei* hfc-s single-port chips (...) Ich nutze im Moment nur den nach extern, welches der zweite sein sollte, also b-channels 4+5. Gegenprobe mit 1+2 (nicht das ich am Ende am falschen Anschluss rumdoktere...) war noch weniger erfolgreich.

Asterisk lädt chan_dahdi jedenfalls:

Asterisk*CLI> module load chan_dahdi
  == Registered application 'DAHDISendKeypadFacility'
  == Parsing '/etc/asterisk/chan_dahdi.conf':   == Found
    -- Registered channel 4, ISDN BRI Point to MultiPoint signalling
    -- Registered channel 5, ISDN BRI Point to MultiPoint signalling
    -- Automatically generated pseudo channel
  == Starting D-Channel on span 3
  == Registered channel type 'DAHDI' (DAHDI Telephony Driver w/PRI)

  == Manager registered action DAHDITransfer
  == Manager registered action DAHDIHangup
  == Manager registered action DAHDIDialOffhook
  == Manager registered action DAHDIDNDon
  == Manager registered action DAHDIDNDoff
  == Manager registered action DAHDIShowChannels
  == Manager registered action DAHDIRestart
 Loaded chan_dahdi => (DAHDI Telephony w/PRI)

Und findet die channels auch:

Asterisk*CLI> dahdi show channels
   Chan Extension  Context         Language   MOH Interpret        Blocked    State
 pseudo            incoming-isdn   de         default                         In Service
      4            incoming-isdn   de         default                         In Service
      5            incoming-isdn   de         default                         In Service

In Asterisk's extensions.conf benutze ich dann eine Zeile wie

exten => #,2,Dial(DAHDI/g1/${NR},60,H|g)

im rauszuwählen.

ALLERDINGS scheint Asterisk alles andere als stabil damit zu laufen. Manchmal (d.h. auch wieder nur begrenzt reproduzierbar), wenn man versucht chan_dahdi manuell zu unloaden und wieder zu laden, reagiert Aterisk teils gar nicht mehr auf cli-Befehle: selbst ein "dialpan show" gibt dann nichts mehr aus...
Wie schon zuvor erwähnt kommt bei obigen Wählen der Fehler mit dem code 34 (busy/congestion) den auch andere hier beobachtet haben.

dahdi_test funktioniert inzwischen bei mir, vielleicht liegt's daran dass ich auf ein neueres dahdi umgestiegen bin?


Es funktioniert aber zumindest grundlegend mit mISDN (die entsprechenden Dial-Regeln für DAHDI auf LCR geändert), hat aber ein paar Macken weswegen ich mich mal an DAHDI versuchen wollte.


Die Sache mit 32/64 bit-Problemen auf x86 hört sich ja ungut an. Da hab ich mit meiner komplett anderen Architektur wahrscheinlich noch *richtig* Spaß, was? Wie gesagt, Big Endian...

Naja, vielleicht wird es ja doch noch was!

Gruss,
H.

 

[motte]

Hallo H.,

Ich habe das in der Reihenfolge gemacht, da ich den eigenartigen Effekt hatte dass mich asterisk mit einem Problem in der DAHDI-Konfiguration anspuckt wenn ich zaphfc zuerst lade und dann dahdi_dummy Eintrag [3] und nicht [1] ist. Warum ist mir in keinster Weise klar.

Hört sich für mich so an, als könnten die Asterisk-DAHDI-Timermodule

res_timing_dahdi.so
res_timing_pthread.so
res_timing_timerfd.so

in der von Dir genannten DAHDI-Kernelmodulinstallationsreihenfolge funktionieren!?! Umgekehrt würde ich erwarten, dass Dein Asterisk-DAHDI-Fehler nicht mehr auftritt, wenn Du diese Asterisk-Module nicht lädst - bei Autoload also in der Konfig ein noload= voranstellst.

Seit heute funktioniert es bei mir mit LCR. Die Sprachqualität könnte zwar besser sein, aber zumindest funktioniert es erstmal. Schauen wir mal, wie sich das mit DAHDI weiter entwickelt...

VG, Alex.

 

[horatio42]

Hallo Alex,

diese Timermodule lade ich nicht, sie existieren in meiner Konfiguration auch gar nicht.
Insofern ist mir auch unklar warum Asterisk bzgl. des dahdi_dummy -moduls so wählerisch ist... eigentlich müsste man - sofern man keine timer braucht - doch ganz gut ohne das auskommen, oder? Ich werde in die Richtung nochmal ein bisschen experimentieren.

Gruss,
V.

P.S.: Verdammt, den Tip mit LCR hätte ich Dir wohl besser nicht gegeben, wieder einer weniger der mit in dahdi rumwühlt?! ;-)

 

[sflemming]

Hallo allerseits,

ich probiere mich gerade mit der module load order.

Hat sich schon einmal jemand damit befasst wo die Module eingetragen werden müssen? Gibt es da Unterschiede?

Auf meiner Gentoo Maschine habe ich folgende Möglichkeiten:

1. /etc/modprobe.d/dahdi.conf
2. /etc/conf.d/modules
3. /etc/dahdi/modules

Momentan nutze ich /etc/conf.d/modules und dort drin steht:

modules="dahdi zaphfc dahdi_transcode dahdi_echocan_oslec dahdi_dummy"

 

[motte]

Hallo V.,

diese Timermodule lade ich nicht, sie existieren in meiner Konfiguration auch gar nicht.

Sie werden immer dann automatisch geladen, wenn (in Deiner Asterisk-modules.conf im Abschnitt "[modules]" kein "autoload=no" steht oder diese nicht mit "noload => ..." absichtlich nicht geladen werden) und (Du irgendein DAHDI-Modul benutzt oder das Meetme-Modul aktiv ist).

P.S.: Verdammt, den Tip mit LCR hätte ich Dir wohl besser nicht gegeben, wieder einer weniger der mit in dahdi rumwühlt?! ;-)

Ich sage mal so: Sie funktionieren unerwarteterweise zurzeit. ;-) Insofern bin ich Dir sehr dankbar! Aber vielleicht klappts ja nur für Voice - das habe ich zurzeit als einziges getestet? Vielleicht verursacht DAHDI ja auch weniger Prozessorlast und/oder arbeitet in Volllastsituationen besser? Ich habe mit DAHDI, glaube ich, so ziemlich alles probiert - ohne Erfolg. Gleichzeitig hatte ich die Woche auch viel Zeit zum experimentieren, die ich ab jetzt nicht mehr so habe. Andererseits: Wenn ich Ansätze finde, die sich wieder lohnen, würde ich es sicher nochmal probieren!

VG, Alex.

 

[motte]

Hallo Stefan,

Hat sich schon einmal jemand damit befasst wo die Module eingetragen werden müssen? Gibt es da Unterschiede?

Ich sehe das so: Die Module müssen geladen werden, bevor Asterisk startet! Und natürlich muss ein eventuell sonst automatisch geladener mISDN-Treiber geblacklistet werden. Wenn sie in modprobe.d aktiviert sind, müsste das IMHO reichen - allerdings müsste immer noch die system.conf aus /etc/dahdi greifen. Bei mir könnte dahdi aus init.d gestartet werden. Das Skript dort lädt die Module laut /etc/dahdi/modules.

modules="dahdi zaphfc dahdi_transcode dahdi_echocan_oslec dahdi_dummy"

Bei mir in /etc/dahdi/modules sinngemäß das gleiche.

VG, Alex.

 

[horatio42]

Hallo Alex,

ich habe autoload=no gesetzt; mit "nicht existieren" meinte ich dass ich die entsprechende Module nicht mal baue.

# cat /etc/asterisk/modules.conf

[modules]
autoload=no

load => pbx_config.so ; Text Extension Configuration Requires N/A
load => func_callerid.so ; Gets or sets Caller*ID data on the channel. - Requires ?
load => func_timeout.so  ; Provides the TIMEOUT function for dialplans - Requires ?
load => chan_dahdi.so
load => codec_alaw.so ; A-law Coder/Decoder - Requires N/A
load => codec_gsm.so ; GSM Coder/Decoder - Requires N/A
load => format_gsm.so ; GSM file format support - Requires N/A
load => app_dial.so ; Dialing Application - Requires res_features.so, res_musiconhold.so
load => chan_mobile.so

[global]

Ich habe halt versucht die Konfiguration minimal zu halten (nur die allernötigsten Module für mein Setup zu laden), da ich mit Speicher knapsen muss und auch Störfeuer von anderen Modulen ausschließen möchte solange ich mit dahdi experimentiere.

@alle:
Sieht aber im Moment nicht wirklich gut aus mit dahdi. Die Fehler die hier so reported werden riechen so ein bisschen nach kernel-race-conditions und/oder nicht portablem code (zwischen 32 und 64 bit).
Auch Stefans' Beobachtung dass bei Änderung des Kernel-Takts plötzlich Sachen funktionieren deuten so in die Richtung... btw, bei meiner Horstbox ist der Kernel als "tickless" konfiguriert. Ich glaube dass es viele neuere x86-Distributionen in ihrem Standard-Kernel genauso machen. Vielleicht probier ich auch mal was in die Richtung. Bei denen die es am Laufen haben: könntet Ihr mal einige diesbezügliche Details posten? Vielleicht kriegt man ja über Ausschlussverfahren zumindest raus in welche Richtung man suchen muss... Danke!
Achja: ich kann leider dahid_speed und ein paar von den anderen dahdi-tools in Ermangelung eines python-Interpreters auf der Horstbox nicht ausprobieren... ich bin nicht sicher ob es sich der Aufwand lohnt python nur deshalb für die Horstbox zu bauen? Irgendwelche Meinungen? Sind diese Tools u.U. aufschlussreich?

Danke & Gruss,
H.

 

[motte]

Hallo H./V.,

ich habe autoload=no gesetzt; mit "nicht existieren" meinte ich dass ich die entsprechende Module nicht mal baue.

Ok, das sehe ich jetzt ein Ich habe das bis auf chan_mobile, das hier nichtmal vorliegt - wozu braucht man das? - so ähnlich - und kriege seitdem keine Fehlermeldungen mehr...

VG, Alex.