Asterisk mit Bristuff - Regelmäßiges Verlieren des D-Channels

[medozas]

Hallo Liebe IPPF-Gemeinde,

nachdem ich nun wirklich am verzweifeln bin, was da los ist, wende ich mich an euch!

Ich habe eine Asterisk am laufen, die immer wieder den D-Kanal meiner Externen HFC-Karte verliert. Die Folge davon ist, dass keinerlei Anrufe von intern (egal ob ausgehend von SIP-Phone oder anderen (an der internen ISDN-Karte hängenden) Phones) nach draussen mehr können.

Allerdings funktionieren trotzdem Anrufe von aussen nach innen!

Dieses Problem lässt sich nur mittels erneutem laden des zaphfc moduls lösen, ergo kompletten restart der Anlage.

Das besonders komische an der Tatsache ist auch, dass es immer wieder in unterschiedlichen Zeitabständen passiert (1 Std. <> 8Std.). Allerdings ist ein restart mind. jeden Tag 1x erforderlich.

Ich habe auch versch. Konfigurationen m. verschiedensten Asterisk &BriStuff-Versionen probiert (angefangen von 1.2.4-1.2.13 (momentan))

Momentane Konfiguration:

Asterisk 1.2.13
BriStuff 0.3.0-PRE-1v
Florz Patch zaphfc_0.3.0-PRE-1o_florz-12

Asterisk Intern im NT Mode (Card 0) (Telefonanlage, alles OK / ISDN Cross-Over)
Asterisk Extern im TE Mode (Card 1) (an T-COM NTBA / KEIN ISDN Cross-Over (vollgeschirmtes CAT6 Patch-Kabel 100% OK)

Die Anlage ist an sich funzt so weit wirklich spitze.

Hier genaueres:

Progress eines calls nach draussen, wenn der Fall eintritt:

    -- Accepting overlap voice call from '' to '0921XXXXX' on channel 0/1, span 1
    -- Starting simple switch on 'Zap/1-1'
    -- Executing GotoIf("Zap/1-1", "0?2:3")
    -- Goto (default,0921XXXXX,3)
    -- Executing Goto("Zap/1-1", "ISDN_TO_EXTERNAL|0921XXXXX|1")
    -- Goto (ISDN_TO_EXTERNAL,0921XXXXX,1)
    -- Executing NoOp("Zap/1-1", "CALL: LIVE ISDN - EXTERNAL! FROM  to 0921XXXXX")
    -- Executing Dial("Zap/1-1", "Zap/g2/0921XXXXX|60|tT")
    -- Requested transfer capability: 0x10 - 3K1AUDIO
    -- Called g2/0921XXXXX
    -- Channel 0/1, span 2 got hangup, cause 18
  == Primary D-Channel on span 2 down
Jan 15 15:55:46 WARNING[22272]: chan_zap.c:2504 pri_find_dchan: No D-channels available!  Using Primary channel 6 as D-chann                                 el anyway!
Jan 15 15:55:46 WARNING[22405]: app_dial.c:733 wait_for_answer: Unable to forward voice
    -- Hungup 'Zap/4-1'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing HangUp("Zap/1-1", "")
  == Spawn extension (ISDN_TO_EXTERNAL, 0921XXXXX, 3) exited non-zero on 'Zap/1-1'
    -- Hungup 'Zap/1-1'
  == Primary D-Channel on span 2 down
Jan 15 15:55:51 WARNING[22272]: chan_zap.c:2504 pri_find_dchan: No D-channels available!  Using Primary channel 6 as D-chann                                 el anyway!
  == Primary D-Channel on span 2 down
Jan 15 15:55:56 WARNING[22272]: chan_zap.c:2504 pri_find_dchan: No D-channels available!  Using Primary channel 6 as D-chann                                 el anyway!
  == Primary D-Channel on span 2 down
Jan 15 15:56:01 WARNING[22272]: chan_zap.c:2504 pri_find_dchan: No D-channels available!  Using Primary channel 6 as D-chann                                 el anyway!

Was ich bei JEDEM call bekomme, egal ob mit D-Kanal oben oder nicht:

Jan 15 14:42:07 WARNING[22271]: chan_zap.c:8541 zt_pri_error: 1 copying 5 bytes LLC

Was hat es damit auf sich?

Ebenso in unregelmäßigen Abständen sehe ich in der /var/log/messages:

Jan 15 17:37:32 VoIPGW kernel: zaphfc[1]: empty HDLC frame received.
Jan 15 17:38:04 VoIPGW kernel: zaphfc[1]: empty HDLC frame received.
Jan 15 17:38:20 VoIPGW kernel: zaphfc[1]: empty HDLC frame received.
Jan 15 17:38:44 VoIPGW kernel: zaphfc[1]: empty HDLC frame received.

Wohlgemerkt egal ob da gerade was passiert im Asterisk, oder auch nicht.

zaptel.conf:

loadzone=de
defaultzone=de

span=1,1,3,ccs,ami
bchan=1-2
dchan=3

span=2,1,3,ccs,ami
bchan=4-5
dchan=6

zapata.conf:

[channels]
; 1. Karte INTERN im NT-Modus
switchtype=euroisdn
signalling=bri_net_ptmp
pridialplan=unknown
prilocaldialplan=unknown
echocancel=yes
immediate=no
usecallingpres=yes
overlapdial=yes
group=1
channel=>1-2

; 2. Karte EXTERN im TE-Modus
switchtype=euroisdn
internationalprefix=00
nationalprefix=0
language=de
pridialplan=unknown
prilocaldialplan=unknown

signalling=bri_cpe_ptmp
;AUCH SCHON NUR MIT BRI_CPE VERSUCHT - NO CHANGE
echocancel=yes
immediate=no
usecallingpres=yes
overlapdial=yes
group=2
channel=>4-5

/proc/zaptel/*:

Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [NT] layer 1 ACTIVATED (G3)" AMI/CCS

           1 ZTHFC1/0/1 Clear (In use)
           2 ZTHFC1/0/2 Clear (In use)
           3 ZTHFC1/0/3 HDLCFCS (In use)
Span 2: ZTHFC2 "HFC-S PCI A ISDN card 1 [TE] layer 1 ACTIVATED (F7)" AMI/CCS

           4 ZTHFC2/0/1 Clear (In use)
           5 ZTHFC2/0/2 Clear (In use)
           6 ZTHFC2/0/3 HDLCFCS (In use)

Es werden auch keine Interrupts geshared:

01:07.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
        Subsystem: Cologne Chip Designs GmbH ISDN Board
        Flags: bus master, medium devsel, latency 16, IRQ 217
        I/O ports at 9000 [disabled] [size=8]
        Memory at ea000000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1

01:08.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
        Subsystem: Cologne Chip Designs GmbH ISDN Board
        Flags: bus master, medium devsel, latency 16, IRQ 185
        I/O ports at 9400 [disabled] [size=8]
        Memory at ea001000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1

Die Lade-Prozedur für Asterisk:

asterisk -rx "stop now"
sleep 10
rmmod zaphfc
rmmod zaptel
modprobe zaphfc modes=1 jitterbuffer=10 timer_card=0
ztcfg -vv
asterisk
asterisk -rx "set verbose 9"

Ich hänge nun wirklich in der Luft, da ich es wirklich seit 2 Monaten versuche, diesen "Bug" rauszukriegen.

Ich kann mir überhaupt nicht vorstellen, dass es an der BriStuff-Version, Asterisk-Version, oder dem Florz-Patch liegt, da ich alle möglichen verschiedenen Versionen bereits ausprobiert habe, und es gunzt einfach nicht. Ich weiß es ja nicht, aber kann es vielleicht ein bisher unbekannter bug sein?!?!

Ich bin für jede Hilfe wirklich dankbar!

Mike

 

[Sjoko]

Habe das gleiche Problem in Holland;

ISDN provider: KPN
normaler ISDN anschluss: 2 sprache + 1 D kanal
asterisk: 1.2.9.1-BRIstuffed-0.3.0-PRE-1r
modified libpri: "outgoing isdn call keeps ringing"
see :http://sourceforge.net/forum/forum.php?thread_id=1437025&forum_id=420324
system: Debian Linux 2.6.8-12-amd64-k8
ISDN-Karte: zapHFC von Conrad

vorlaefige loesung:
jede minutie uber cron ein anruff ueber AMI damit das kanal hoch bleibt.

mit while true; do echo "`date` `grep "(F" /proc/zaptel/1`"; sleep 2; done
sieht man ob das kanal da ist oder nicht.

Es scheint alsob der zaphfc treiber in ordnung ist (weil /proc/zaptel/1 das immer korrekt signalisiert) , nur Asterisk bekommt irgendwie nicht mit das der Kanal weg ist. Its das ein libpri problem ?

Es ist mir mittlerweile bekannt das KPN das Kanal mal runter und hoch schaltet.

Kann es sein das bei eine standard KPN ISDN anschluss, das Kanal gepollt werden muss oder so eine Art von keep-alive gesendet werden muss damt KPN das Kanal hoch haltet ?
Ich kann aber nichts in die *-configuration finden womit man so ein keep-alive einstellt.

 

[medozas]

Resetinterval Einstellung - bei mir allerdings ohne effekt

Hallo sjoko,

versuch mal in deiner zapata.conf, ob deine Anlage den parameter resetinterval verträgt. Ich hatte es bei mir versucht, auch mit 60 Sekunden, allerdings gab es bei mir keinen Effekt.

resetinterval: sets the time in seconds between restart of unused channels,
defaults to 3600 minimum 60 seconds. Some PBXs don't like channel restarts. 
so set the interval to a very long interval e.g. 100000000 or 'never' to disable
*entirely*.

Zu finden unter http://www.voip-info.org/wiki/index.php?page=Asterisk+config+zapata.conf

---

Der Rechner ist ein Athlon XP 3000+ mit 1GB RAM (ohne andere Dienste am Laufen), also denke ich, dass es nicht an der Performance der Kiste liegen kann.

Was ich allerdings auch festgestellt habe, ist das ich mittels auschalten von ACPI den Zeitintervall verlängert habe. Ich werde mich dieser Sache annehmen, und evtl. noch weiter dieses Problem auflösen. Tatsächlich habe ich da mit

System uptime: 3 days, 5 hours, 14 minutes, 2 seconds

die längste uptime jemals. Es kommt zwar noch vor, dafür aber um EINIGES seltener. => Wohlgemerkt: Es werden (und wurden vorher auch schon) keine Interrupts geshared.

Sollte jemand auch ACPI ausschalten wollen (zum test):

acpi=off

in den boot-prompt noch mitreingeben, und evtl. in der /boot/grub/menu.lst (bei grub) miteintragen (dauerhaft).

Viel Erfolg! :rock:

Mike

 

[Sjoko]

Resetinterval Einstellung - auch ohne effekt

Hi Mike,

das mit den resetinterval hatte ich auch schon probiert, bringt gar nichts.
Vieleicht kann man noch etwas im zaptel.conf einstellen.
Aber ich finde keine richtige doku.
Ich habe jetzt:

loadzone=nl
defaultzone=nl
span=1,1,3,ccs,ami
bchan=1-2
dchan=3

Und was bedeutet LBO (The line build-out (or LBO)).
hat das mit die laenge des anschluss-drats zu tun, und vieleicht mit latency ?

Ich bin ahnungslos.

 

[medozas]

Vielleicht eine Hilfe bei dir?

das mit den resetinterval hatte ich auch schon probiert, bringt gar nichts.
Vieleicht kann man noch etwas im zaptel.conf einstellen.
Aber ich finde keine richtige doku.

Dokumentieren tun Sie alles schon, nur findet sich meistens auf normalem wege dass alles nicht ganz so leicht, da diese Sites nicht unbedingt bei google, etc. ganz oben stehen (denke ich)

Was ich dir empfehlen kann ist die Direkte Asterisk Dokumentation:
http://www.asterisk.org/doxygen/1.2/Config_zap.html
bzw. bei
http://www.asterisk.org/doxygen/1.2/main.html die Startseite.
----------

loadzone=nl
defaultzone=nl
span=1,1,3,ccs,ami
bchan=1-2
dchan=3

Sieht ganz gut aus!

Und was bedeutet LBO (The line build-out (or LBO)).
hat das mit die laenge des anschluss-drats zu tun, und vieleicht mit latency ?

span = <span num>,<timing>,<line build out (LBO)>,<framing>,<coding>[,yellow]

<span num> bezeichnet die Portnummer und <timing> beschreibt, ob dieser Port eine Timingquelle für Asterisk darstellt und, falls ja, mit welcher Priorität diese verwendet werden soll. Timingquellen dienen zur Synchronisation der Kommunikation auf dem PRI-Interface. Mit <LBO> wird die Leitungsdistanz zum "Ubergabepunkt der PRI-Leitung in Schritten von ca. 40m angegeben. <framing> gibt die Einteilung der vorhandenen Kanäle auf die einzelnen Zeitschlitze vor - für europäische PRI-Anschlüsse wird fast ausschliesslich ccs verwendet. Das "Ubertragungsprotokoll für die jeweilige Leitung wird mit <coding> definiert und ist für E1-Leitungen üblicherweise hdb3,crc4. yellow weist Asterisk an, bei festgestellten Fehlern auf der PRI-Leitung dies der Gegenstelle mittels eines sogenannten 'Yellow-Alerts' zu signalisieren.

Ich bin ahnungslos.

Waren wir alle mal, oder sind es noch heute

 

[Sjoko]

In Koeln habe ich die fast die gleiche Konfiguration, allerdings auf i386 basis und die kiste hat 2 hfc karten (beide im TE modus).
Dort alles prima. Es wird auch signalisiert im *-CLI das das D-Kanal down ist wenn mann den ISDN stecker zieht.

Es gibt wolh doch ein unterschied zwischen Deutschen ISDN protokol und Niederlaendischen ISDN Protokol.

 

[medozas]

BRI debug

Hi,

mach doch mal auf beiden einen

bri debug intense span <x>

auf beiden, und poste den mal. Setze dazu einfach mal einen call auf beiden ab, und paste hier doch kurz den output, dann kann man Unterschiede feststellen.

Mike

 

[Sjoko]

HauptProblem geloest;

Ich hab mit KPN telefoniert.
Den erklaert das das D-kanal (Primary D-Channel) mit regelmass wegfaelt und das mein server da probleme mit hat. Die haben ein internen ticket aufgemacht.
Zuerst haben wir noch versucht den DSL splitter wegzunehmen, aber das hat nichts gebracht.
Dan irgendwan waehrend des Tages ist die leitung stabil geworden, die haben offensichtlich etwas gemacht.
Die haben sich aber nicht mehr gemeldet.

Ich hab die heute angerufen um zu fragen was genau das problem war;
Problem war folgendes; Die sync ist immer wieder weggefallen. Die haben jetzt den sync fest angemacht oder gesetzt (auf continues gesetzt).
Das passiert manchmal wenn man DSL & ISDN hat. Den is das Problem ist den offensichtlich nicht unbekannt.

Ich denke das meine HFC karte entweder nicht resysncen kann oder vieleicht ist das timing zu intolerant und kann es nicht umgehen mit slechte verbindungen.

Hat einer hier noch eine idee ?

Bleibt nur noch ein Problem; Wenn ich den ISDN stecker ziehe, das komt keine meldung im *-CLI das der Primary D-Channel down ist, nur wenn ich es wieder reinstecke, dan kommt "Primary D-Channel UP".

Hat einer hier auch noch eine idee ?

 

[hehol]

Hallo,

am ISDN-Mehrgeräteanschluß (PTMP) ist es häufig üblich, daß die Vermittlungsstelle bei Inaktivität nach einiger Zeit den Layer 1 deaktiviert. Die Signalisierung wird erst wieder eingeschaltet, wenn ein Anruf reinkommt oder durch das angeschlossene Endgerät wieder aktiviert wird. Bei der Deutschen Telekom kann man den ISDN-Anschluß auf Wunsch "daueraktiv" konfigurieren lassen. Das sollte die beobachteten Effekte beheben. Sjoko, wahrscheinlich hat KPN genau diese Änderung an Deinem Anschluß vorgenommen.

Der zaphfc-Treiber scheint vor dem Wählen auf einem Port zu überprüfen, ob der Layer 1 aktiv ist und gar nicht erst einen Wählvorgang zu starten, wenn der Anschluß offenbar inaktiv ist. Am Mehrgeräteanschluß sollte der Treiber aber besser erstmal einen Wählversuch starten, bevor er den Port für "congested" erklärt. In chan_misdn gibt es dafür die Option pmp_l1_check=no. Weiß jemand, ob es einen entsprechenden Parameter auch für bristuff gibt?

Henning

 

[o_dapenguin]

!! Selbes Problem !!

Hallo !
Ich denke, dies ist ein Hardware- / Leitungsproblem auf seiten des Providers, sonst hätten doch noch mehr Leute das Problem, oder ?

Auch bei mir durchgehend Warnungen alle 1-2 Sekunden, die Verbindungen sind nicht beeinträchtigt, wohl aber die Arbeit für den Admin in der CLI ....

No D-channels available!  Using Primary channel 6 as D-channel anyway!
Detected alarm on channel 4: Red Alarm
Detected alarm on channel 5: Red Alarm

Nur der Vollständigkeit halber die Configs, an denen es nicht liegt ...
Zapata.conf

; Zapata telephony interface
; Configuration file
[channels]
;
; Default language
language=de
;
switchtype = euroisdn
pridialplan = local
prilocaldialplan = local
nationalprefix = 0
internationalprefix = 00
overlapdial = yes

; p2mp TE mode (for connecting ISDN lines in point-to-multipoint mode)
;signalling = bri_cpe_ptmp
; p2p TE mode (for connecting ISDN lines in point-to-point mode)
signalling = bri_cpe

echocancel = yes
echocancelwhenbridged = yes ;
echotraining = no ;
immediate = no

context=ISDN-extern
group = 1
; S/T port 1,2,3
channel => 1,2,4,5,7,8

;group = 2
; S/T port 2
;channel => 4-5

;group = 3
; S/T port 3
;channel => 7-8

; p2mp NT mode (for connecting ISDN phones in point-to-multipoint mode)
signalling = bri_net_ptmp
; p2p NT mode (for connecting an ISDN pbx in point-to-point mode)
;signalling = bri_net

context=ISDN-intern

group = 4
; S/T port 4
channel => 10-11
;rxgain = 0.0
;txgain = 0.0

und
Zaptel.conf

loadzone=nl
defaultzone=nl
# qozap span definitions
# most of the values should be bogus because we are not really zaptel
span=1,0,3,ccs,ami
span=2,0,3,ccs,ami
span=3,0,3,ccs,ami
span=4,0,3,ccs,ami

bchan=1,2
dchan=3
bchan=4,5
dchan=6
bchan=7,8
dchan=9
bchan=10,11
dchan=12

Die ISDN-Interfacekarte (Junghanns QuadBRI) zeigt für Span 2 Alarm / rot, alle anderen LEDs sind grün. Die Terminierung auf der Karte hab ich noch einmal überprüft / ist korrekt.
Die Kabel von den 3 NTBAs des TCOM Anlagenanschlusses sind nun schon 2x überprüft und ausgetauscht. Alles ohne Effekt.

Hier die entsprechenden Protokolle aus der CLI:

*CLI>pri intense debug span 2
2 Sending Set Asynchronous Balanced Mode Extended
2
> [ 00 01 7f ]
2
> Unnumbered frame:
2 > SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        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 01 7f ]
2
> Unnumbered frame:
2 > SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        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

Span 2 ist In Alarm und Down ... als ob ich das nicht schon dauernd mit lästigen WARNINGS in der CLI gesagt bekäme ....

*CLI>pri show span 2
Primary D-channel: 6
Status: Provisioned, In Alarm, Down, Active
Switchtype: EuroISDN
Type: CPE
Window Length: 0/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: -1
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T313 Timer: 4000
N200 Counter: 3

Span 1 und 3 ohne Probleme:

*CLI>pri show span 1
Primary D-channel: 3
Status: Provisioned, Up, Active
Switchtype: EuroISDN
Type: CPE
Window Length: 0/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: -1
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T313 Timer: 4000
N200 Counter: 3

*CLI> pri show span 3
Primary D-channel: 9
Status: Provisioned, Up, Active
Switchtype: EuroISDN
Type: CPE
Window Length: 0/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: -1
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T313 Timer: 4000
N200 Counter: 3

Hmmm, der D-CHannel ging auch schon früher mal "verloren", allerdings kommen die aufdringlichen Meldungen, die einem die Arbeit in der CLI (z.B. beim Dialplan debuggen / erweitern) unmöglich machen, erst seit BRIStuff 0.3.0-PRE...
Hab nun heute auf BRIStuff 0.3.0-PRE-y-h geupdatet, - leider mit denselben WARNINGs die ganze Zeit. Dachte mir eigentlich schon, dass das kein Treiber- sondern ein Hardware- bzw. Leitungsproblem sein muss.
Hat jemand eine Idee oder dasselbe Problem. Bringt ein Anruf bei der TCOM was ?
Grüße
o_dapenguin

 

[o_dapenguin]

Ok .... SuperGAU. Ganze 4 Stunden lief mein *, bevor ohne Vorwarnung in jeglichen Logs (ob system- oder asteriskbezogen) nachts um 4:35h der Ausstieg erfolgte. Die Serverkonsole blank, nicht mehr anzupingen, tot ... Neustart mit Brachialgewalt und er läuft wieder .... Frage - wie lange ? Frage - lag's an Span 2 (s.o.) ? In 0.3.0_PRE-r waren die Fehler auch da, die Anlage lief jedoch durch, bis auf die Abstürze, wenn man versuchte qozap.ko zu entladen ... hmmm ... Downgrade ?


Ein verwunderter
o_dapenguin
, der Blankscreenz bislang nur aus der W1nd0wswelt kannte

 

[o_dapenguin]

Gelöst

Naja, zumindest unser Problem war - nach langem Suchen und den schon geäußerten Mutmaßungen - ein Problem aus seiten der TCom ... allerdings nicht in der Vermittlungsstelle. Die konnten jedoch den defekten NTBA vor Ort bestätigen (der an der 2. WuadBRI Schnittstelle eben), er wurde dann ausgetauscht und Voilá ... keine Fehler mehr !!
Seltsam: Am betreffenden NTBA selbst wurde kein Fehler signalisiert (eigene Leuchtdiode), nur an der QuadBRI und in der Software, noch seltsamer: der Techniker behauptete, wenn er sein Diagnosetelefon dranstöpsele und die Anlage (*) ab, dann melde die Vermittlungsstelle keinen Fehler mehr.
Hat es sich um einen Defekt gehandelt, der NUR die QuadBRI beeinträchtigte und das Diagnosetelefon der TCom nicht ?
Sei es wie es will, der NTBA war's und alle sind wieder glücklich ... waren ja in der Zwischenzeit immerhin noch über 4 Leitungen (statt 6) erreichbar, ohne dass eine bestimmte Nummer nicht ging -- der Vorteil eines Anlagenanschlusses eben.

Es grüßt ein übernächtigte aber froher
o_dapenguin

 

[XxXenoxxX]

wir haben das selbe problem

bri intense debug span 3:
3
> [ 02 01 7f ]
3
> Unnumbered frame:
3 > SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
3 >   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
> 0 bytes of data

pri show span 3:

Primary D-channel: 37
Status: Provisioned, Down, Active
Switchtype: EuroISDN
Type: Network
Window Length: 0/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: -1
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T313 Timer: 4000
N200 Counter: 3

zapata conf

[channels]
language=de
overlapdial=yes
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=no
callerid=asreceived

jitterbuffers=36

rxgain=0.0
txgain=0.0

callgroup=1
pickupgroup=1
immediate=no

internationalprefix=00
nationalprefix=0
localprefix=07225
privateprefix=0722590900

switchtype=euroisdn

;the E1
group=1
signalling=pri_cpe
pridialplan=unknown
prilocaldialplan = national
context=isdn-incoming
channel => 1-15,17-31

; Fax BRI's:
group=2
context=faxserver-outgoing
signalling=bri_net
channel => 32,33,35,36

;Zusaetzliche BRI's
group=3
context=isdn-intern
;signalling=bri_cpe_ptmp
signalling=bri_net
channel => 38,39,41,42

also am span 3 haben wir unsere aktiven isdn karten unseres fax server angehängt
nur verlieren wir in regelmäßigen abständen den d-channel, und es funktioniert kein faxen mehr

im einsatz sind 1 junghanns singleE1 und eine QuadBri
Asterisk ist 1.2.22-BRIstuffed-0.3.0-PRE-1y-i

mfg
matthias

 

[DomRoc]

Hallo,

ich kann dieses Problem auch bestätigen, und kurioserweise liegt es bei mir nicht an irgendwelchen Einstellungen der Telefongesellschaften sondern an einer AGFEO-Anlage.
Der Asterisk ist über einen internen S0 mit der AGFEO verbunden, bei mir ist das Span 12. Ich hatte immer das Problem, dass manchmal Gespräche über diesen Span 12 plötzlich unterbrochen wurden. Wenn man gleich darauf neu gewählt hat konnte man das Gespräch gleich wieder herstellen. Dazu passt dann auch folgende Ausgabe auf der CLI:

== Primary D-Channel on span 12 down
== Primary D-Channel on span 12 up


Das andere Problem ist aber auch schon aufgetreten. Laut Asterisk ist auch schonmal der komplette 12 Span besetzt, obwohl dort nachweislich alles frei ist. Hier kommt es dann zu genau dem gleichen Fehler wie beim Thread-Starter: everyon is busy --> Congestion

Hier hilft dann auch bei mir nur ein Neustart der Asterisk-Software. Ob ein ZAP-Restart auch ausreicht hab ich noch nicht getestet.


Der LBO Parameter steht bei mir immer auf 3, also wie folgt:

# Karte Nummer 1 (4x TE und 4x NT):
span=10,1,3,ccs,ami
span=11,2,3,ccs,ami
span=12,3,3,ccs,ami
span=13,4,3,ccs,ami
span=14,0,3,ccs,ami
span=15,0,3,ccs,ami
span=16,0,3,ccs,ami
span=17,0,3,ccs,ami

Für die paar Meter ISDN-Bus sind Cat5e UTP Kabel im Einsatz. Ich werde mal testen, ob es da was bringt geschirmte Kabel einzusetzen.
An der AGFEO lässt sich zum ISDN-Bus-Verhalten leider nicht viel einstellen.

Ich würde gerne mal über mehrere Tage einen PRI-Debug mitlaufen lassen. Allerdings funktioniert bei mir der Befehl "pri set debug file" nicht richtig.
Es kommt nur immer "Invalid usage, but no usage information available."

Oder bin ich nur zu doof den korrekt aufzurufen?
"pri set debug file /var/log/asterisk/pridebug.log"

Vielleicht weiß da ja jemand bescheid!

Vielen Dank und schöne Grüße,
DomRoc