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