linux-avmb1:Probleme mir c2faxrcv am Anlagenanschluß
Rainer Krienke
krienke at uni-koblenz.de
Mon Mar 21 09:35:16 CET 2005
Hallo,
ich betreibe an der Uni auf einem Linuxrechner (suse9.0) mit einer
AVM-B1-Karte einen Faxservice, bei dem Faxe aufgrund der Zielrufnummer per
Email direkt zum Empfänger geroutet werden. Die B1-Karte ist an der
Alcatel-Telefonanlage der Uni angeschlossen und wird durch einen Nummerpräfix
(100) angesprochen. Anschließend müssen 4 Ziffern für die Durchwahl des
Mitarbeiters gewählt werden, die dann zum Routen des Fax verwendet werden.
Das ganze hat jetzt ca. 3 Jahre ohne Probleme geklappt.
Vor kurzem wurde die Firmware der Alcatel-Anlage upgedated. Danach klappte der
Faxservice nicht mehr, wenn man über ein Amt geht (ein intern versendetes Fax
klappt weiterhin). Der Verdacht lag natürlich auf einem Problem nach dem
Update. Alcatel hat das untersucht und sagt das sie (Alcatel) nicht schuld
sind. Es sehe so aus als ob die Fax-Applikation nicht korrekt arbeitet, wenn
sie Rufnummern als Blockwahl erhält. Die alte Alcatel-Firmware hätte hier
wahrscheinlich einen bug gehabt und die Durchwahl immer einzeln geliefert
nicht en Block. Laut Alcatel ist es am P2P-Anschluß korrekt die Durchwahl en
Block an die Untervermittlung zu übergeben, was die neue Firmware jetzt eben
tut.
Schaut man in das CAPI-Trace hinein (avmcapictrl trace 1 full), so sieht man
tatsächlich, das beim internen Versand eines Fax auf die B1-Karte (also eine
interne Verbindung innerhalb der Alcatel-Anlage) die 4 Durchwahlziffern
nacheinander eintreffen und die Verbindung aufgebaut wird.
Hier das CAPI-Trace für diesen Fall:
http://www.uni-koblenz.de/~krienke/alcatel/internal_dial.txt
Macht man das gleiche diesesmal jedoch über ein Amt, so kann man erkennen, das
die 4-Stellige Durchwahl als Block geliefert wird. Jetzt klappt der
Verbindungsaufbau nicht. Der Anrufer hört nur ein Besetztzeichen, c2faxrecv
sagt nach einer kleinen Weile:
Connection is droped with reason 0x34E6 (Recovery on timer expiry).
Hier das hoffentlich etwas aussagekräftigere CAPI-Trace:
http://www.uni-koblenz.de/~krienke/alcatel/external_dial.txt
Das seltsame ist, ich kann die capifaxrcvd-Anwendung nehmen und damit das
eingehende Fax problemlos empfangen. Allerdings fehlt bei dieser Anwendung so
manches, insbesondere die Ausgabe der Zielrufnummer, die ich ja zum routen
des Fax brauche. Daher ist capifaxrcvd keine wirkliche Alternative.
Da ich an dieser Stelle mit meinem Latein am Ende bin, würde ich gerne wissen,
ob jemand den CAPI-Traces etwas mehr entnehmen kann als ich, was auf einen
möglichen Fehler hindeuten könnte? Interessant wäre auch zu wissen, ob
c2faxrecv bei jemandem anderen am Anlagenanschluß funktioniert, und ob dort
Blockwahl gemacht wird? Wie kann ich sonst noch mehr rauskriegen, was hier
schief geht? Jemand eine Idee?
Vielen Dank im Voraus
Rainer Krienke
--
---------------------------------------------------------------------------
Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022
Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312
Mail: krienke at uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke
Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mlists.in-berlin.de/pipermail/linux-avmb1-mlists.in-berlin.de/attachments/20050321/eea973d2/attachment.pgp
More information about the linux-avmb1
mailing list