Sangoma B700 stört andere Geräte am Mehrgeräteanschluss

[eogfhwsk]

Ich habe hier folgendes Problem:

An einem Mehrgeräteanschluss betreibe ich 3 Geräte: 1 ISDN Telefon, 1 digitale Faxkarte (Dialogic Diva 2fx) sowie eine Sangoma B700 Karte mit Asterisk als PBX für die VOIP Haustelefone. Sobald wanrouter gestartet ist, kann das Telefon und die Faxkarte nicht mehr verwendet werden, da der abgehende B-Kanal jeweils extrem gestört ist. Das eingehende Signal ist nicht gestört. Die Signalisierung scheint zu funktionieren (Klingeln, CLID, etc). Dies ist unabhängig davon ob gerade die B700er Karte selbst auf einem B-Kanal aktiv ist oder nicht. Die Gespräche über die B700 sind immer ok und hier funktioniert alles bestens. Sobald wanrouter gestoppt wird, kann wieder telefoniert und gefaxt werden. Kurz ausgedrückt könnte man sagen, dass die B700 den Bus nicht mit anderen Geräten teilen will, wodurch die Möglichkeiten des Mehrgeräteanschlusses verloren gehen.

Das Problem tritt auch bei einer zweiten Karte auf, womit man einen Hardwarefehler sehr wahrscheinlich ausschliessen kann. S0-Bus Terminierung und Polarität der Leitungen wurden bereits überprüft und keine Probleme gefunden. Ich habe auch bereits Sangoma kontaktiert, wobei bereits die typischen HWEC, FAX Optionen ohne Ergebnis durchprobiert worden sind.

Kann jemand dieses Problem bestätigen? Wenn ja, ist eine Lösung bekannt?

Hier noch einige technische Details:
Asterisk 1.6.2.13 (auch 1.6.2.10 getestet, sollte aber keine Rolle spielen)
DAHDI 2.4.0 (auch 2.3.0.1 getestest, da die BRI Kanäle über Woomera laufen, dürfte DAHDI aber keinen Einfluss haben)
Wanpipe 3.5.16 (auch 3.5.14 getestet)

 

[eogfhwsk]

Mit Hilfe des technischen Supports von Sangoma wurde mein Problem gelöst. Für meine besondere Konfiguration war eine spezielle Option in einer der Konfigurationsdateien notwendig.

 

[Junialter]

Ich bin neugierig... Welche Option war es?

 

[eogfhwsk]

Es handelte sich um den Wert eines Signals im Idle-Modus der Karte. In Frage kommende Wanpipes benötigen explizit einen gültigen Wert für IDLE_FLAG, da ältere Treiber nur bei Verwendung des mu-law Codecs korrekt arbeiteten. Neuere Treiber (3.5.17.x) benötigen diese manuellen Einstellungen nicht mehr. Die neueste Version 3.5.18 werde ich erst am Wochenende testen können. Theoretisch dürfte es keine Probleme geben, aber gegenüber 3.5.17.9 hat es sehr viele Codeänderungen und Ergänzungen gegeben, zumal es auch neue Firmwares für die Hardwareechounterdrückung der Octasic Chips gibt.

 

[dsb]

bei mir ist es leider auch so und das mit unterschiedlichen Karten (digium B410P und Junghanns QuadBri), kannst Du evtl. den Parameter genauer spezifizieren. Danke

 

[eogfhwsk]

Sorry wegen der verzögerten Antwort.

Sangoma verwendet eigene zum Teil proprietäre Treiber. Von daher macht es nicht viel Sinn den Treiberparameter zu beschreiben. Es mag dennoch sein, dass die eigentlich technische Ursache gleich ist. Ich würde mal mit einem D-Kanal-Protokoll beginnen und schauen was passiert, wenn eigentlich auf dem S-Bus nicht viel los sein sollte...

 

[dsb]

Wie mache ich denn ein D-Kanal-Protokoll? Könntest Du den Parameter nicht doch mal nennen, ein Versuch würde ja nicht schaden. Danke.

 

[eogfhwsk]

Der Konfigurationsparameter nennt sich IDLE_FLAG, wie schon in meiner Nachricht vom 25.11.2010 beschrieben, und was er bewirkt wird einem schlagartig klar, wenn man die D-Kanal Daten mitschneidet. Den Sangoma Treibern liegt eine API mit Beispielprogrammen bei, die unter anderem auch zeigen wie man an die D-Kanal Daten kommt. Wie das bei den Digium und Junghanns Karten aussieht, weiss ich nicht. Ich vermute mal, mit etwas Suchen wird man auch hier fündig werden...