zaphfc outbound Problem

[ChristianMS]

Hallo,

ich habe hier 2 HFC Karten in einem Asterisk (Debian Etch, bristuff-enabled) mit bristuff 0.2.0-RC8r und florz. Eine Karte läuft im TE Modus am ISDN Anschluss der deutschen Telekom, die andere im NT Modus mit einem ISDN-Telefon dran.
Die TE-Karte macht Probleme: Es können Anrufe entgegengenommen werden, aber hinauswählen geht nicht. In der zapata.conf habe ich als signalling für diese Karte "bri_cpe_ptmp". Das für mich kuriose ist: Wenn ich das signalling auf "bri_net_ptmp" umstelle, kann die Karte keine Anrufe mehr entgegen nehmen, aber man kann raustelefonieren.

Hier die Konsolenausgabe

 1 Channel 0/-1, Call 124  - received AOC charging request - charging case: 1
1 Channel 0/-1, Call 124  - received AOC charging request - charging case: 2
    -- Accepting overlap voice call from '13' to '123456' on channel 0/2, span 1    -- Starting simple switch on 'Zap/2-1'
    -- Executing Dial("Zap/2-1", "Zap/g2/123456") in new stack
Oct  8 02:47:04 NOTICE[7600]: app_dial.c:1076 dial_exec_full: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion)
  == Everyone is busy/congested at this time (1:0/1/0)
Oct  8 02:47:14 WARNING[7600]: pbx.c:2416 __ast_pbx_run: Timeout, but no rule 't' in context 'default'
    -- Hungup 'Zap/2-1'

zapata.conf habe ich von http://www.pug.org/index.php/Asterisk-bristuff pübernommen und nur die contexte angepasst.

zaptel.conf

loadzone=nl
defaultzone=nl
# Hinweis: Zone nl ist mit Zone de identisch

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

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

dialplan

exten => _XXX.,1,Dial(Zap/g2/${EXTEN})
exten => 555555,1,Dial(Zap/g1/${EXTEN})

wobei 555555 meine Nummer ist.

Ich habe schon mehrere andere bristuff-zaphfc Durchprobiert, das Problem ist immer das selbe. Ich hoffe, hier kann mir jemand helfen.
Vielen Dank und schöne Grüße

Christian

 

[madiehl]

Wo hast Du denn die Gruppen g1 und g2 definiert?

 

[ChristianMS]

danke für deine Antwort, das war mein Fehler. Bei meinen Versuchen hatte ich zuletzt diese eine als funktionierend bezeichnete zapata.conf verwendet. Jetzt hab ich wieder diese ursprüngliche:

[channels]
language=de
switchtype = euroisdn
pridialplan = local
prilocaldialplan= local
nationalprefix = 0
internationalprefix = 00
echocancel=yes
immediate=no
overlapdial=yes
;priindication = outofband

; interne Gruppe
group = 1
signalling = bri_net_ptmp
context=default
channel => 1-2

; an das oeffentliche-ISDN-Netz
group = 2
context=default
signalling = bri_cpe_ptmp
channel => 4-5

Ansonsten ist alles, wie im ersten Beitrag beschrieben.

 

[clan]

ich habe hier 2 HFC Karten in einem Asterisk (Debian Etch, bristuff-enabled) mit bristuff 0.2.0-RC8r und florz. Eine Karte läuft im TE Modus am ISDN Anschluss der deutschen Telekom, die andere im NT Modus mit einem ISDN-Telefon dran.
Die TE-Karte macht Probleme: Es können Anrufe entgegengenommen werden, aber hinauswählen geht nicht. In der zapata.conf habe ich als signalling für diese Karte "bri_cpe_ptmp". Das für mich kuriose ist: Wenn ich das signalling auf "bri_net_ptmp" umstelle, kann die Karte keine Anrufe mehr entgegen nehmen, aber man kann raustelefonieren.

Funktioniert es denn, wenn du die andere Karte als TE betreibst? Falls ja scheint die Karte ein Problem zu haben, falls nicht würde ich auf die Verkabelung tippen.

 

[ChristianMS]

Ich habe die Karten bereits in den PCI-Slots getauscht, das hat keine Besserung gebracht. Es handelt sich um eine Karte von Conrad und eine von Sitecom.
Ausserdem habe ich testweise den NT und TE Modus der jeweils anderen Karte zugewiesen. Das hat ebenfalls nichts gebracht.
Verkabelung werde ich gleich checken.

 

[ChristianMS]

Die Verkabelung ist so, dass anstelle der TE-Karte auch ein normales iSDN-Telefon am Netz hängen kann. An der NT-Karte hängt ein NTBA, an dem die Leitung gekreuzt ist. Auch hier funktioniert das Telefon.
Mir ist total rätselhaft, warum das signalling den im ersten Beitrag beschriebenen Einfluss hat.

 

[clan]

Ich habe die Karten bereits in den PCI-Slots getauscht, das hat keine Besserung gebracht. Es handelt sich um eine Karte von Conrad und eine von Sitecom.
Ausserdem habe ich testweise den NT und TE Modus der jeweils anderen Karte zugewiesen. Das hat ebenfalls nichts gebracht.
Verkabelung werde ich gleich checken.

Der Fehler wandert also mit? Eigentlich ein Zeichen für Verkabelungsprobleme. In der Anschlußleitung sind zwei Adern zum Senden, die anderen beiden zum Empfangen. Beim Wechsel zwischen NT und TE werden die Adern vertauscht, deshalb die Notwendigkeit für eine gekreuzte Leitung, wenn die Karte im NT-Modus betrieben wird (Junghanns hat dafür Jumper auf der Karte). Den Symptomen nach ist ein Adernpaar hinüber.

Hast du den Test mit dem ISDN-Telefon an der gleichen Leitung gemacht die zum Asterisk führt, oder es mit einer eigenen Leitung an die Dose angeschlossen? Oder anders: ist möglicherweise die Verbindung von der Dose zum TE-Port defekt?

 

[ChristianMS]

Hast du den Test mit dem ISDN-Telefon an der gleichen Leitung gemacht die zum Asterisk führt, oder es mit einer eigenen Leitung an die Dose angeschlossen? Oder anders: ist möglicherweise die Verbindung von der Dose zum TE-Port defekt?

ich habe das Kabel aus der TE-Karte rausgezogen und in das Telefon reingesteckt. Das Telefon hat dann funktioniert.

 

[clan]

ich habe das Kabel aus der TE-Karte rausgezogen und in das Telefon reingesteckt. Das Telefon hat dann funktioniert.

Schade, das Problem liegt also wohl doch woanders.

Dann sollte man jetzt vielleicht doch auf das ISDN-Protokoll schauen. Mache doch mal 'bri debug span 2' (Span 2 ist doch das Problem?) in der Asterisk CLI und versuche ein Telefonat nach draussen. Da sollten einige ISDN-Messages zu sehen sein. Vielleicht hilft das ja weiter. Debug-Modus abschalten geht übrigens mit 'bri no debug span 2'.

 

[ChristianMS]

praxis-internet*CLI> bri debug span 2
Enabled debugging on span 2
1 Channel 0/-1, Call 124  - received AOC charging request - charging case: 1
1 Channel 0/-1, Call 124  - received AOC charging request - charging case: 2
    -- Accepting overlap voice call from '13' to '485083' on channel 0/2, span 1    -- Starting simple switch on 'Zap/2-1'
    -- Executing Dial("Zap/2-1", "Zap/g2/485083") in new stack
Oct 14 13:26:26 NOTICE[7824]: app_dial.c:1076 dial_exec_full: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion)
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Channel 0/2, span 1 got hangup request
    -- Hungup 'Zap/2-1'
praxis-internet*CLI>

wie mir scheint, kommt erst gar keine ISDN-Verbinung zustande, weil Asterisk meint, alle Leitungen sein voll. Das ist aber definitiv nicht der Fall.

 

[Cy8aer]

Ähnliches Problem (Debian Bug 386052)

Ich hab ein ähnliches Problem, das sich bei irgendeinem Wechsel der Standard-Debian Pakete für zaptel ergeben hat:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386052

Ich habe eine Karte TE dranhängen. Konfiguration siehe Bugreport. Ich kann mir bei einem Neustart meines Rechners seltsam behelfen: Nach dem Neustart des Rechners rufe ich mich selbst an, was den "cause 34" erzeugt. Anschließend stoppe ich den Asterisk und setze in der zapate.conf signalling = bri_cpe. Nach dem Neustart des Asterisk rufe ich mich wieder selbst an, das Rauswählen funkt aber nun ist besetzt. Nun setze ich den Parameter wieder auf bri_cpe_prmp und starte den Asterisk neu. Und - Oh Wunder: alles funktioniert - bis der Asterisk das nächste mal neu gestartet wird.

Ich habe langsam den Eindruck, daß irgendwas hardwaremäßig falsch bei ptmp falsch konfiguriert wird und mit obigem Trick irgendwas in der Hardware hängenbleibt. Kann das vielleicht auch am Prozessor liegen (ich hab ne VIA C3-Maschine).

Natürlich habe ich schon mit diversen Kabeln und (!) Karten rumgespielt, ohne Erfolg.

 

[ChristianMS]

Hallo,

das Problem scheint bei mir gelöst:
Ich habe die von Debian etch bereitgestellten Pakete asterisk-bristuff und zaptel gelöscht und die komplette bristuff-Installation laufen lassen. Voila!

Grüße
Christian