2 x octoBRI mit P-t-P und P-t-MP

[rklose]

Hallo,

ich habe hier eine kleines Problem. Es geht darum eine Telefonanlage hinter einer * einzubinden, wie es als BRI-PBX-Integration im bristuff Paket beschrieben steht.

10 B-Kanäle Anlagenanschluß - 2 B-Kanäle Mehrgeräte als Zugang vom Telefonanbieter. Bisher gehen diese Leitungen direkt auf die PBX.

Auf Hardwareseite wurde eine Karte komplett auf NT und eine auf TE gejumpert.

Bei der Installation der Software lief fast alles rund. Beide octoBRI von Junghanns wurden erkannt. Allerdings steht in der Zaptel durchgängig das alle Ports auf TE laufen.

Daraufhin hatte ich genzaptelconf -sdMv aufgerufen. Mit der Fehlermeldung, das SPAN nur 0-15 haben dürfte, aber nicht 16. Ich habe manuell dann in der zaptel.conf die Werte um eins reduziert. Das schien zu klappen. ztcfg -v zeigt alle Kanäle an schreibt aber "ZT_SPANCONFIG failed on span 0: Invalid argument (22)"

Wo muß da etwas korrigiert werden? Kann ich die Meldung ignorieren?

Ich vermute mal, das die Einstellung TE/NT und Anlagen/Mehrgeräteanschluß in der zapata.conf konfiguriert wird, oder?

Gruß
Roland

 

[rklose]

ein klein wenig bin ich weiter gekommen.

Auf Verdacht habe ich einfach mal in /etc/modules bei qozap ports=255 hinzugefügt. Und siehe da, mit ein mal sind 8 Ports im NT-Modus und 8 im TE-Modus. Nur, auf welcher Karte von den beiden octoBRI wurden die Ports entsprechend deklariert?

Automatisch die, die entsprechend gejumpert sind? Doch wohl eher nicht, denn dann könnte qozap es doch selber erkennen und man könnte sich den Eintrag in /etc/modules sparen.

Vielleicht hat der Eine oder Andere einen Tipp für mich.

Roland

 

[mindflow]

Mit einer Octrobri 2.0 soll das automatische erkennen funktionieren, zumindest laut Junghanns.net Webseite.
Mit der Ports-Angabe sagst du welche Ports im TE- und welche im NT-Modus funktionieren.
Das herausfinden welche Ports welcher Karte gehören ist hier leider schwierig, da es noch keine CardID gibt. Da hilft nur ausprobieren.
Die Ports-Option funktioniert folgendermassen, du hast deine 16-Ports, d.h. du legst eine 16-Bit Maske an, die je nach Kartenanordnung 0000000011111111 oder 1111111100000000 lautet, dabei entspricht das linkeste Bit dem Port 16, das rechteste Port 1. Nun musst du das ganze noch zusammenrechnen. also im 1. Fall 2^0+2^1+...+2^7=255 oder im 2. Fall = 2^8+2^9+2^10+...+2^15=2^16-256 =65280

Viele Grüße

Florian

 

[rklose]

Danke für den Hinweis,

mir war nicht bekannt, das man einfach die Kanäle bitweise aneinanderfügt (ist auch nirgends dokumentiert, zumindest habe ich es bisher nicht finden können). Bisher war ich immer davon ausgegangen, das man sowas je Karte macht. Aber so ist es natürlich einfacher.

Bezgl. der in meinem ersten Posting geschriebenen Meldung mit der 16 bin ich auch einen kleinen Schritt weiter, aber immer noch nicht am Ziel.

So sah meine Zaptel.conf direkt nach der Installation aus:

span=1,1,0,ccs,ami
#termtype: te
bchan=1-2
dchan=3
span=2,2,0,ccs,ami
#termtype: te
bchan=4-5
dchan=6
.
.
.
span=16,16,0,css,ami
#termtype: te
bchan=46-47
dchan=48

loadzone=nl
defaultzone=nl

Fehlermeldung: Timing im Span dürfe 16 nicht enthalten. Nach einigem Lesen bin ich dann dahinter gekommen, das die zweite Zahl etwas mit dem Timing zu tun haben muß. Was genau, wurde nicht erklärt (oder ich war zu blöd, das zu kapieren). Außerdem ist mir aufgefallen das in anderen zaptel.conf für die OctoBri als dritter Parameter hinter span= eine drei eingetragen wurde (Warum=?).
Statt 'ami' scheint es auch noch einen Parameter 'hdb3' zu geben, der Sinn ergeben könnte (zumindest bei France Telecom... für mich also wahrscheinlich nicht relevant [deutsches Netz]).

Bei mir liegt Span1 an einem Mehrgeräteanschluß (TE) und Span2-8 an einem Anlagenanschluß (TE), Span9 (also 2-te OctoBri) soll einen Mehrgeräteanschluß (NT) und Span10-16 einen Anlagenanschluß (NT) anbieten.

ich habe nun alle Span-Einträge im letzten Parameter auf 3 gesetzt und den zweiten Paramater auf 0, bis auf Span1,2 sowie Span9,10 die ich auf 1 gesetzt habe (Timing). Leider komme ich da immer noch nicht weiter. Vor allem weiß ich nicht, ob das überhaupt richtig ist. Jedenfalls kommen weder Fehlermeldungen noch HDLC-Fehler auf der Konsole.

Muß bei den oberen Spans (9-16), damit der NT-Modus aktiviert wird, evtl. zusätzlich noch aus "#Termtype: TE" noch "Termtype: NT" gemacht werden (also Raute entfernen und aus TE NT machen?)?

Da die Asterisk noch nicht fertig ist, kann ich sie auch nicht einfach so ins Netz einbinden und mir steht zum testen erstmal nur ein Mehrgeräteanschluß zur Verfügung, den ich auf Span1 anschließe. Ist zur grundsätzlichen Konfiguration der Anschluß am Anlagenanschluß notwendig? Gibt es eine einfache Möglichkeit, nicht benötigte Kanäle auszublenden?

Ist bei erfolgreicher Konfiguration in der Asterisk-CLI "zap show" verfügbar? Bisher ist das nicht der Fall. Auch ein ./zaptel start hat da nichts gebracht.

Meine zapata.conf sieht folgendermaßen aus:

[channels]

switchtype = euroisdn
pridialplan = dynamic
priclocaldialplan = local
nationalprefix = 0
internationalprefix = 00
usecallingpres=yes
overlapdial=yes
immediate=no
echocancel = yes
echocancelwhenbriged = yes
echotraining = 100

signalling = bri_cpe_ptmp
context=isdn-msn-in
group = 1

channel => 1-2

signalling = bri_cpe
context=isdn-incoming
group = 2

channel => 4-5
channel => 7-8
channel => 10-11
channel => 13-14
channel => 16-17
channel => 19-20
channel => 22-23

signalling = bri_net_ptmp
context=pbx-msn-in
group = 3
channel => 25-26

signalling = bri_net

context=pbx-incoming
group = 4

channel => 28-29
channel => 31-32
channel => 34-35
channel => 37-38
channel => 40-41
channel => 43-44
channel => 46-47

wenn ich bei dieser Konfiguration versuche mit einem angemeldeten SIP-Telefon herauszuwählen (intern klappt es), dann bekomme ich die Fehlermeldung:

"No channel type registered for ZAP" und "unable to create channel of type ZAP (cause 66 - channel not implemented)"

ein load chan_zap.so hilft auch nicht weiter: "already have an application 'ZapSendKeypadFacility'" und "unable to specify channel 1: No such devices or address", sowie "unable to register channel '1-2'"

in der extensions.conf steht für die Wahl:
exten=> _0X.,1,Dial(ZAP/g1/${EXTEN:1})

was mich insgesamt irritiert: die Konfiguration auf einem anderen Rechner mit einer billigen Fritz-Karte auf CAPI-Basis verlief problemloser und klappte vor allem auf Anhieb.

Der Einsatz von zwei OctoBri scheint auch etwas exotisches zu sein, zumindest nach dem, was man so in den Foren findet.

Falls Jemand an dem einen oder anderen Punkt einen Fehler findet, wäre ich für Informationen sehr dankbar. Vielleicht gibt es auch irgendwo etwas mehr Informationen zu Konfiguration und Hinweise auf Tools, mit denen man die Konfiguration auf richtige Parameter testen kann.

Gruß
Roland

 

[mindflow]

Hi, also im Installationshandbuch von Junhanns.net steht das (wenn auch missverständlich) beschrieben.

Zu deiner Config:
Ich denke die zaptel.conf ist für Bristuff von untergeordneter Bedeutung. Probier mal folgendes aus:

loadzone=nl
defaultzone=nl
# qozap span definitions
# most of the values should be bogus because we are not really zaptel
span=1,1,3,ccs,ami
span=2,2,3,ccs,ami
span=3,3,3,ccs,ami
span=4,4,3,ccs,ami
span=5,5,3,ccs,ami
span=6,6,3,ccs,ami
span=7,7,3,ccs,ami
span=8,8,3,ccs,ami
span=9,1,3,ccs,ami
span=10,2,3,ccs,ami
span=11,3,3,ccs,ami
span=12,4,3,ccs,ami
span=13,5,3,ccs,ami
span=14,6,3,ccs,ami
span=15,7,3,ccs,ami
span=16,8,3,ccs,ami
bchan=1,2
dchan=3
bchan=4,5
dchan=6
bchan=7,8
dchan=9
bchan=10,11
dchan=12
bchan=13,14
dchan=15
bchan=16,17
dchan=18
bchan=19,20
dchan=21
bchan=22,23
dchan=24
....

Damit sollten die Channels soweit passen. Nach dem ändern der Config musst du ztcfg- v aufrufen damit die Konfiguration aktiv wird. Danach sollte
cat /proc/zaptel/* schon mal etwas brauchbares auspucken.

Die Zapata sieht so erstmal brauchbar aus. Ich denke, dass dein Zaptel einfach noch nicht richtig gestartet war.

Gruß

Florian

 

[rklose]

Hallo Florian,
vielen Dank für den Tipp... damit hat es geklappt.

ich möchte an dieser Stelle vielleicht meine weiteren "Erfolge" schildern... Ich hoffe, das ist in Ordnung.

Zuerst hatte ich einfach die zweite Karte entfernt und alles auf TE eingestellt.

Dazu hatte ich in der zaptel.conf alle Einträge der zweiten Karte auskommentiert. Das gleiche habe ich in der zapata.conf gemacht.

Es hat alles auf Anhieb funktioniert. Ich war verblüfft. D.h. z.B. bei korrekter Installation sind alle LED aus (das wird auch irgendwo beschrieben). Wenn ein Amt anliegt, leuchtet die LED.

Mit diesem Wissen kann man dann weiter gehen. Ich habe daraufhin die zweite Karte wieder eingebaut. Aber die Treiber auskommentiert gelassen. Dabei hat sich dann herausgestellt, welche Karte eigentlich angesprochen wird. Denn bei der angesprochenen Karte gehen die LED aus (vorher die Leitungen entfernen), und bei der nicht angesprochenen bleibt alles eingeschaltet.

Dabei hatte sich bei mir herausgestellt, das die NT gejumperte Karte am Amt anlag, was nicht sein darf.

Übrigens, wenn man mit NT auf den ISDN-Anschluß vom Amt geht (und nicht zur dahinter angeschlossenen Telefonanlage), dann macht sich das durch HDLC-Fehler bemerkbar mit der die Konsole vollgemüllt wird. Das passiert dann, wenn man das Kabel gesteckt hat. Sobald man das Kabel entfernt, ist Ruhe

Das auskommentieren mit ";" in der zapata.conf reicht anscheinend aus, um Kanäle (bzw. Ports) zu deaktivieren. Das ist dann ganz nützlich wenn man wie bei mir die Anlagenanschlüsse zu Anfang nicht zur Verfügung hat. Ansonsten hätte man auf der Asterisk-CLI ständig die Meldung, das der D-Kanal für die entsprechenden Ports nicht zur Verfügung steht.

Damit scheint die grundsätzliche Hardwarekonfiguration erledigt zu sein....

Eine Kleinigkeit fehlt noch. Die Anschlüsse "PCM In" und "PCM Out". Direkt vom Amt vermittelte Gespräche in die alte Anlage sollten darüber laufen, oder?

Genügt ein Kabel von PCM Out nach PCM In? Wenn ja, auf welcher Karte wird dann PCM Out genutzt. Auf der NT oder auf der TE Karte? Oder benötigt man zwei Leitungen, die kreuzweise gesteckt werden? Oder müssen alle PCM Out und alle PCM In jeweils miteinander verbunden werden?

Gruß
Roland

---
Asterisk-Anfänger mit zwei Junghanns OctoBRI 2.0 PCI Karten.

 

[mindflow]

Du meinst das PCM-Bus kabel was intern an die OctroBRIs gesteckt wird?
Das dient nur zur synchronisation der Timing-Informationen, daten werden darüber nicht geschickt.

 

[rklose]

ja, den Anschluß meinte ich. D.h. der wird in meiner Konfiguration nicht benötigt? Ansonsten bin ich mit den bisherigen Ergebnissen zufrieden. Heute abend werde ich dann mal den Anlagenanschluß aufschalten.

 

[rklose]

Ist Murphy hier in der Nähe?

Anlage auf der NT-Seite angeschlossen.
Ergebnis: Null!
Nicht einmal die Leitung, die am Prüfhörer über den Mehrgeräteanschluss lief.

Immerhin haben mich die Leitungen vom Amt nicht im Stich gelassen.

Es werden die gleichen Kabel genommen, bei der die Anlage am Amtsanschluss funktioniert.

Wo unterscheidet sich die OctoBRI im NT Modus vom Amtsanschluss? Kann es nur an der fehlenden Stromversorgung liegen? Benötigt man für den NT-Modus zwingend eine externe Stromzuführung?

Fragen über Fragen....

Gruß
Roland

 

[mindflow]

Hi,

also Stromversorgung brauchst du nicht zwingend und Kabel können auch bleiben. Was heißt Ergebnis null? Meldet die Telefonanlage das sie keinen Anschluss hat? Kommt etwas an der Asterisk an?

Viele Grüße

Florian

 

[rklose]

Hallo Florian,

vielen Dank erstmal, das Du Dich meiner Probleme hier annimmst.

Wenn ich es richtig verstanden habe, sollte beim Anschluß der Anlage an die OctoBRI die entsprechende LED leuchten, oder? Zumindest beim funktionierenden Prüfhörer war das der Fall.
Daraufhin hatte ich den Mehrgeräteanschluß der Anlage zuerst einmal auf den PTMP-NT Anschluß den ich auf der OctoBRI habe angeschlossen (SPAN1). LED leuchtet nicht. Wenn ich versuche die Amtsleitung auf der Telefonanlage zu holen, reagiert sie, als wenn kein Kabel angeschlossen ist. Währenddessen habe ich die anderen Anlagenanschlußleitungen nicht angeschlossen gehabt. Auf der Asterisk tat sich auch nichts. Keine Meldung. Nichts. Als wenn das Kabel nicht angeschlossen wäre. Wenn ich genau dieses Kabel dann wieder direkt auf die Amtsleitung lege, funktioniert die Anlage wie gehabt. Das heißt also, das das Kabel in Ordnung ist.
Wenn ich den Prüfhörer direkt an den Anschluß der OctoBRI lege, funktioniert der auch.

Später habe ich dann vom Amt den Anlagenanschluß auf die eine OctoBRI Karte (TE) gelegt, und auf die andere (NT) die Telefonanlage. Auch hier gab es keine Reaktion auf der NT-Karte. Weder von der Anlage noch von Asterisk. Die TE-Karte hat fleissig geleuchtet und eingehende Gespräche (die aber nicht weiter geleitet werden konnten) wurden auch auf der Asterisk-CLI gemeldet.

Wenn eine Stromversorgung nicht nötig ist, kann eigentlich nur noch das Kabel schuld sein, oder? Was wird eigentlich durch den Jumperblock TE/NT gemacht?

Gruß
Roland

 

[speedy1980]

Ich habe auch schon komische Sachen erlebt, wenn am NT Port ein Endgerät (oder eine Telefonanlage) mit eigener Stromversorgung angeschlossen ist, aber die ISDN Karte im Asterisk keine Stromversorgung für diesen NT Port hat. Eigentlich wird dann ja keine Stromversorgung für die ISDN Karte im Asterisk benötigt. So wirklich funktioniert hat so ein Aufbau aber selten. Deswegen wird bei meinen Installationen jetzt immer eine Stromversorgung für die ISDN Karte installiert, wenn ein oder mehrere Ports auf NT sind. Egal welche Geräte dann angeschlossen werden.

 

[rklose]

So, nachdem ich mich an den Händler gewandt habe, der das dann weiter an Junghanns geschickt hat, habe ich folgende Neuigkeiten die sehr passend mit Speedy1980s Aussagen sind:

Der Junghanns Support meinte, die Timingangaben sollte man auf der NT-Karte auf 0 setzen. OK, habe ich gemacht. Hat leider auch nichts weiter geholfen. War aber auch nicht schädlich.
Daraufhin habe ich in den Anlagenanschluß einen NTBA gesetzt. Also Strom drauf, und beide ISDN Anschlüsse jeweils einmal Richtung Anlage und einmal Richtung Asterisk.

Und ja, plötzlich funktioniert es. Nur der PTMP-(MSN)-Anschluß bockt. Bei der Anwahl von außen gibt es die Meldung "Rufnummer nicht vollständig". Auf der Anlage meldet sich der Kanal aber als belegt. Hat jemand eine Idee, wo es da hapert? Ich habe zur Anwahl in die Extensions.conf sowohl die MSN wie auch die MSN inkl. Vorwahl eingetragen. Klappte beides nicht.

So, und jetzt eine Frage an die Leute hier im Forum, die wissen, an welcher Seite der Lötkolben heiß ist: Kann man ohne weiteres die Stromversorgung aus dem NTBA abklemmen und der octoBRI direkt zuführen. Das hätte den Vorteil, das ich nicht für jeden Port einen NTBA dazwischen schalten müßte.

Gruß
Roland

 

[rklose]

So, noch einige Informationen wie es weiter gegangen ist.

Nach Anschluß von sechs noch aufgefundenen NTBA kann man jetzt die Leitungen nutzen.

Ich habe Gespräche, die auf dem PTMP-(MSN)-Anschluß ankommen auf den PTP-Anschluß weitergeleitet, der die Gespräche dann in der Telefonzentrale auflaufen läßt.

Bei ausgehenden Gesprächen wurde immer nur die Rufnummer der Zentrale und nicht die der Nebenstellen angezeigt. Im Forum habe ich dazu folgenden Vorschlag gefunden:

exten => _0X.,1,SetCallerID(9111234${CALLERIDNUM})
exten => _0X.,2,SetCallerPres(allowed_passed_screen)
exten => _0X.,3,Dial(Zap/g1/${EXTEN:1})
exten => _0X.,4,HangUp()

Der funktionierte bei mir nicht, weil sich anscheinend die Variable CALLERIDNUM verändert hat. Mit CALLERID(NUM) hat es geklappt. Außerdem mußte die Vorwahl entfernt werden. Damit war alles bestens.

Ein kleines Problemchen gibt es noch. Hin und wieder ist die Sprachqualität unter aller Kanone. Leider läßt sich nicht genau feststellen, wann das der Fall ist. Auch scheint es bei der Echokompensation nicht immer zu funktionieren. Man hört sich selber verhackstückt auf dem eigenen Hörer. Das gilt für Gespräche von der alten Anlage über die Asterisk ins Netz. Mit SIP-Telefonen ist das bisher nicht aufgetreten. Das liegt vielleicht aber auch daran, das bisher nur 2 Apparate über SIP angeschlossen sind.

Ist das evtl. eine Einstellung, die man über die Codecs einstellt?
Mal sehen, ob ich dazu in den weiten des Netzes etwas finden kann.

Gruß
Roland

 

[DomRoc]

Hallo Roland,

schön dass Du das jetzt hinbekommen hast. Ich bin ja sozusagen Leidensgenosse. Mein beiden octoBRIs sind definitiv richtig konfiguriert (Stichwort: qozap ports=xyz).
Einen Tip vom Junghanns-Support folgend habe ich einfach mal einen PTP TE-Port mit einem NT-Port direkt per Patchkabel verbunden. Und siehe da, es klappt alles auf Anhieb! Auch wenn man bei PTMP einen TE- mit einem NT-Port verbindet funktioniert es, es muss allerdings die Rufnummer passen, sonst hebt der TE-Port quasi nicht ab!

Mein Problem besteht weiterhin darin, die Anlage an einem NT-Port des Asterisk anzuschliessen. An einem TE-Port (also der Asterisk quasi als Teilnehmer am Anlageninternen S0) klappt es hingegen schon lange.

Ich bekomme die Anlage an einem NT-Port weder an einem PTP- noch PTMP-Port aktiv. Den Tip mit dem NTBA dazwischen, um irgendwie Strom draufzubekomme, habe ich auch schon ausprobiert. Die Terminierung im NTBA habe ich ausgeschaltet, und beide Male einfache Patch-Kabel verwendet: Ist das denn so richtig?

Hast Du bei Dir das PCM-Kabel im Einsatz? Bei mir ging es damit irgendwann mal nicht und ich habe es ausgebaut, da das ganze wohl beim Einsatz von BRIstuff nicht notwendig sei!

Vielleicht hast Du ja noch den ein oder anderen Tip für mich, denn ich bin wirklich langsam am verzweifeln. Das Powerfeeding-Modul habe ich nämlich auch nicht!


Schöne Grüße,
Dominik

 

[rklose]

Hallo Dominik,
das PCM-Kabel ist anscheinend ohne Bedeutung. Ist bei mir nicht angeschlossen. Ich hatte zu Anfang vermutet, das darüber die direkt vermittelten Gespräche laufen. Dem ist wohl nicht so, jedenfalls funktioniert es jetzt so. An der NT Karte ist die Terminierung aktiviert. Bei den NTBA habe ich alles so belassen wie es ist. Und auch bei der Anlage habe ich nichts geändert. Würde also heißen, das es bei mir evtl. sogar falsch abgeschlossen ist, wenn sowohl NTBA wie Anlage und auch NT Karte den Widerstand enthalten. Nachdem was ich so gelesen habe, scheint das kein wirkliches Problem zu sein.
Eingesetzt habe ich sowohl Patchkabel wie auch selbst konfektionierte Kabel, um aus den 4 Anschlüssen der Karte auf 8 Anschlüsse bei der Anlage(NTBA) zu kommen. Dabei sind alle Kabel 1:1 verbunden. Also nichts gekreuztes oder ähnliches.
Die LED an den Karten zeigen den Status an. Wenn der qozap richtig installiert ist, sollte die entsprechende LED leuchten, wenn alles richtig verkabelt ist. Wenn der qozap richtig installiert ist, und kein Kabel angeschlossen ist, muß die LED dunkel bleiben. HDLC-Fehler sollten auch nicht angezeigt werden. Auch SPAN Fehler die auf einen fehlenden D-Kanal hinweisen sollten nicht auftauchen.

Bei mir habe ich folgende Konfiguration zum laufen bekommen:
bristuff-0.4.0-test6-xr2
asterisk-1.4.19
auf Debian 4.0 r3 Etch mit Kernel 2.6.18-6-486

viel Erfolg
Roland

PS.: was mir übrigens immer gut weiter geholfen hat ist die Asterisk-CLI mit einem recht hohen Verbose und Debug Level. Außerdem natürlich die Kontrolle ob die Zuteilung der SPAN in der zaptel.conf und der zapata.conf passt.

 

[DomRoc]

[Edito foschi: fullquote entfernt!]

Danke für die Infos!
Im Prinzip hab ich dann das gleiche installiert wie Du. Die Meldungen a la

== Primary D-Channel on span 10 down
[Apr 28 14:20:39] WARNING[3150]: chan_zap.c:2452 pri_find_dchan: No D-channels available! Using Primary channel 51 as D-channel anyway!
== Primary D-Channel on span 14 down
[Apr 28 14:20:39] WARNING[3154]: chan_zap.c:2452 pri_find_dchan: No D-channels available! Using Primary channel 63 as D-channel anyway!

kommen bei mir nur dann, wenn wirklich kein Kabel angeschlossen ist. Wenn ich wie in diesem Fall einfach nur ein Patch-Kabel zwischen Port 1 und 5 (Span 10 und 14) einstecke, dann verschwindet auch diese Meldung und ich kann über diese Verbindung Gespräch aufbauen. (Port 1 ist im TE, Port 5 im NT-Mode, beides PTP).

Bekommst Du diese Meldungen nicht, wenn Du einen offenen PTP-Anschluss hast?

Ich glaube langsam wirklich, dass mein Problem an der wenig Kontaktfreudigen AGFEO liegt!

Schöne Grüße,
Dominik

 

[rklose]

Hallo Dominik,

[Apr 28 14:20:39] WARNING[3150]: chan_zap.c:2452 pri_find_dchan: No D-channels available! Using Primary channel 51 as D-channel anyway!

Das sah bei mir etwas anders aus, bei mir fehlte so etwas wie "pri_find_dchan". Könnte das bei Dir mit dieser PRILib zusammenhängen? Die habe ich nämlich nicht eingesetzt.

WARNING: chan_zap.c: No D-channels available! Using Primary channel 30 as D-channel anyway!

Und das ist auch der Fall wenn der NTBA nicht zwischen der Asterisk und der Telefonanlage (hier: NITSUKO, dürfte eher unbekannt sein) aktiviert ist.
In dem Moment, wo der NTBA Strom bekommt, kommt die Meldung "Primary D-Channel on Span 10 up".

Ich kann mir eigentlich nicht vorstellen, das das Problem wirklich an der Telefonanlage liegt, es sei denn, die octoBRI stellt die Daten nicht genauso dar, wie ein echter Anlagenanschluß. Und da habe ich mittlerweile gelernt, kann bei der Konfiguration eine Menge schief gehen.
Bliebe für Dich ansonsten fast nur noch der Test mit einer alternativen Anlage. Ich kann mir auch nicht vorstellen, das nicht Andere auch Probleme damit hätten. AGFEO-Anlagen sind doch eigentlich recht verbreitet. Vielleicht ist ja doch noch jemand Anderes hier im Forum, der eine AGFEO an der octoBRI hat, und seine Erfahrungen bzw. ".conf" darstellen kann.

Gruß
Roland

 

[DomRoc]

[Edit foschi: Bitte keine Fullquotes - beim nächsten gibt es eine Verwarnung!]

Hallo,
habe jetzt mal ein AGFEO-ISDN-Systemtelefon an einen PTMP-NT-Port angeschlossen, natürlich mit NTBA zwecks Stromversorgung dazwischen. Zumindest das Telefon funktioniert dann schonmal. Es nimmt zwar keine Anrufe an (liegt evtl. am Notfallbetrieb), aber Anrufe absetzen kann es.
Bei der AGFEO werde ich mir mal je einen PTP und einen PTMP S0 konfigurieren lassen (TE-Mode, nennt sich "S0 extern") und dann morgen nochmal testen.
Ich hoffe doch mal stark, dass es wenigstens mit dem NTBA wie bei Dir dann klappt!
Eigentlich ja alles schon letzte Woche getestet, aber hoffentlich hab ich da was übersehen und es funktioniert dann morgen doch noch...
Denn ansonsten wüsste ich dann auch nimmer weiter!

Danke und schöne Grüße,

PS: Die LEDs arbeiten bei mir übrigens wie Du beschrieben hast. Allerdings ist es schon ein bischen verwirrend, dass die Ports 1-4 grün leuchten und die Ports 5-8 dann orange!
Dominik

 

[DomRoc]

Hallo,

da fällt mir noch folgendes ein: Bei der Kompilierung des test6-xr musste ich in der compile.sh den zaphfc aus dieser Zeile entfernen:

BRISTUFF_ZAP_MODS="${BRISTUFF_ZAP_MODS:-cwain qozap zaphfc ztgsm}"

Das Problem war ein Kompilierungsfehler. Aber das sollte bei den octoBRIs doch zu keinem Fehler führen, schliesslich wird der qozap benutzt und mit anderen Geräten als der AGFEO arbeitet die Karte ja auch.

Eine Direktverbindung zwischen NT- und TE-Port läuft einwandfrei, sowohl im PTP- als auch PTMP-Modus.

Vielleicht hat ja noch jemand eine Idee, warum die AGFEO bei mir nicht an den NT-Ports der octoBRI laufen will!

@rklose:
Du hast das ganze mit dem PRI ja schon angesprochen. Bekommst Du auf der Asterisk-CLI nicht die Möglichkeit z.B. sowohl "PRI debug span x" als auch "BRI debug span x" zu benutzen?
Hast Du den test6-xr2 ganz normal kompiliert oder irgendwelche Veränderungen vorgenommen?

Wenn ich die originale unveränderte LibPRI vom test6-xr2 benutzte, dann kommt es bei meinen Versuchen dann teilweise zum berüchtigten "cause 18"-Bug. Also ist mein Problem vermutlich auch nicht an der gepatchten LibPRI zu suchen.

Grüße,
DomRoc