Probleme mit Junghanns QuadBRI an Versatel Anlagenanschluss

[mhamann]

Hallo Allerseits,

ich habe seit einiger Zeit erhebliche Probleme eine Junghanns QuadBRI Karte unter Kernel 2.6.15, Asterisk 1.2.4 sowie den dazugehörigen briStuff Treibern 0.3.0-PRE-1l.

Die Karte wird dabei auf allen Ports im TE Modus betrieben, teilt sich keinen Interrupt.

Angeschlossen sind daran 3 S0 Anschlüsse folgender Anbieter:

1x S0 T-Com PTMP Anschluss (Port 1)
2x S0 Versatel Anschluss (Port 2-3) - Port 4 -> frei (bei dem Versatel Anschluss wurde eine Dauersignalisierung von Layer1+2 eingerichtet)

Nach Initialisierung und starten des Asterisk sind die entsprechenden LEDs an der Karte grün. Auch unter /proc/zaptel/1-3 ist der Layer2 jeweils als "ACTIVATED" angezeigt.

Die Karte ist dabei über die zaptel.conf folgendermassen eingerichtet:

defaultzone=de
span=1,1,3,ccs,ami
span=2,2,3,ccs,ami
span=3,3,3,ccs,ami
span=4,4,3,ccs,ami
bchan=1,2
dchan=3
bchan=4,5
dchan=6
bchan=7,8
dchan=9
bchan=10,11
dchan=12

Die dazugehörige zapata.conf:

signalling=bri_cpe_ptmp
group=2
echocancel=yes
echocancelwhenbridged=yes
callerid=asreceived
context=isdn-incoming
channel => 1-2

signalling=bri_cpe_ptp
group=1
overlapdial=yes
immediate=no
echocancel=yes
echocancelwhenbridged=yes
callerid=asreceived
context=isdn-incoming
channel => 4-5
channel => 7-8
channel => 10-11

Das merkwürdige ist, dass der T-Com PTMP Anschluss völlig problemlos funktioniert, der Anlagenanschluss jedoch lediglich die folgende Meldung bringt:

== Primary D-Channel on span 2 down
== Primary D-Channel on span 3 down

Ein pri intense debug span 2 beispielsweise bringt folgende Meldung:

> Unnumbered frame:
2 > SAPI: 00 C/R: 0 EA: 0
> TEI: 098 EA: 1
2 > M3: 3 P/F: 1 M2: 3 11: 3 [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data
2 Sending Set Asynchronous Balanced Mode Extended
2
> [ 00 c5 7f ]

Ein weiterer Auszug aus dem Debugging:

2006-04-24 18:35:23 VERBOSE[3427] logger.c: == Primary D-Channel on span 3 down
2006-04-24 18:35:23 DEBUG[3429] chan_zap.c: Monitor doohicky got event Alarm on channel 7
2006-04-24 18:35:23 WARNING[3429] chan_zap.c: Detected alarm on channel 7: Red Alarm
2006-04-24 18:35:23 WARNING[3429] chan_zap.c: Unable to disable echo cancellation on channel 7
2006-04-24 18:35:23 DEBUG[3429] chan_zap.c: Monitor doohicky got event Alarm on channel 8
2006-04-24 18:35:23 WARNING[3429] chan_zap.c: Detected alarm on channel 8: Red Alarm
2006-04-24 18:35:23 WARNING[3429] chan_zap.c: Unable to disable echo cancellation on channel 8
2006-04-24 18:35:23 NOTICE[3427] chan_zap.c: PRI got event: Alarm (4) on Primary D-channel of span 3
2006-04-24 18:35:23 NOTICE[3427] chan_zap.c: pri_shutdown
2006-04-24 18:35:23 DEBUG[3427] chan_zap.c: Got event Alarm (4) on D-channel for span 3
2006-04-24 18:35:23 DEBUG[3429] chan_zap.c: Monitor doohicky got event No more alarm on channel 7
2006-04-24 18:35:23 NOTICE[3429] chan_zap.c: Alarm cleared on channel 7
2006-04-24 18:35:23 DEBUG[3429] chan_zap.c: Monitor doohicky got event No more alarm on channel 8
2006-04-24 18:35:23 NOTICE[3429] chan_zap.c: Alarm cleared on channel 8
2006-04-24 18:35:23 NOTICE[3427] chan_zap.c: PRI got event: No more alarm (5) on Primary D-channel of span 3

Das merkwürdige ist, dass beim Anschluss der alten (Siemens HiCom 150) Telefonanlage der Anschluss sofort funktioniert, andersherum ist es jeodch so, dass beim Simulieren eines Standard Anlagenanschlusses über ein ISDN Testgerät die Verbindung zur QuadBRI funktioniert. Auch an einer Siemens Hipath 4000 läuft die Karte zuammen mit 3x PTP völlig problemlos.

Der auf der gleichen Karte befindliche PTMP Anschluss funktioniert stets einwandfrei, ledigich die beiden (laut Versatel Standard) Anlagenanschlüsse funktionieren nicht.

Auch ein Kartentausch der QuadBRI brachte hier keine Verbesserung. Aus Sicht der Vermittlungsstelle ist nur sichtbar, dass Layer 2 nicht hochkommt, sonstige Fehler sind auf der Leitung nicht sichtbar. Kabel und NTBAs sind schon getauscht worden, es treten auch keinerlei CRC Fehler auf der Leitung auf, zumal die bisherige Anlage sowie ein Aurora ISDN Testgerät an dem Anschluss problemlos funktionieren.

Kabel wie auch NTBAs wurden testweise und leider ohne Besserung getauscht.

Ich bin langsam am Ende meines Lateins angekommen... Hat hier jemand eine Idee was noch zu tun ist? Ist an der Konfiguration was nicht korrekt?

Würde mich über jede Art von Tipps oder Unterstützung sehr freuen.

mit Grüßen aus Freiburg
Michael Hamann

 

[clan]

Was sagt denn der zap-channel beim starten des Asterisk? In deiner zapata.conf steht 'signalling=bri_cpe_ptp', in einer ähnlichen Konfiguration hier steht nur 'bri_cpe'. Möglicherweise wird der Anschluß deswegen ignoriert?

 

[mhamann]

Was sagt denn der zap-channel beim starten des Asterisk? In deiner zapata.conf steht 'signalling=bri_cpe_ptp', in einer ähnlichen Konfiguration hier steht nur 'bri_cpe'. Möglicherweise wird der Anschluß deswegen ignoriert?

Hmm da stimme ich dir so zu. Habe gerade nochmal in der Junghanns Beispiel Konfiguration nachgeschaut. Dort steht nur bri_cpe - ich habe in verschiedenen Quellen im Netz jedoch auch die Anweisung bri_pri_ptp gefunden.

Asterisk bringt mir hier auch keine Fehlermeldung beim Start:

[chan_zap.so] => (Zapata Telephony w/PRI)
== Parsing '/etc/asterisk/zapata.conf': Found
== Registered application 'zapEC'
== Registered application 'zapCD'

Die Sache ist ja auch die, dass der Anschluss an einer Siemens Anlage als PTP-TE, wie auch an einem Aurora Testgerät funktioniert. Nur nicht an besagtem Versatel Anlagenanschluss.

Leider brachte auch die Änderung auf bri_cpe keine Änderungen im positiven Sinne...