mISDN und Beronet BN2E1 vor Alcatel OmniPCX

[schlaile]

Hallo zusammen,

ich werde gerade noch ziemlich wahnsinnig mit folgender Konfiguration:

PRI Amt -> BN2E1 -> Asterisk -> BN2E1 -> Alcatel OmniPCX

Rufe direkt aus der Asterisk auf's Amt funktionieren tadellos. (Mittels SIP -> Asterisk -> BN2E1 -> Amt). Genauso wie Amt -> Asterisk tadellos funktioniert. (z.dt. mit der Telekom verstehe ich mich prächtig, was nicht jeder von sich behaupten kann )

Rufe Asterisk -> Alcatel OmniPCX werden von der OmniPCX nach kurzer Zeit mit cause=18 (Teilnehmer antwortet nicht) abgewehrt, obwohl der Dialstring exakt den des Amtes abbildet. (D.h. alle Wahlpläne passen, Caller-ID passt, Zielrufnummer passt, habe ich was vergessen?)

Rufe OmniPCX -> Asterisk werden kurz aufgebaut und dann im gleichem Atemzug von der Alcatel-Anlage mit cause=44 (Keine angeforderte Gasse/Kanal) terminiert.

Nach einem "misdn restart port" auf beiden Ports habe ich es bereits geschafft, zumindest kurz eine Verbindung OmniPCX -> Asterisk -> Amt aufzubauen (, die jedoch nach wenigen Sekunden wiederum von der Alcatel-Anlage mit cause=44 abgeschossen wird).

Hat irgendeiner von Euch sowas am Laufen und weiß, was man hätte machen sollen (neben Alcatel verfluchen und/oder Schnittstellen-Karte verbrennen ) ?

Anreiz das zu lösen wäre, daß ich dann den OSLEC Echo-Cancellierer endlich fertig entwickeln könnte, weil ohne eine Lösung für dieses Problem kann ich hier nicht produktiv gehen und damit auch nicht in einer Live-Umgebung testen.

Viele Grüße,
Peter

--
Linux 2.6.22.5
Asterisk 1.4.17
misdn GIT current
Beronet BN2E1
Alcatel OmniPCX R1.X/R2.X Business (Software-Version ALZAA210/021.003)

[sterkel]

Zitat von schlaile

machen sollen (neben Alcatel verfluchen

Das hilft immer!

Schalte mal das misdn-NT-Debug ein, vielleicht findet sich dann im Logfile ein Hinweis.

ntdebugflags=0xffffffff (ist wahrscheinlich zuviel, 0x000000c3 evtl).
ntdebugfile=/var/log/misdn-nt.log

[schlaile]

so langsam komme ich dahinter:

Obwohl in meiner /etc/mISDN.conf

<card type="BN2E1" watchdog="yes" crystalclock="yes">
<port mode="te" link="ptp">1</port>
<port mode="nt" link="ptp">2</port>
</card>

steht, also beide Ports explizit als PTP gekennzeichnet sind, passiert beim Laden der Module das hier:

/sbin/modprobe --ignore-install hfcmulti type=0xc0001,0xc0801 protocol=0x22,0x12 layermask=0xf,0x3 poll=32 debug=0 timer=0

Und asterisk verkündet fröhlich einen PTMP NT-Port gefunden zu haben.
Läd man es von Hand mit

/sbin/modprobe --ignore-install hfcmulti type=0xc0001,0xc0801 protocol=0x22,0x22 layermask=0xf,0x3 poll=32 debug=0 timer=0

kommt zwar:

P[ 0] Got: 1ptp,2ptp from get_ports

aber gleich zur Ernüchterung auch ein

P[ 1] Cannot register layer 4 of this port.

(dmesg meint dazu noch:

mISDN: INTERNAL ERROR in /usr/src/mISDN/drivers/isdn/hardware/mISDN/stack.c:1014 register duplicate 40000100 i1(d1fbfe0c) i2(d1dd7400) i1->st(d5b2b000) i2->st(d267dc00) st(d5b2b000)

)

Ergebnis: keiner mag mich. Interessant aber: kurzfristig konnte ich sogar mal von der Asterisk eine Nebenstelle der Alcatel läuten lassen. (Nachdem ich /etc/init.d/mISDN restart vollzogen hatte und asterisk beim neuen Start plötzlich immer noch der Meinung war, einen PTP Port zuhaben.)

@sterkel: habe mal entsprechende Logfiles erstellt, siehe hier:
http://peter.schlaile.de/mISDN/misdn-nt-call-out.log
bzw. parallel das misdn-Asterisk-Log:
http://peter.schlaile.de/mISDN/misdn...k-call-out.log

(XXXSRC und XXXDST sind natürlich im echten Leben vernünftige Telefonnummern )

Ich kann da nichts erkennen, außer vielleicht, daß mir selbst im Idle-Zustand zuviele Nachrichten hin- und hergeworfen werden. (Und natürlich, daß mISDN anfängt zu tilten, wenn Alcatel mitten in der Aufbau-Phase des Amts-Rufes kurzerhand die Reißleine zieht...)

Viele Grüße,
Peter

[schlaile]

mit dem folgenden Patch, starten zumindest beide Ports korrekt im PTP Modus:

--- /usr/src/mISDN/config/mISDN.conf.bnx.xsl 2008-02-01 23:44:59.000000000 +0100
+++ ./mISDN.conf.bnx.xsl 2008-02-10 13:34:41.000000000 +0100
@@ -173,7 +173,7 @@
<xsl:with-param name="match-true">te</xsl:with-param>
<xsl:with-param name="match-false">nt</xsl:with-param>
<xsl:with-param name="val-true">34</xsl:with-param>
- <xsl:with-param name="val-false">18</xsl:with-param>
+ <xsl:with-param name="val-false">50</xsl:with-param>
<xsl:with-param name="val-default">34</xsl:with-param>
</xsl:call-template>
<xsl:text>+</xsl:text>

----------
Und wir sind insofern einen Schritt weiter, als daß die Alcatel-Anlage konsequent eingehende _und_ ausgehende Telefonate mit cause=44 ins Nirvana befördert.

(Man muß bei solchen Experimenten immer daran denken, _alle_ misdn-Treiber raus und wiederreinzuwerfen, sonst wird man mit diesem lästigen Layer4-Fehler bestraft).

Naja,
Peter

[schlaile]

Hallo zusammen,

habe jetzt die Lösung (oder zumindest einen Workaround):

bristuff installieren, cwain patchen (beronet-Patch: http://blog.eth0.cc/zaptel-patchwork/, möglicherweise noch zur Sicherheit: http://peter.schlaile.de/zaptel/cwain.patch drauf, damit der Watchdog auch wirklich anzieht.)

/etc/init.d/mISDN stop

modprobe cwain

kurz warten

rmmod cwain

/etc/init.d/mISDN start

asterisk -c

=> läuft.

Vermutung: irgend ein subtiles Detail ist in der Karteninitialisierung vom hfc_multi noch falsch, was bestimmte Anlagen (z.B. Alcatel ) aus der Bahn wirft.

Viele Grüße,
Peter

[schlaile]

Hallo,

um das vernünftige Endergebnis google-bar zu machen:

mISDN NT-Modus hatte eine fehlerhafte Port-Restart-Implementierung. Im TE-Modus geht alles insofern glatt, als daß das Amt zufrieden ist, wenn die Asterisk einen RESTART schickt und den Acknowledge ignoriert. Auf NT-Seite schickt die Alcatel einen Restart und mISDN leider keinen Acknowledge. Alcatel befindet dann (korrekterweise) den gesamten Anschluß für tot und schickt weiter fleißig Restarts. Daß das mit dem cwain-Treiber funktioniert hat, liegt vermutlich am geschickten Timing (cwain unterbricht, Alcatel schickt Restart, danach ist der Port wieder kurz zum Amt durchgeschaltet, Amt schickt Acknowledge, dann läd der mISDN und Alcatel ist glücklich.)

Ernsthafte Lösung: entweder auf aktuellen mISDN 1.1.8 upgraden oder besser, gleich den socket-branch nehmen, dann läßt sich mittels LCR nämlich das gesamte ISDN-Wählverhalten korrekt abbilden. (Asterisk wählt konsequent nur mit Complete. Anwenderempfindung: mangelhaft. Entweder muß man einen hohen Timeout bei wait4digits setzen oder die Asterisk wählt schon los, bevor alle Ziffern da sind.)

An dieser Stelle übrigens noch einmal ein großes Lob an Andreas Eversberg, ohne dessen Geduld das Problem wohl in absehbarer Zeit keiner richtig behoben hätte!

Übrigens: der socket-branch ist _wirklich_ stabil. Ich habe bis jetzt _keine_ einzige Kernel-Panic mit dem Ding hinbekommen!

Viele Grüße,
Peter