G
gandalf94305
Guest
Hallo zusammen,
nachdem die Kopplung einer FBF mit einer Tk-Anlage via ISDN inzwischen ja ein nachvollziehbarer Prozess geworden ist, fehlt noch ein Mosaiksteinchen zum Glück: Fallback an die Tk-Anlage, falls kein VoIP-Anruf geschaltet werden kann (aus unterschiedlichen Gründen).
Ich habe nun festgestellt, daß verschiedene DisconnectReasons signalisiert werden (die FBF verwendet CAPI-Notation). Dies sind z.B. 3301 (kein B-Kanal, wenn Festnetz nicht angeschlossen ist), 349f, 34af, ... Leider sind das jedoch nicht immer die korrekten Codes. Wenn beispielsweise ein User Busy signalisiert werden sollte, so kann auch ein Switch Congestion Signal kommen...
Meine Auerswald-Anlage führt wohl nur dann einen Fallback auf die nächste Anwahlalternative durch, wenn User Busy signalisiert wird. Schön wäre natürlich, wenn die beiden sich verstehen würden.
Also: wo kann ich erkennen, welche ISDN Disconnect Cause tatsächlich zurückgegeben wird? Ich konnte bisher in den Logs nichts finden. Wenn es gelingt, die tatsächlichen Causes zu identifizieren, dann könnte man in der Tat ein Fallback mit der Auerswald-Anlage durchführen, wenn diese die Äquivalente der 33xx (Protokoll-Fehler) und 34xx (ISDN Fehler) abgefangen werden (nicht nur User Busy) bzw. wenn man die FBF analog zu Cisco-Routern konfigurieren könnte, die ein Mapping von ISDN Cause Codes erlauben.
Wunschdenken? Realistisch machbar? :gruebel:
Meinungen? Informationen? ;-)
--gandalf.
nachdem die Kopplung einer FBF mit einer Tk-Anlage via ISDN inzwischen ja ein nachvollziehbarer Prozess geworden ist, fehlt noch ein Mosaiksteinchen zum Glück: Fallback an die Tk-Anlage, falls kein VoIP-Anruf geschaltet werden kann (aus unterschiedlichen Gründen).
Code:
killall telefon
telefon a127.0.0.1 | logger -t telefon &
Ich habe nun festgestellt, daß verschiedene DisconnectReasons signalisiert werden (die FBF verwendet CAPI-Notation). Dies sind z.B. 3301 (kein B-Kanal, wenn Festnetz nicht angeschlossen ist), 349f, 34af, ... Leider sind das jedoch nicht immer die korrekten Codes. Wenn beispielsweise ein User Busy signalisiert werden sollte, so kann auch ein Switch Congestion Signal kommen...
Meine Auerswald-Anlage führt wohl nur dann einen Fallback auf die nächste Anwahlalternative durch, wenn User Busy signalisiert wird. Schön wäre natürlich, wenn die beiden sich verstehen würden.
Also: wo kann ich erkennen, welche ISDN Disconnect Cause tatsächlich zurückgegeben wird? Ich konnte bisher in den Logs nichts finden. Wenn es gelingt, die tatsächlichen Causes zu identifizieren, dann könnte man in der Tat ein Fallback mit der Auerswald-Anlage durchführen, wenn diese die Äquivalente der 33xx (Protokoll-Fehler) und 34xx (ISDN Fehler) abgefangen werden (nicht nur User Busy) bzw. wenn man die FBF analog zu Cisco-Routern konfigurieren könnte, die ein Mapping von ISDN Cause Codes erlauben.
Wunschdenken? Realistisch machbar? :gruebel:
Meinungen? Informationen? ;-)
--gandalf.