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

Hallo,

des Rätsels Lösung war eigentlich ganz einfach. Weder war die Software (Treiber) falsch konfiguriert, noch fehlte die Spannungsversorgung für die NT-Ports: Es werden in meinem Fall einfach gedrehte ISDN-Kabel benötigt, um die Verbindung zwischen NT-Port der Junghanns-Karte und dem externen S0 der AGFEO-Anlage zu realisieren!
Nach dem Umcrimpen funktioniert nämlich soweit alles!
Das ganze steht natürlich im krassen Gegensatz zu den Aussagen aus diversen Anleitungen, Foren und dem Junghanns-Support!

Grüße
DomRoc
 
Glückwunsch...

leider habe ich hier im Moment ganz andere Schwierigkeiten. Deswegen habe ich meine Konfiguration soweit geändert das jeweils die Ports 1-4 im TE und 5-8 im NT Modus laufen (hat trotzdem nichts gebracht).

Und zwar gibt es teilweise unerklärliche Abbrüche (2-3 mal täglich bei ca. 300 Gesprächen). Der qozap meldet Dropped Audio im Kernel.Log.
Danach sind beide B-Kanäle auf der Anlage nicht mehr verfügbar. Wenn man dann das Kabel kurz unterbricht (oder einen Restart durchführt), läuft alles, als wenn nichts gewesen wäre.
Nach Aussage von Junghanns soll das mit den IRQs zusammenhängen. Nun haben beide Karten ihre ganz eigenen IRQs zugeweisen bekommen (5 + 7). Damit das funktioniert habe ich sämtliche Sonderfunktionen im BIOS die der Rechner nicht benötigt abgeschaltet: LPT, USB, serielle Ports, nicht benötigte IDE-Ports usw. In der PCI Konfiguration konnte ich das zuordnen.
Hat aber nicht geholfen.
Ich könnte auch noch DMA-Kanäle zuordnen. Ich weiß aber nicht, ob die explizit benötigt werden (es steht also auf AUTO).

Die analoge FAX-Anbindung über die Anlage macht bei einigen Kunden (es sind zwar immer die selben, aber eben auch nicht ständig) Probleme mit Abbrüchen und Übertragungsfehlern (sowohl beim Empfang [Hylafax, sollte zukünftig dann auf IAXModem umgestellt werden], wie auch beim senden [Standalonegeräte und Hylafax].
Ich hatte schon vermutet, das man evtl. durch ändern der TX- und RXGAIN-Werte in der zapata.conf weiter kommt (habe es getestet mit Werten zwischen 0 und 4). Leider hat das auch nichts gebracht.

Außerdem gab es dann noch einige ganz wenige Anrufe, bei denen die Echounterdrückung nicht funktionierte (oder evtl. besonders gut?). Jedenfalls habe ich auch da in der zapata.conf etwas experimentiert (Werte zwischen 50-200, yes, no.... halt was man alles in dem Bereich einstellen kann). Hat leider auch nichts gebracht.

Momentan durfte ich deswegen die Asterisk erst mal wieder vom Netz nehmen, weil die Geschäftsführung die Probleme nicht besonders lustig fand. Leider stellen sich die Probleme immer erst dann ein, wenn das System 1. lange am Netz hängt und 2. viele Gespräche geführt werden. Das heißt jetzt nicht, das ab 6 Gesprächen gleichzeitig die Probleme auftreten. Auch wenn nur 1 oder zwei Gespräche laufen kann es dazu kommen.

Im Moment bin ich ein klein wenig resigniert.

Ich weiß, das speziell das Faxhandling nicht ganz einfach ist, hätte mir aber eigentlich gedacht, das System liesse sich wirklich einfach transparent zwischen Anschluß und Anlage hängen. Bei mir hat das (bisher) nicht 100%ig geklappt.

Vielleicht gibt es Jemanden, der vor dem gleichen Problem stand, und eine Lösung für mich hat. Oder einen Hinweis, wie man das prüfen kann, was da evtl. falsch läuft, und was da irgendwo außerhalb der Toleranz ist.

Gruß
Roland
 
Hallo Roland,

ein richtiger Last-Test steht ja bei mir auch noch aus!

Ob die analogen Faxe bei mir dann richtig durchkommen weiß ich auch noch nicht, aber die GAIN-Werte sind schon kritisch. Ich hatte bei jedem 3. Gespräch eines SIP-Clients über den Asterisk direkt ins ISDN-Netz ein drastisches Übersteuern des Empfangspegels. D.h. man hat nur noch Klirren in der Leitung, der Gesprächspartner merkt aber von all dem nix.
Mit ztmonitor kannst Du die Leitungen richtig einpegeln. Steht auch auf www.voip-info.org was dazu. Muss aber wohl für jeden Anschluss seperat gemacht werden, d.h. das Konfig-File wird etwas länger!
Mit Echo hatte ich auch schon zu kämpfen, allerdings war da die Anlage noch vor dem Asterisk, was wohl die Probleme verursacht hat. Echocancel habe ich wieder auf den Default-Wert zurückgesetzt, der scheint am besten für hiesige ISDN-Anschlüsse zu funktionieren.
Ich hoffe mal das Durchleiten klappt dann doch noch halbwegs transparent und ohne großen Aufwand. Ich möchte die ganzen Funktionen (Fax usw.) auch erst nach und nach auf den Asterisk umstellen.
Viel Glück weiterhin! Wird schon irgendwie klappen! :)

Grüße,
DomRoc
 
Hallo,

ein kurzer Ausschnitt aus der kern.log:

Code:
May 15 10:12:36 asterisk kernel: qozap: Junghanns.NET octoBRI (Version 2.0) card configured at io port 0xec00 IRQ 7 HZ 250
May 15 10:12:36 asterisk kernel: qozap: S/T ports: 8 [ TE TE TE TE NT NT NT NT ]
May 15 10:12:36 asterisk kernel: dips = 0x0 cid = 0
May 15 10:12:36 asterisk kernel: qozap: Junghanns.NET octoBRI (Version 2.0) card configured at io port 0xe880 IRQ 5 HZ 250
May 15 10:12:36 asterisk kernel: qozap: S/T ports: 8 [ TE TE TE TE NT NT NT NT ]
May 15 10:12:36 asterisk kernel: qozap: 2 multiBRI card(s) in this box, 16 BRI ports total, bloop 0, pcmslave 0, dacs 1.

.
.
.

May 15 10:19:51 asterisk kernel: qozap: dropped audio card 2 cardid 0 bytes 20 z1 76 z2 40 fifo 8
May 16 09:14:07 asterisk kernel: qozap: dropped audio card 2 cardid 0 bytes 1 z1 0 z2 111 fifo 2

Im BIOS habe ich jeder Karte einen eigenen IRQ zugewiesen und cat /proc/interrupts zeigt folgendes:

Code:
  0:   21542017    IO-APIC-edge  timer
  2:          0          XT-PIC  cascade
  5:   86226710   IO-APIC-level  qozap
  7:   86154797   IO-APIC-level  qozap
  8:          1    IO-APIC-edge  rtc
 10:    5254685   IO-APIC-level  nvidia
 11:    1023365   IO-APIC-level  libata
201:    8992624         PCI-MSI  eth0
NMI:          0 
LOC:   21542960 
ERR:          1
MIS:          0

An den IRQs können die dropped Audio Meldungen demnach wohl nicht liegen, oder?

Hat jemand eine Idee?

Gruß
Roland
 
Hallo Roland,

hab mal meine kern.log inspiziert und kann nur ein paar von diesen Meldungen, welche wohl nur sporadisch auftreten, sehen:

May 16 00:33:53 kiste kernel: qozap: CRC error for HDLC frame on card 2 (cardID 0) S/T port 8
May 16 01:38:29 kiste kernel: qozap: CRC error for HDLC frame on card 1 (cardID 0) S/T port 3
May 16 04:05:01 kiste kernel: qozap: CRC error for HDLC frame on card 1 (cardID 0) S/T port 5
May 16 09:24:11 kiste kernel: qozap: CRC error for HDLC frame on card 2 (cardID 0) S/T port 7

Haben aber anscheinend keine Auswirkung!


Vor ein paar Tagen hatte ich sehr selten (jede Woche ca. 1 mal) ein Meldung in der Art:

May 10 07:32:08 kiste kernel: qozap: dropped audio card 1 cardid 0 bytes 2 z1 55 z2 37 fifo 7

Allerdings sind diese "dropped audi" Meldungen seit einer Woche nichtmehr aufgetreten. Evtl. sind sie ja jetzt ganz weg wegen dem korrekten Anschluss der AGFEO-Anlage!

Grüße und viel Erfolg,
Dominik

PS: Ich hab nen Dual-Core! Können es evtl. zuviele Interrupts für die eine CPU sein, die die beiden Karten verursachen?
Obwohl sich bei mir die beiden Karten auf die beiden CPUs verteilen, habe ich mit der analogen Sangoma noch eine Interrupt-Schleuder auf CPU0, und das funktioniert ja auch!
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.