pri_find_dchan: No D-channels available!

[geistio]

Abend!
Also ich habe folgendes Problem:
Asterisk 1.4.17-BRIstuffed-0.4.0-test6 zeigt mir beim Start folgendes an:

[Apr  1 21:17:21] WARNING[9636]: chan_zap.c:2513 pri_find_dchan: No D-channels available!  Using Primary channel 6 as D-channel anyway!
[Apr  1 21:17:26] WARNING[9635]: chan_zap.c:2513 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!

Die 2 Longshine HFC-S Karten werden folgendermaßen geladen und konfiguriert:

chef:~# cat /etc/modprobe.d/zaphfc 
options zaphfc modes=2 sync_slave=2 timer_card=0

#######################################
chef:~# cat /etc/zaptel.conf
loadzone=at
defaultzone=at

# 1.Karte (extern)
span=1,1,3,ccs,ami
bchan=1-2
dchan=3

# 2.Karte (intern)
span=2,1,3,ccs,ami
bchan=4-5
dchan=6

#######################################
chef:~# cat /etc/asterisk/zapata.conf
[channels]

; p2p TE mode  => bri_cpe
; p2mp TE mode => bri_cpe_ptmp
; p2p NT mode  => bri_net
; p2mp NT mode => bri_net_ptmp

language=de

switchtype=euroisdn

pridialplan=local
prilocaldialplan=local

nationalprefix=0
internationalprefix=00

immediate=no
overlapdial=yes

echocancel=yes
echocancelwhenbridged=no

;
; 1. Karte (extern)
;
signalling=bri_cpe
group=1
context=isdn-extern
channel => 1,2

;
; 2. Karte (intern)
;
signalling=bri_net
group=2
context=isdn-intern
channel => 4,5

dmesg zeigt mir beim Laden von zaphfc.ko folgendes an:

zaphfc: jitterbuffer size: 1
PCI: Enabling device 0000:00:01.0 (0000 -> 0003)
zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xee1d8400 fifo 0xe5738000(0x4ed9d000) IRQ 17 HZ 250
zaphfc: Card 0 configured for TE mode
zaphfc: Card 0 configured for master mode
zaphfc: hfc busy.
PCI: Enabling device 0000:00:02.0 (0000 -> 0003)
zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xee1e4000 fifo 0xe55f8000(0x4eedd000) IRQ 16 HZ 250
zaphfc: Card 1 configured for NT mode
zaphfc: Card 1 configured for slave mode
zaphfc: hfc busy.
zaphfc: 2 hfc-pci card(s) in this box.

Das Problem tritt nur auf, wenn ich P2P Verbindungen herstellen möchte, d.h. wenn ich statt bri_cpe und bri_net, bri_cpe_ptmp und bri_net_ptmp in der zapata.conf setze, scheint die Fehlermeldung nicht auf.
Da ich aber in Österreich lebe und einen ISDN Anlagenanschluss habe, ist dies für mich keine Lösung des Problems...
Hat jemand vielleicht eine Idee was ich falsch mache?
Vielen Dank schon einmal im Voraus!

 

[geistio]

Hmm... also ich denke wirklich, dass es sich dabei um einen Bug des BRIstuff patches handelt....
An wen sollte ich mich mit diesem Bug-Report am Besten wenden?

 

[fsiggi]

Was sagt

cat /proc/zaptel/1 bzw. cat /proc/zaptel/2 ?

 

[geistio]

chef:~# cat /proc/zaptel/*
Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] layer 1 DEACTIVATED (F4)" (MASTER) 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 [NT] layer 1 DEACTIVATED (G2)" AMI/CCS

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

Hm.... könnte der Fehler vielleicht damit zu tun haben, dass die Karten derzeit noch nicht angeschlossen sind? D.h. Layer 1 ist down...
Wäre irgendwie logisch... doch warum bekomme ich die Fehlermeldung nicht, wenn ich einen *_ptmp Anschluss konfiguriert habe?

 

[fsiggi]

Wenn die Karten nicht angeschlossen sind, ist klar, das im ptp mode die D-Kanal Warnung kommt und bei ptmp nicht.

 

[geistio]

Hmm.... Wenn ich mir das so recht überlege, ergibt das so langsam auch einen Sinn...
fsiggi: :groesste:
Werde mich jedenfalls wieder melden, sobald die Karten angeschlossen sind...

 

[geistio]

Okay... ich habe jetzt einmal probehalber die TE-Karte an eine Auerswald Anlage angeschlossen. Auf der Auerswald ist der S0-Port als intern konfiguriert, d.h. im NT-Modus, oder?
Folgendes müsste doch funktionieren, oder?
Auerswald (NT) <=====> (TE) HFC-S Karte
Dabei wird ein ungekreuztes Kabel benutzt...
Die ganze Sache funktioniert leider Gottes nicht, /proc/zaptel/* zeigt mir zwar, dass Layer 1 aktiviert ist, aber es können weder eingehende, noch ausgehende Verbindungen hergestellt werden. Brauche ich denn bei HFC-S Karten IMMER ein gekreuztes Kabel?
Entschuldigung für die äußerst dumme Frage, aber ich verzweifle sonst noch...

 

[fsiggi]

Wie versuchst du denn eine Verbindung herzustellen? Mit einem SIP-Softphone?
Was zeigt die Asterisk Konsole dabei an?

Stimmt die extensions.conf?

 

[geistio]

Hmm.... also irgendwas stimmt da bei mir nicht... wenn die zaptel-module (zaptel, zaphfc, ...) geladen sind "spinnt" Asterisk völlig.
Nur ein Beispiel: Bei geladenen Zaptel-modulen sieht ein Anruf auf die Voicemailbox von X-Lite so aus:

Asterisk Ready.
*CLI>   == Primary D-Channel on span 1 down
[Apr  2 18:34:27] WARNING[4052]: chan_zap.c:2452 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
  == Primary D-Channel on span 1 down
[Apr  2 18:34:32] WARNING[4052]: chan_zap.c:2452 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
  == Primary D-Channel on span 1 down
[Apr  2 18:34:37] WARNING[4052]: chan_zap.c:2452 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
    -- Executing [80@privat:1] Answer("SIP/91-05feec60", "") in new stack
    -- Executing [80@privat:2] Wait("SIP/91-05feec60", "1") in new stack
    -- Executing [80@privat:3] VoiceMailMain("SIP/91-05feec60", "s89") in new stack
    -- <SIP/91-05feec60> Playing 'vm-youhave' (language 'de')
  == Primary D-Channel on span 1 down
[Apr  2 18:34:43] WARNING[4052]: chan_zap.c:2452 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
  == Primary D-Channel on span 1 down
[Apr  2 18:34:48] WARNING[4052]: chan_zap.c:2452 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
  == Spawn extension (privat, 80, 3) exited non-zero on 'SIP/91-05feec60'

*CLI> stop now

Ohne den Modulen so:

*CLI>     -- Executing [80@privat:1] Answer("SIP/91-0827d9c0", "") in new stack
    -- Executing [80@privat:2] Wait("SIP/91-0827d9c0", "1") in new stack
    -- Executing [80@privat:3] VoiceMailMain("SIP/91-0827d9c0", "s89") in new stack
    -- <SIP/91-0827d9c0> Playing 'vm-youhave' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'digits/6' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-Old' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-messages' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-onefor' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-Old' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-messages' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-opts' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-helpexit' (language 'de')
    -- <SIP/91-0827d9c0> Playing 'vm-goodbye' (language 'de')
    -- Executing [80@privat:4] Hangup("SIP/91-0827d9c0", "") in new stack
  == Spawn extension (privat, 80, 4) exited non-zero on 'SIP/91-0827d9c0'

 

[fsiggi]

An Span 1 ist offenbar nichts angeschlossen. Das sollte eigentlich aber nichts ausmachen.
Dennoch, schließ doch mal beide Karten ordentlich an, also die NT-Karte mit gekreuztem Kabel an einen Amts-Port der Auerswald und die TE-Karte an den NTBA.

Was passiert dann?

 

[DomRoc]

Wenn die Karten nicht angeschlossen sind, ist klar, das im ptp mode die D-Kanal Warnung kommt und bei ptmp nicht.

Bei mir ist es genauso wie Du es beschreibst. Ungenutzte als PTP konfigurierte S0-Busse habe ich deshalb auskommentiert.

 

[geistio]

Habe einen neuen Thread gestartet:
http://ting.ip-phone-forum.de/showthread.php?p=1077238